Core Web Vitals explicados: qué son y cómo mejorarlos

Si su web tarda una eternidad en cargar, se siente lenta cuando alguien intenta hacer clic en algo o tiene elementos que saltan por la pantalla como si hubieran tomado demasiado café, tiene un problema de Core Web Vitals. Y sí, Google está atento.

Los Core Web Vitals son la forma que tiene Google de medir cómo se siente realmente su web para personas reales. No cómo se ve en una maqueta de diseño, ni lo ingenioso que es el código por dentro, sino cómo se comporta en la práctica cuando alguien la abre en el móvil durante la pausa del almuerzo. Y desde 2021, estas métricas son un factor de posicionamiento confirmado de Google. Así que ignorarlas ya no es realmente una opción.

Tanto si es empresario y se pregunta por qué su web no posiciona, como si es desarrollador intentando exprimir hasta el último milisegundo, o simplemente alguien con curiosidad por saber qué significan realmente esas extrañas puntuaciones de PageSpeed Insights, esta guía explica los Core Web Vitals en lenguaje claro. Veremos qué mide cada métrica, por qué importa y, lo más importante, cómo arreglar de verdad las cosas que arrastran sus puntuaciones hacia abajo.

Vamos al lío.

Qué son los Core Web Vitals

Los Core Web Vitals son un conjunto de tres métricas concretas que Google utiliza para evaluar la experiencia de usuario de una página web. Se centran en las tres cosas que más importan: rendimiento de carga, interactividad y estabilidad visual.

Esta es la alineación:

• LCP (Largest Contentful Paint) mide la rapidez con la que carga el contenido principal de su página
• INP (Interaction to Next Paint) mide la rapidez con la que responde su página cuando alguien interactúa con ella
• CLS (Cumulative Layout Shift) mide cuánto se mueve inesperadamente el contenido en la pantalla

Google introdujo estas métricas como parte de sus señales de experiencia de página más amplias, y las ha ido refinando desde entonces. ¿El cambio reciente más importante? En marzo de 2024, INP reemplazó oficialmente a FID (First Input Delay) como métrica de capacidad de respuesta. Si todavía optimiza para FID, va un poco por detrás, solo por decirlo.

Estas métricas se recopilan de usuarios reales a través del Chrome User Experience Report (CrUX), lo que significa que Google no se limita a ejecutar pruebas de laboratorio en su web. Está midiendo cómo se comporta realmente para las personas que la visitan en el mundo real. Eso es emocionante y un pelín aterrador a la vez.

Los umbrales que Google considera “buenos”:

• LCP: 2,5 segundos o menos
• INP: 200 milisegundos o menos
• CLS: 0,1 o menos

Si alcanza esas cifras en al menos el 75 % de las visitas a su página, Google considera que sus Core Web Vitals están aprobados. Cualquier cosa peor significa que está dejando sobre la mesa tanto posicionamiento como satisfacción de los usuarios.

LCP: Largest Contentful Paint

El LCP mide cuánto tarda en aparecer en la pantalla el mayor elemento de contenido visible. Suele ser una imagen hero, un titular grande, un bloque de texto extenso o la miniatura de un vídeo, básicamente lo que ocupa más espacio visual por encima del pliegue.

¿Por qué importa tanto esta métrica? Porque el LCP es lo más cercano que tenemos para medir lo que una persona real percibe como “la página ya ha cargado”. A nadie le interesa de forma aislada su evento DOMContentLoaded ni su Time to First Byte. A la gente le interesa ver contenido real. El LCP captura ese momento.

La propia documentación de LCP de Google entra a fondo en los detalles técnicos, pero aquí tiene el desglose práctico.

Lo que suele causar un LCP malo:

• Tiempos de respuesta del servidor lentos (su TTFB lo arrastra todo hacia abajo)
• Archivos JavaScript y CSS que bloquean el renderizado
• Imágenes sin optimizar, tamaños de archivo enormes, sin formatos modernos
• Renderizado del lado del cliente que retrasa la aparición del contenido real
• Aplicar lazy loading a su imagen hero (en serio, no lo haga)

Cómo mejorarlo:

• Optimice el tiempo de respuesta de su servidor. Si su TTFB supera los 600 ms, empiece por ahí. Use un CDN, active el caching y considere mejorar su hosting.
• Precargue los recursos críticos. Use <link rel="preload"> para su imagen hero y las fuentes críticas, de modo que el navegador las obtenga de inmediato.
• Use formatos de imagen modernos. AVIF y WebP son notablemente más pequeños que JPEG y PNG con la misma calidad visual. Su imagen de LCP debería estar sin duda en uno de estos formatos.
• No aplique lazy loading a las imágenes por encima del pliegue. Su imagen hero debería cargar de inmediato, no esperar a un evento de scroll que aún no ha ocurrido. Este es uno de los errores más comunes que existen.
• Minimice los recursos que bloquean el renderizado. Inserte el CSS crítico inline, aplace el JavaScript no esencial y mantenga la ruta crítica de renderizado lo más ligera posible.

Un buen LCP es de 2,5 segundos o menos. Entre 2,5 y 4 segundos necesita mejora. ¿Más de 4 segundos? Eso es una señal de alarma, y Google lo trata como tal.

INP: Interaction to Next Paint

El INP es la métrica más reciente de la alineación de Core Web Vitals, y es bastante importante. Reemplazó a First Input Delay (FID) en marzo de 2024 porque FID solo medía el retardo de la primera interacción, lo cual, sinceramente, no contaba toda la historia. El INP mide la capacidad de respuesta de todas las interacciones a lo largo de toda la visita a la página y luego informa de la peor (a grandes rasgos).

En lenguaje claro: cuando alguien toca un botón, hace clic en un enlace o escribe en un campo, ¿cuánto tarda la página en responder visualmente? Eso es el INP.

Lo que causa un INP malo:

• Ejecución pesada de JavaScript que bloquea el hilo principal
• Tareas largas (Chrome considera tarea larga cualquier cosa que supere los 50 ms)
• Controladores de eventos costosos que hacen demasiado trabajo cuando un usuario interactúa
• Scripts de terceros, piense en analítica, anuncios, widgets de chat, todos peleándose por el tiempo de CPU
• Estructuras DOM complejas que tardan una eternidad en actualizarse tras una interacción

Cómo mejorarlo:

• Divida las tareas largas. Use setTimeout, requestAnimationFrame o la API scheduler.yield() para repartir el trabajo pesado en fragmentos más pequeños, de modo que el navegador pueda responder a la entrada del usuario entre ellos.
• Reduzca el tamaño de su bundle de JavaScript. Menos JavaScript significa menos que analizar y ejecutar. El code splitting y el tree shaking son sus mejores aliados aquí.
• Aplique debounce a los controladores de eventos. Si tiene controladores de scroll o de entrada disparándose constantemente, aplíqueles debounce para que no se ejecuten en cada evento.
• Audite los scripts de terceros sin piedad. Ese widget de chat o ese embed social podría estar añadiendo 200 ms a su retardo de interacción. ¿Compensa el sacrificio?
• Use web workers para los cálculos pesados. Descargue el trabajo ajeno a la interfaz a un web worker para que no bloquee el hilo principal.

El INP es donde muchos sitios más sufren ahora mismo, porque expone problemas de rendimiento que siempre estuvieron ahí pero que FID nunca captó. Si su web se siente lenta cuando la gente interactúa con ella, el INP probablemente le esté diciendo exactamente por qué.

CLS: Cumulative Layout Shift

El CLS mide la estabilidad visual, en concreto, cuánto se desplaza inesperadamente el contenido mientras la página carga. ¿Conoce esa experiencia exasperante en la que está a punto de tocar un enlace y la página salta de repente porque encima ha cargado un anuncio o una imagen? Eso es un desplazamiento de diseño, y el CLS cuantifica exactamente lo grave que es.

Los culpables más comunes detrás de un CLS malo:

• Imágenes y vídeos sin dimensiones explícitas de anchura y altura
• Anuncios, embeds o iframes que cargan sin espacio reservado
• Contenido inyectado dinámicamente que empuja el contenido existente hacia abajo
• Fuentes web que provocan un destello de texto invisible (FOIT) o un destello de texto sin estilo (FOUT)
• Banners de carga tardía o barras de consentimiento de cookies que empujan todo hacia abajo

Cómo mejorarlo:

• Establezca siempre anchura y altura en imágenes y vídeos. O use la propiedad CSS aspect-ratio. Esto permite que el navegador reserve la cantidad correcta de espacio antes de que el recurso cargue de verdad.
• Reserve espacio para anuncios y embeds. Use un contenedor con una altura mínima fija para que el contenido de abajo no salte cuando el anuncio aparezca por fin.
• Use font-display: swap junto con el preloading de fuentes. Esto evita el texto invisible y reduce el desplazamiento de diseño cuando entran en juego las fuentes personalizadas.
• Evite insertar contenido por encima del contenido existente. Si necesita añadir un banner o una notificación, use una posición sticky o fixed, o insértelo por debajo del pliegue.
• Use la propiedad CSS contain donde sea apropiado. Le indica al navegador que ciertos elementos no afectarán al diseño de sus elementos hermanos, lo que ayuda a prevenir desplazamientos inesperados.

El CLS es traicionero porque a menudo está perfectamente bien durante el desarrollo, pero es terrible en el mundo real, donde las conexiones son más lentas y los recursos cargan en momentos impredecibles. Pruebe siempre en dispositivos reales con conexiones limitadas, no solo en su MacBook con fibra.

Cómo afectan los Core Web Vitals a su SEO

Bien, vayamos a la parte que de verdad le interesa a todo el mundo: ¿cuánto importan realmente los Core Web Vitals para el SEO?

Google ha sido bastante claro al respecto. Los Core Web Vitals son una señal de posicionamiento confirmada como parte de su actualización de experiencia de página. Pero aquí está el matiz que mucha gente pasa por alto: no son el factor de posicionamiento más importante. El contenido relevante y de alta calidad sigue ganando. Si su artículo es la mejor respuesta a la consulta de búsqueda de alguien, puede posicionar bien incluso con unos Core Web Vitals mediocres.

Pero la cosa es así: en igualdad de condiciones, el sitio con mejores Core Web Vitals lleva la ventaja. Piénselo como un desempate. Si dos páginas tienen un contenido igual de excelente, Google va a preferir la que carga más rápido, responde antes y no tiene cosas saltando por ahí.

Y más allá del posicionamiento directo, los Core Web Vitals tienen un impacto indirecto enorme a través de las señales de comportamiento del usuario:

• Las páginas más rápidas tienen tasas de rebote más bajas
• Una mejor interactividad mantiene a la gente interesada durante más tiempo
• Los diseños estables reducen la frustración y aumentan las conversiones

Google Search Console tiene un informe dedicado a los Core Web Vitals que le dice exactamente qué páginas están aprobando y cuáles necesitan trabajo. Si se toma en serio el SEO, debería revisarlo con regularidad.

Una cosa más que conviene saber: Google evalúa los Core Web Vitals a nivel de página y agrupa las páginas similares. Así que si todas sus entradas de blog comparten la misma plantilla y una de ellas tiene unos CWV malos, las demás probablemente también. Arregle la plantilla, las arregla todas. Esta es también la razón por la que las tendencias modernas de diseño web se construyen cada vez más en torno al rendimiento desde la base.

Cómo medir sus Core Web Vitals

No puede mejorar lo que no mide. Por suerte, Google le da un montón de herramientas gratuitas para comprobar sus Core Web Vitals. Estas son las que realmente debería conocer:

PageSpeed Insights

PageSpeed Insights es la herramienta de referencia para la mayoría de la gente. Introduzca cualquier URL y obtenga tanto datos de laboratorio (pruebas simuladas) como datos de campo (usuarios reales) para los tres Core Web Vitals. También le da recomendaciones concretas sobre qué arreglar, priorizadas por impacto. Empiece aquí.

Google Search Console

El informe de Core Web Vitals de Search Console le muestra qué páginas de su web entera son buenas, necesitan mejora o son deficientes. Es la vista a vista de pájaro que necesita para monitorizar tendencias a lo largo del tiempo y detectar regresiones antes de que hundan su posicionamiento.

Chrome DevTools (Lighthouse)

Integrado directamente en Chrome, Lighthouse ejecuta una auditoría de laboratorio de su página y le da puntuaciones de rendimiento junto con sugerencias accionables. Súper útil para depurar problemas concretos durante el desarrollo, cuando necesita probar cambios en tiempo real.

Chrome User Experience Report (CrUX)

CrUX es el conjunto de datos de métricas de usuarios reales que Google utiliza de verdad para fines de posicionamiento. Puede acceder a él a través de PageSpeed Insights, el CrUX Dashboard o la CrUX API. Esta es la verdad sobre el terreno, lo que Google está mirando literalmente cuando evalúa su web.

Biblioteca JavaScript Web Vitals

Si quiere hacer un seguimiento de los Core Web Vitals en su propia analítica, la biblioteca web-vitals de código abierto de Google se lo pone súper fácil. Unas pocas líneas de código y ya estará midiendo las tres métricas a partir de sus visitantes reales.

Consejo de profesional: no se limite a probar en su flamante MacBook con conexión de fibra. La prueba de verdad es en un móvil Android de gama media con conexión 4G. Ahí es donde navega de verdad la mayor parte del mundo, y eso es lo que le importa a Google.

Victorias rápidas para mejorar sus puntuaciones

Si sus puntuaciones de Core Web Vitals tienen mala pinta y necesita avanzar rápido, aquí tiene algunas victorias rápidas que suelen ofrecer la mejor relación entre esfuerzo y resultado:

1. Comprima y convierta sus imágenes. Cambie a WebP o AVIF, redimensione al tamaño real de visualización y comprima con decisión. Solo esto puede recortar segundos de su LCP.
2. Añada dimensiones explícitas a todas las imágenes y vídeos. Atributos de anchura y altura o CSS aspect-ratio. Es de lejos la corrección individual más rápida para los problemas de CLS.
3. Aplace el JavaScript no crítico. Añada defer o async a las etiquetas de script que no necesitan ejecutarse de inmediato. Mueva los scripts de terceros por debajo del pliegue.
4. Precargue su imagen de LCP. Una línea en su <head>: <link rel="preload" as="image" href="your-hero.webp">. Eso es todo.
5. Use un CDN. Servir los recursos estáticos desde servidores edge cercanos a sus usuarios reduce drásticamente la TTFB y mejora el LCP en todos los frentes.
6. Audite sus scripts de terceros. Elimine todo lo que no esté usando activamente. Esa vieja etiqueta de analítica, ese widget social que nadie clica, ese script de pruebas A/B de hace dos años, deshágase de ellos.
7. Active el caching del navegador. Configure cabeceras Cache-Control adecuadas para que los visitantes recurrentes no tengan que volver a descargarlo todo desde cero.
8. Minimice el impacto de la carga de fuentes. Precargue las fuentes críticas, use font-display: swap y considere reducir el número de grosores de fuente que carga.

Lo bonito de los Core Web Vitals es que los pequeños cambios se suman rápido. No siempre necesita una revisión enorme. A veces es solo un puñado de correcciones específicas las que llevan sus puntuaciones del rojo al verde.

Si la optimización del rendimiento le resulta abrumadora, o simplemente quiere que alguien se encargue de ella como es debido, eso es literalmente lo que hacemos. Construimos webs con los Core Web Vitals integrados desde el primer día, para que no tenga que correr a arreglar cosas tras el lanzamiento.

Preguntas frecuentes

¿Qué son los Core Web Vitals?

Los Core Web Vitals son tres métricas concretas que Google utiliza para medir la experiencia de usuario: LCP (velocidad de carga), INP (interactividad) y CLS (estabilidad visual). Forman parte de las señales de posicionamiento de experiencia de página de Google e influyen directamente en cómo se comporta su web en los resultados de búsqueda.

¿Afectan los Core Web Vitals al posicionamiento SEO?

Sí. Los Core Web Vitals son un factor de posicionamiento confirmado de Google. Aunque la calidad del contenido sigue siendo la señal principal, unos mejores Core Web Vitals pueden darle ventaja sobre competidores con contenido similar. Piénselo como el desempate.

¿Qué reemplazó a First Input Delay (FID)?

Interaction to Next Paint (INP) reemplazó a FID en marzo de 2024. A diferencia de FID, que solo medía el retardo de la primera interacción, el INP mide la capacidad de respuesta a lo largo de todas las interacciones durante una visita a la página, lo que da una imagen mucho más completa de cómo se siente realmente usar su web.

¿Qué es una buena puntuación de LCP?

Google considera “bueno” un LCP de 2,5 segundos o menos. Entre 2,5 y 4 segundos necesita mejora, y más de 4 segundos se clasifica como deficiente. Para la mayoría de los sitios, optimizar las imágenes y el tiempo de respuesta del servidor son las maneras más rápidas de mejorar el LCP.

¿Con qué frecuencia debería comprobar mis Core Web Vitals?

Como mínimo, una vez al mes. Si está haciendo cambios de rendimiento de forma activa, compruébelo semanalmente. El informe de Core Web Vitals de Google Search Console es la mejor herramienta para la monitorización continua, ya que rastrea datos de usuarios reales a lo largo del tiempo y marca las regresiones automáticamente.