Core Web Vitals: Mide y mejora el rendimiento web

Has creado un sitio web rápido, pero los usuarios siguen quejándose de la lentitud. O quizás tu posicionamiento en SEO bajó tras una actualización de Google. El culpable podrían ser las Core Web Vitals, un conjunto de métricas que Google utiliza para medir la experiencia real del usuario. Ignorarlas puede perjudicar tanto la satisfacción del usuario como la visibilidad en las búsquedas.

En esta guía aprenderás qué son las Core Web Vitals, cómo medirlas con precisión y pasos prácticos para mejorar cada métrica. Nos centraremos en las tres métricas actuales: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS).

¿Qué son las Core Web Vitals?

Las Core Web Vitals son un subconjunto de las Web Vitals que Google considera esenciales para ofrecer una gran experiencia de usuario. Cuantifican la rapidez con la que se carga el contenido, la capacidad de respuesta de la página a las interacciones y su estabilidad visual.

Google utiliza estas métricas como señal de posicionamiento, pero lo más importante es que reflejan problemas reales de los usuarios. Un LCP lento frustra a los usuarios que esperan el contenido; un INP alto hace que la página se sienta lenta; un CLS alto provoca clics erróneos y molestias.

Las tres Core Web Vitals

• Largest Contentful Paint (LCP): Mide el rendimiento de carga. Marca el momento en que el elemento de contenido más grande (imagen, vídeo o bloque de texto) se hace visible. Un LCP bueno es de 2,5 segundos o menos.
• Interaction to Next Paint (INP): Mide la capacidad de respuesta. Registra la latencia de todas las interacciones (clics, toques, pulsaciones de teclas) y reporta un único valor. Un INP bueno es de 200 milisegundos o menos.
• Cumulative Layout Shift (CLS): Mide la estabilidad visual. Cuantifica los cambios de diseño inesperados durante la carga. Un CLS bueno es de 0,1 o menos.

Estos umbrales se basan en datos de campo de usuarios reales, no en pruebas de laboratorio. Google los evalúa en el percentil 75 de las cargas de página, lo que significa que el 75 % de las experiencias de usuario deben cumplir el umbral "bueno".

Cómo medir las Core Web Vitals

Necesitas tanto datos de laboratorio como de campo. Las herramientas de laboratorio simulan una única carga de página en condiciones controladas, mientras que los datos de campo (Real User Monitoring, RUM) capturan las experiencias reales de los usuarios en distintos dispositivos y redes.

Herramientas de laboratorio

• Lighthouse: Integrado en Chrome DevTools, audita el rendimiento y proporciona puntuaciones para LCP, CLS y total blocking time (TBT), que se correlaciona con INP. Ejecútalo en modo incógnito para evitar que las extensiones distorsionen los resultados.
• PageSpeed Insights: Combina datos de laboratorio (Lighthouse) y de campo (CrUX). Úsalo para ver tanto tus puntuaciones de laboratorio como las métricas de usuarios reales.
• WebPageTest: Ofrece pruebas avanzadas desde múltiples ubicaciones y dispositivos. Proporciona filmstrips y gráficos waterfall para diagnosticar problemas de carga.

Herramientas de campo

• Chrome User Experience Report (CrUX): Un conjunto de datos público de métricas de usuarios reales de Chrome. Disponible a través de PageSpeed Insights, el panel de CrUX o BigQuery.
• Google Search Console: Muestra el estado de las Core Web Vitals de tu sitio según los datos de CrUX. Agrupa las URL por rendimiento.
• Biblioteca JavaScript web-vitals: Una pequeña biblioteca para medir métricas en tu propio RUM. Puedes enviar datos a tu plataforma de analítica.

Así se usa la biblioteca web-vitals para registrar métricas en la consola:

import {onLCP, onINP, onCLS} from 'web-vitals';

function sendToAnalytics(metric) {
  const body = JSON.stringify(metric);
  // Use navigator.sendBeacon() or fetch() to send data
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
  fetch('/analytics', {body, method: 'POST', keepalive: true});
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Para una comprobación rápida sin programar, puedes usar herramientas online que analizan datos de rendimiento. Por ejemplo, si tienes registros del servidor, el Nginx Log Analyzer puede ayudarte a identificar respuestas lentas que podrían afectar al LCP.

Mejorar Largest Contentful Paint (LCP)

El LCP suele ser la métrica más impactante de optimizar. Le afectan el tiempo de respuesta del servidor, el tiempo de carga de recursos y el renderizado del lado del cliente.

Optimizar la respuesta del servidor

• Usa una CDN para servir contenido desde ubicaciones más cercanas a los usuarios.
• Habilita el almacenamiento en caché (del navegador y del servidor) para los recursos estáticos.
• Optimiza las consultas a la base de datos y el código del servidor para reducir el TTFB (Time to First Byte).
• Actualiza a HTTP/2 o HTTP/3 para multiplexación y conexiones más rápidas.

Optimizar los recursos

• Precarga los recursos críticos: Usa <link rel="preload"> para la imagen o fuente del LCP.
• Comprime y dimensiona correctamente las imágenes: Usa formatos modernos como WebP o AVIF y sirve imágenes responsive con srcset.
• Minifica CSS y JavaScript: Elimina caracteres y comentarios innecesarios.
• Difiere el JavaScript no crítico: Usa los atributos async o defer.
• Incluye el CSS crítico en línea: Coloca los estilos de la parte superior directamente en el HTML para evitar peticiones que bloquean el renderizado.

Eliminar los recursos que bloquean el renderizado

El CSS y el JavaScript en el <head> bloquean el renderizado. Incluye el CSS crítico en línea y carga el resto de forma asíncrona. Para JavaScript, usa defer o async.

Mejorar Interaction to Next Paint (INP)

El INP mide el tiempo desde una interacción del usuario hasta el siguiente paint. Le influyen la ejecución de JavaScript, la gestión de eventos y el trabajo de renderizado.

Reducir el tiempo de ejecución de JavaScript

• Divide las tareas largas (más de 50 ms) usando setTimeout o requestIdleCallback.
• Usa web workers para cálculos pesados.
• Aplica debounce o throttle a los manejadores de eventos de scroll, resize e input.
• Evita scripts síncronos grandes; divide el código y carga los módulos de forma diferida.

Optimizar la gestión de eventos

• Usa listeners de eventos pasivos para eventos táctiles y de rueda para mejorar el rendimiento del scroll.
• Minimiza la manipulación del DOM; agrupa las actualizaciones y usa requestAnimationFrame.
• Reduce el alcance de los recálculos de estilo evitando selectores complejos.

Mejorar el rendimiento de renderizado

• Usa CSS will-change o transform para animaciones y activar la aceleración por GPU.
• Evita el layout thrashing leyendo y escribiendo estilos en fases separadas.

Mejorar Cumulative Layout Shift (CLS)

El CLS mide los cambios de diseño inesperados. Se producen cuando los elementos cambian de posición durante la carga, a menudo debido a imágenes sin dimensiones, anuncios o contenido inyectado dinámicamente.

Incluye siempre atributos de tamaño

Para imágenes y vídeos, establece los atributos width y height o usa CSS aspect-ratio. Esto reserva espacio y evita los desplazamientos.

<img src="#" width="800" height="600" alt="Hero">

Reserva espacio para contenido dinámico

• Usa CSS min-height para contenedores que cargan contenido de forma asíncrona (por ejemplo, anuncios, embeds).
• Evita insertar contenido por encima del contenido existente, salvo que lo active una interacción del usuario.

Usa font-display swap

Las fuentes personalizadas pueden provocar texto invisible (FOIT) o cambios de diseño cuando se cargan. Usa font-display: swap para mostrar el texto alternativo de inmediato y precarga las fuentes para reducir el tiempo de intercambio.

Reuniéndolo todo: un flujo de trabajo práctico

1. Mide: Empieza con PageSpeed Insights para obtener datos tanto de laboratorio como de campo. Identifica qué métrica necesita mejorar.
2. Diagnostica: Usa Lighthouse y el panel Performance de Chrome DevTools para encontrar cuellos de botella. Observa el waterfall, la actividad del hilo principal y los cambios de diseño.
3. Optimiza: Aplica las técnicas anteriores, priorizando los cambios que afecten a la peor métrica.
4. Prueba: Vuelve a ejecutar las pruebas de laboratorio para confirmar las mejoras. Despliega en un entorno de staging y usa RUM para monitorizar los datos de campo.
5. Monitoriza: Configura RUM continuo con la biblioteca web-vitals y alerta sobre regresiones. Usa Search Console para seguir el estado de las Core Web Vitals.

Recuerda que las optimizaciones pueden tener contrapartidas. Por ejemplo, la carga diferida de imágenes puede mejorar la carga inicial, pero perjudicar el LCP si la imagen del LCP se carga de forma diferida. Prueba siempre con usuarios reales.

Preguntas frecuentes

¿Cuáles son los umbrales actuales de las Core Web Vitals?

Para LCP, bueno es ≤2,5 s, necesita mejorar es ≤4,0 s y malo es >4,0 s. Para INP, bueno es ≤200 ms, necesita mejorar es ≤500 ms y malo es >500 ms. Para CLS, bueno es ≤0,1, necesita mejorar es ≤0,25 y malo es >0,25. Estos umbrales se evalúan en el percentil 75 de las cargas de página.

¿Con qué frecuencia debo comprobar las Core Web Vitals?

Monitoriza los datos de campo de forma continua con RUM. Revisa Search Console mensualmente para ver las tendencias generales. Ejecuta pruebas de laboratorio tras cambios importantes en el código o despliegues. Las Core Web Vitals pueden cambiar con actualizaciones de tu sitio o de scripts de terceros.

¿Puedo mejorar las Core Web Vitals sin un desarrollador?

Algunas mejoras son posibles mediante plugins o ajustes (por ejemplo, habilitar el almacenamiento en caché, optimizar imágenes). Sin embargo, las mejoras significativas suelen requerir cambios en el código, como incluir el CSS crítico en línea, diferir JavaScript o reestructurar cómo se cargan los recursos. Normalmente se necesita la ayuda de un desarrollador para el INP y las optimizaciones avanzadas del LCP.

¿Listo para analizar el rendimiento de tu servidor? Prueba nuestro Nginx Log Analyzer para identificar peticiones lentas que podrían estar afectando a tus Core Web Vitals.