WPO: Todo sobre las Core Web Vitals

Las Core Web Vitals son una obsesión para muchos SEOs y profesionales del sector. Estas métricas no son una meta en sí mismas. Nos indican que hay algo que revisar, pero no nos explican el porqué ni el cómo solucionarlo.

Optimizar un sitio web no debería reducirse a «pasar el test de PageSpeed». Lo importante es entender qué elementos afectan realmente la experiencia de los usuario. ¿Por qué la web carga lenta? ¿Dónde se están bloqueando los recursos? ¿Qué parte del layout genera saltos visuales? Es ahí donde hay que poner el foco.

Una página vacía de contenidos puede obtener un 100 en rendimiento, pero eso no significa que esté bien optimizada.

Las puntuaciones, por sí solas, no dicen mucho si no sabemos interpretarlas correctamente. 

Qué son las Core Web Vitals

Las Core Web Vitals son un conjunto de métricas creadas por Google que miden la experiencia de usuario real en una página web, especialmente en términos de velocidad, interactividad y estabilidad visual. Son parte del sistema de evaluación de calidad de páginas que Google utiliza para el posicionamiento en los resultados de búsqueda.

📊 ¿Qué miden exactamente?

✅ LCP (Largest Contentful Paint)

• ¿Qué es?
  Mide el tiempo que tarda en aparecer el elemento de contenido más grande visible dentro de la ventana del navegador (por ejemplo, una imagen grande, un bloque de texto, etc.).
• ¿Qué evalúa?
  La velocidad de carga percibida. Un buen LCP significa que el contenido principal aparece rápido y el usuario no se queda esperando.
• Umbrales:
  • Bueno: ≤ 2.5 segundos
  • Necesita mejorar: entre 2.5 y 4 segundos
  • Malo: > 4 segundos

📉 Ejemplo de mal LCP: una landing con un slider gigante que se carga desde un servidor lento.

✅ CLS (Cumulative Layout Shift)

• ¿Qué es?
  Mide cuánto se mueven visualmente los elementos de la página mientras carga, sin que el usuario lo espere (por ejemplo, cuando vas a hacer clic en un botón y otro elemento lo empuja hacia abajo).
• ¿Qué evalúa?
  La estabilidad visual. Un bajo CLS indica que el contenido no salta o cambia de lugar de forma inesperada.
• Umbrales:
  • Bueno: ≤ 0.1
  • Necesita mejorar: entre 0.1 y 0.25
  • Malo: > 0.25

📉 Ejemplos de mal CLS: fuentes que cargan tarde (fenónemos FOUT y FOIT), imágenes sin altura definida, banners que se insertan de golpe.

✅ INP (Interaction to Next Paint) – Reemplazó a FID en marzo de 2024

• ¿Qué es?
  Mide el tiempo que tarda la página en reaccionar a una interacción del usuario (clic, toque, teclado) desde que se realiza hasta que aparece una respuesta visual.
• ¿Qué evalúa?
  La capacidad de respuesta de la web. A diferencia de FID (que solo medía la primera interacción), INP evalúa la experiencia interactiva durante toda la visita.
• Umbrales:
  • Bueno: ≤ 200 ms
  • Necesita mejorar: entre 200 y 500 ms
  • Malo: > 500 ms

📉 Ejemplos de mal INP: una página con JavaScript pesado que bloquea la respuesta a interacciones.

⚠️ Importante: Adiós FID, hola INP

Google eliminó la métrica FID (First Input Delay) en marzo de 2024 y la reemplazó por una nueva: INP (Interaction to Next Paint), la que acabamos de ver.

• FID medía el tiempo desde que el usuario interactuaba (como hacer clic) hasta que el navegador empezaba a procesar esa acción.
• INP es más completa: evalúa todas las interacciones de la página, no solo la primera, y mide cuánto tarda en producirse una respuesta visible.

Este reemplazo se debe a que INP refleja mejor la experiencia real del usuario en sitios complejos o con múltiples interacciones.

¿Qué es la puntuación de rendimiento de Lighthouse?

Es un promedio ponderado de varias métricas clave de carga y experiencia de usuario, que da como resultado una puntuación de 0 a 100. 

Algunas claves que tenemos que entender sobre este análisis son que:

• No refleja la velocidad real que experimentan los usuarios, sino un análisis técnico en condiciones simuladas.
• Google evalúa la velocidad de tu web usando métricas reales recogidas en los últimos 28 días (si hay datos suficientes). Esto sí influye directamente en SEO.
• PageSpeed Insights es una herramienta de diagnóstico, no una medida definitiva del rendimiento. 
• Las puntuaciones pueden variar en función del dispositivo que usemos, extensiones del navegador, nuestro antivirus, pruebas A/B, etc.

¿PageSpeed Insights es diferente para escritorio y móvil?

Sí. Desde Lighthouse v6, se usan curvas distintas para escritorio y móvil, porque antes las puntuaciones en desktop estaban infladas artificialmente.

¿Cuál es la importancia de cada métrica de Core Web Vitals?

Métrica	Peso en la puntuación
First Contentful Paint (FCP)	10%
Speed Index	10%
Largest Contentful Paint (LCP)	25%
Total Blocking Time (TBT)	30%
Cumulative Layout Shift (CLS)	25%

 

Cómo interpretar y usar los datos de PageSpeed Insights

PageSpeed y Search Console están para ayudarnos a detectar problemas, no para obsesionarnos con una puntuación numérica. Usa los informes para entender qué está afectando a la web, revisa qué carga tarde, qué bloquea la interacción y dónde se descoloca el diseño. Lo que importa no es sacar un 100, sino que la web vaya rápida.

Informe de Core Web Vitals en Google Search Console

El informe de Core Web Vitals en Google Search Console es una herramienta que muestra datos reales sobre cómo los usuarios experimentan la velocidad y la usabilidad de tu sitio web.

Este informe se basa en datos de campo recopilados de usuarios reales que visitan tu página en los últimos 28 días, siempre que haya suficiente información para que los datos sean fiables. Mide las tres métricas principales de Core Web Vitals que ya hemos visto en este artículo (LCP, CLS & INP).

El informe clasifica las páginas en tres categorías: Bueno, Necesita mejorar y Malo, según los umbrales establecidos por Google. Así, puedes identificar qué URLs necesitan atención para mejorar la experiencia del usuario.

A diferencia de herramientas como PageSpeed Insights, que hacen simulaciones, el informe de Core Web Vitals en Search Console refleja el rendimiento real y vivido por los usuarios, lo que lo convierte en un recurso esencial.

Caso práctico: Análisis y mejora del CLS en un E-commerce

Contexto:

Detectamos en un e-commerce que muchas páginas de producto tienen un CLS alto, lo que indica que los elementos visuales (imágenes, botones, textos…) se mueven inesperadamente mientras la página carga. Esto puede causar frustración en los usuarios que intentan hacer clic en un botón que de repente cambia de lugar.

Análisis:

Al revisar la página con herramientas como Lighthouse y el informe de Core Web Vitals en Search Console, vemos que estos saltos visuales son provocados por tres problemas principales:

• Problema 1: Imágenes sin dimensiones definidas en el HTML, lo que hace que el navegador no reserve espacio para ellas mientras cargan.

• Problema 2: Fuentes web que cargan después del contenido (fenómenos FOUT o FOIT), causando cambios en el tamaño del texto y desplazamiento del layout.

• Problema 3: Contenido cargado de forma asincrónica, como widgets o recomendaciones, que empujan hacia abajo otros elementos visibles.

Soluciones:

• Problema 1: Imágenes sin dimensiones definidas en el HTML, lo que hace que el navegador no reserve espacio para ellas mientras cargan.
• Solución: Definir el ancho y alto exacto en los atributos HTML de las imágenes para que el navegador tenga en cuenta ese espacio desde el inicio.

Técnicas a utilizar:

• Añadir siempre los atributos width y height con las dimensiones reales de la imagen en píxeles.

<img src=»producto.jpg» width=»600″ height=»400″ alt=»Producto Uno»>

• Uso de CSS para mantener proporción: Si usas imágenes responsive, asegúrate de mantener la relación de aspecto para que el espacio reservado se ajuste correctamente en diferentes dispositivos. Una técnica común es usar el contenedor con aspect-ratio o relleno proporcional para reservar el espacio.

 

• Problema 2: Fuentes web que cargan después del contenido (fenómenos FOUT o FOIT), causando cambios en el tamaño del texto y desplazamiento del layout.
• Solución: Usar técnicas de carga de fuentes que minimicen el cambio de estilo (font-display: swap y uso de preload). Te lo cuento en detalle en mi artículo SEO para tipografías. 

Las fuentes web a menudo tardan en cargarse, y mientras tanto el navegador puede mostrar un texto invisible (FOIT, Flash of Invisible Text) o cambiar la fuente del texto visible cuando la fuente definitiva carga (FOUT, Flash of Unstyled Text). Esto genera cambios en el tamaño y posición del texto, provocando saltos visuales.

Técnicas para minimizar este efecto:

• font-display: swap: Es una propiedad CSS que indica al navegador que muestre una fuente de sistema (fallback) mientras carga la fuente web, evitando que el texto desaparezca y reduciendo cambios bruscos.

• Precarga de fuentes: Le indica al navegador que descargue las fuentes clave lo antes posible, reduciendo el tiempo de carga y el cambio de estilo.

• Problema 3: Contenido cargado de forma asincrónica, como widgets o recomendaciones, que empujan hacia abajo otros elementos visibles.
• Solución: Prioriza la carga del contenido principal y cargar widgets o elementos secundarios de forma diferida, para que no afecten la estabilidad visual inicial.

Técnicas de mejora:

• Carga diferida (lazy loading) o asíncrona de scripts: Usa atributos defer o async en tus etiquetas <script>, o técnicas de lazy loading para cargar estos elementos solo cuando el contenido principal ya esté disponible.

<script src=»widget.js» defer></script>

• Renderizar el contenido principal primero: Prioriza el HTML, CSS y scripts que muestran la información esencial del sitio web para que el usuario vea la página estable rápido.
• Reserva de espacio para widgets: Asigna un contenedor con dimensiones fijas para los widgets que se cargarán después, para evitar que empujen el contenido principal cuando aparezcan.