Qué son los Core Web Vitals (CWV) y cómo mejorarlos

Si Search Console te ha avisado de un problema de «Core Web Vitals» o alguien de tu equipo ha dicho que la web «suspende las CWV», están hablando de lo mismo: tres mediciones con las que Google valora si una página carga rápido, responde cuando se pulsa algo y se mantiene quieta mientras se carga. Las tres se pueden comprobar gratis en unos minutos.

Esta guía explica qué mide cada una, qué valores pide Google, dónde consultarlas y qué hay que tocar en la web para mejorarlas, con una idea clara de qué parte puedes hacer tú y qué parte es trabajo técnico.

Qué son los Core Web Vitals y qué significa CWV

CWV son las siglas de Core Web Vitals, que en las herramientas de Google en español aparecen traducidas como «Métricas web principales». Son un subconjunto de las Web Vitals, la iniciativa con la que Google propuso en 2020 una forma común de medir la experiencia de carga y uso de una página.

Un core web vital es cada una de esas métricas. Hoy son tres:

• LCP, que mide la velocidad de carga del contenido principal.
• INP, que mide lo que tarda la página en reaccionar a lo que hace el usuario.
• CLS, que mide si los elementos se desplazan mientras la página se carga.

Dos rasgos las distinguen de una prueba de velocidad cualquiera. Se miden sobre visitas reales de usuarios de Chrome, así que reflejan lo que vive tu cliente con su móvil y su conexión. Y Google las usa dentro de sus sistemas de clasificación como parte de lo que llama experiencia de página.

Las tres métricas: LCP, INP y CLS

La lista ha cambiado una vez desde que existe. Hasta marzo de 2024 la métrica de respuesta era FID (First Input Delay), que solo medía el retraso de la primera interacción. INP la sustituyó porque mide todas las interacciones de la visita. Si una guía o una auditoría todavía te habla de FID, está desactualizada.

LCP (Largest Contentful Paint): cuánto tarda en cargar lo principal

El LCP mide el tiempo que pasa desde que el usuario pide la página hasta que se pinta el elemento más grande visible en pantalla. Casi siempre es la imagen de cabecera, una foto de producto o el bloque de texto del titular.

Es la métrica que más se parece a la sensación de «esta web va lenta». Una página puede empezar a mostrar cosas enseguida (el menú, el logo) y aun así tener un LCP malo si la imagen principal pesa dos megas.

INP (Interaction to Next Paint): cómo responde a los clics

El INP mide cuánto tarda la página en mostrar una respuesta visible después de un clic, un toque en el móvil o una pulsación de tecla. Registra las interacciones de toda la visita y se queda con una de las más lentas, de modo que un solo botón pesado basta para estropearlo.

Es la métrica del botón que no hace nada al primer toque o del filtro de la tienda que congela la pantalla un segundo después de marcarlo. Esos retrasos son pequeños en tiempo y grandes en experiencia de usuario (UX): el visitante vuelve a pulsar, duda o se va.

CLS (Cumulative Layout Shift): si el contenido se mueve al cargar

El CLS mide cuánto se desplazan los elementos de la página sin que el usuario lo provoque. Es el caso del texto que baja de golpe cuando aparece un banner encima, o del botón de compra que cambia de sitio justo cuando ibas a pulsarlo.

A diferencia de las otras dos, no se mide en tiempo: es una puntuación sin unidades que combina cuánta superficie de la pantalla se mueve y cuánta distancia recorre.

Qué valores se consideran buenos

Google publica tres tramos para cada métrica:

El detalle que más se pasa por alto es cómo se calcula el valor. Google toma el percentil 75 de las visitas, que es más exigente que la media: una página aprueba el LCP si al menos tres de cada cuatro visitas lo tienen por debajo de 2,5 segundos. Además mide por separado móvil y ordenador, y en móvil suele ser donde una web suspende.

Para que una página se considere buena en Core Web Vitals tiene que aprobar las tres métricas a la vez. Dos en verde y una en ámbar no bastan.

Cómo medir tus Core Web Vitals

Antes de elegir herramienta conviene entender que hay dos tipos de datos:

• Datos de campo: los de visitas reales, que Google recoge de los usuarios de Chrome en el informe CrUX (Chrome User Experience Report) con una ventana de 28 días. Son los que cuentan para Google.
• Datos de laboratorio: una prueba simulada que lanza Lighthouse en un dispositivo y una conexión fijos. Sirven para diagnosticar y comparar antes y después de un cambio, pero no son lo que ve Google.

Con esa distinción, estas son las herramientas gratuitas que necesitas:

1. PageSpeed Insights (pagespeed.web.dev). Pegas una URL y te devuelve arriba los datos de campo de CrUX, si la página tiene tráfico suficiente, y debajo el análisis de laboratorio de Lighthouse con una lista de mejoras sugeridas. Es la primera parada para revisar una página concreta.
2. Informe de Métricas web principales de Search Console. Agrupa las URL de toda la web en buenas, a mejorar y deficientes, separando móvil y ordenador. Te dice qué plantillas fallan (todas las fichas de producto, todos los artículos) en vez de obligarte a revisar página por página.
3. Chrome DevTools. El panel Rendimiento muestra en directo el LCP, el INP y el CLS mientras navegas por tu propia web, útil para encontrar qué interacción concreta es la lenta.

Una web con poco tráfico puede no tener datos de campo: CrUX necesita un mínimo de visitas para publicar resultados. En ese caso te quedan los datos de laboratorio, que orientan, aunque no son la nota con la que Google trabaja. Ten en cuenta también que Lighthouse no puede medir el INP, porque en la prueba nadie pulsa nada; en su lugar muestra el Total Blocking Time, una métrica relacionada.

Por qué importan para el SEO

Google ha confirmado que los Core Web Vitals forman parte de las señales de experiencia de página que tienen en cuenta sus sistemas de clasificación. También ha dejado claro su peso: la relevancia del contenido va primero, y una página con métricas perfectas no adelanta a otra que responde mejor a la búsqueda.

Donde sí pesan es entre páginas que responden igual de bien. En sectores con mucha competencia, donde los primeros resultados tienen contenidos parecidos, la experiencia de página es uno de los factores que pueden decidir quién queda por encima.

El otro motivo para cuidarlos tiene poco que ver con Google. Una página que tarda en mostrar el producto, que no reacciona al botón de añadir al carrito o que mueve el formulario mientras escribes pierde ventas y contactos aunque esté en la primera posición. Por eso, en una agencia SEO como la nuestra, revisar los Core Web Vitals forma parte del SEO técnico de cualquier proyecto: afecta a cómo te clasifica Google y a lo que hace el usuario cuando llega.

Cómo mejorar cada métrica

Cada métrica tiene sus causas habituales. Este es el punto de partida, ordenado por lo que más se repite en las webs de pymes.

Para mejorar el LCP

• Optimiza la imagen principal: formato moderno (WebP o AVIF), servida al tamaño en que se muestra y nunca con carga diferida (lazy loading), porque así el navegador la pide tarde.
• Dale prioridad: el atributo fetchpriority="high" o una precarga indican al navegador que esa imagen va primero.
• Acelera la respuesta del servidor: un hosting adecuado al tráfico, caché de página y una CDN si tus visitas llegan de lejos.
• Reduce el CSS y el JavaScript que bloquean el renderizado: todo lo que el navegador tiene que descargar antes de pintar retrasa el contenido principal.

Para mejorar el INP

• Quita scripts de terceros que no uses: chats, mapas de calor, botones para compartir en redes y píxeles de campañas antiguas. Cada uno ocupa el procesador del móvil cuando el usuario quiere pulsar.
• Divide las tareas largas de JavaScript para que el navegador pueda atender un clic entre una y otra.
• Aligera la página: un HTML con miles de elementos (menús enormes, filtros con cientos de opciones) hace más lenta cada actualización de la pantalla.

Para mejorar el CLS

• Declara el ancho y el alto de imágenes y vídeos para que el navegador les reserve el hueco antes de descargarlos.
• Reserva espacio para lo que llega tarde: banners, anuncios, vídeos incrustados y avisos que se cargan después del resto.
• Controla las fuentes web: si la fuente final ocupa más o menos que la provisional, el texto salta al cambiar. Precargarla y ajustar la fuente de reserva lo evita.
• No insertes contenido encima del que ya se ve, salvo que responda a una acción del usuario.

Si tu web está hecha con WordPress, buena parte de estas mejoras dependen del tema y de los plugins que tengas instalados. Tenemos una guía con el paso a paso para optimizar WordPress y que cargue más rápido.

Algunos arreglos están a tu alcance, como comprimir imágenes o desinstalar un plugin que no usas. Otros, como reescribir el JavaScript del tema o configurar la caché del servidor, requieren a alguien que trabaje en el código.

Mantener los Core Web Vitals con el tiempo

Aprobar los Core Web Vitals una vez no garantiza seguir aprobando. Las métricas se degradan con el uso normal de una web: una actualización de plugin que añade un script, el píxel de una campaña nueva, un banner promocional sin espacio reservado o un artículo con fotos subidas directamente desde el móvil.

A eso se suma el retraso de los datos. Como CrUX trabaja con los últimos 28 días, un problema introducido hoy tarda semanas en aparecer del todo en Search Console, y una corrección también tarda en reflejarse. Cuando el aviso llega, el problema lleva tiempo afectando a las visitas.

La forma de evitarlo es revisarlos con una frecuencia fija: el informe de Search Console una vez al mes y PageSpeed Insights sobre las plantillas principales después de cada cambio en la web. Cualquier plugin o script nuevo se mide antes de instalarlo en producción. Es una de las tareas que incluimos en el servicio de mantenimiento web, junto a las actualizaciones y las copias de seguridad, para que la velocidad de la web no dependa de que alguien se acuerde de mirarla.