Core Web Vitals: Mide y mejora el rendimiento web

Has creado una aplicación web moderna, pero los usuarios se quejan de que va lenta. Es posible que también se resientan las clasificaciones en los buscadores. Las Core Web Vitals (CWV) son las métricas de Google para la experiencia de usuario: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS). Esta guía te muestra cómo medirlas con precisión y mejorarlas de forma efectiva.

¿Qué son las Core Web Vitals?

Las Core Web Vitals son tres métricas que cuantifican aspectos clave de la experiencia de usuario:

• LCP mide el rendimiento de carga. Marca cuándo el elemento de contenido más grande (imagen, bloque de texto, vídeo) se hace visible. El objetivo es ≤2,5 segundos.
• INP mide la capacidad de respuesta. Captura la latencia de todas las interacciones (clics, toques, pulsaciones de teclas) e informa del retraso en el peor caso (o casi el peor). El objetivo es ≤200 milisegundos.
• CLS mide la estabilidad visual. Cuantifica los cambios de diseño inesperados durante la carga. El objetivo es ≤0,1.

Estas métricas se miden en campo (a partir de usuarios reales) y en laboratorio (en entornos controlados). Ambas importan.

Cómo medir las Core Web Vitals

Necesitas datos tanto de campo como de laboratorio para diagnosticar problemas.

Datos de campo (monitorización de usuarios reales)

Los datos de campo reflejan las experiencias reales de los usuarios en distintos dispositivos y redes. Utiliza estas fuentes:

• Chrome User Experience Report (CrUX): conjunto de datos público de métricas de usuarios reales para millones de sitios. Accede a través de PageSpeed Insights o la API de CrUX.
• Google Search Console: el informe de Core Web Vitals muestra grupos de URL que necesitan atención según los datos de CrUX.
• Biblioteca JavaScript Web Vitals: añade la biblioteca web-vitals a tu sitio y envía las mediciones a tu endpoint de analítica.

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

function sendToAnalytics(metric) {
  const body = JSON.stringify(metric);
  navigator.sendBeacon('/analytics', body);
}

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

Datos de laboratorio (pruebas sintéticas)

Las herramientas de laboratorio simulan la carga en un entorno controlado, lo que las hace ideales para depurar e integrar en CI.

• Lighthouse: integrado en Chrome DevTools, disponible como CLI e integrado en PageSpeed Insights. Informa de métricas de laboratorio y oportunidades de mejora.
• WebPageTest: pruebas avanzadas con condiciones de red personalizadas y filmstrips.
• Panel Performance de Chrome DevTools: graba y analiza el rendimiento en tiempo de ejecución, incluidas las tareas largas que afectan al INP.

Buena práctica: usa datos de laboratorio para identificar correcciones y datos de campo para validar el impacto.

Mejorar Largest Contentful Paint (LCP)

El LCP suele estar dominado por la imagen principal o un bloque de texto grande. Optimiza estos elementos:

1. Optimiza el recurso LCP: comprime imágenes (usa WebP/AVIF), sirve tamaños responsivos con srcset y precarga la imagen LCP si es crítica.
2. Elimina los recursos que bloquean el renderizado: inserta el CSS crítico en línea y difiere el CSS y JavaScript no críticos.
3. Mejora el tiempo de respuesta del servidor (TTFB): usa una CDN, habilita el almacenamiento en caché y optimiza las consultas del backend.
4. Reduce el renderizado en el lado del cliente: para SPAs, considera el renderizado en el servidor (SSR) o la generación estática para la vista inicial.

Ejemplo: precargar la imagen LCP:

<link rel="preload" as="image" href="/hero.avif" imagesrcset="/hero-480.avif 480w, /hero-800.avif 800w" imagesizes="(max-width: 600px) 480px, 800px">

Mejorar Interaction to Next Paint (INP)

El INP mide el retraso entre una interacción del usuario y el siguiente pintado. Las tareas largas y el JavaScript pesado son los culpables habituales.

1. Divide las tareas largas: usa setTimeout, requestIdleCallback o la API del scheduler para ceder el hilo principal.
2. Optimiza los manejadores de eventos: aplica debounce o throttle a los manejadores costosos; evita el layout thrashing.
3. Reduce el tiempo de ejecución de JavaScript: divide el código, aplica tree-shaking y difiere los scripts no críticos.
4. Usa web workers para trabajo intensivo de CPU.

Ejemplo: ceder el hilo principal:

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();
  }
  return new Promise(resolve => setTimeout(resolve, 0));
}

async function handleClick() {
  // ... do some work
  await yieldToMain();
  // ... continue
}

Mejorar Cumulative Layout Shift (CLS)

El CLS se produce cuando los elementos se desplazan inesperadamente. Evítalo así:

• Incluye siempre los atributos width y height en imágenes y vídeos, o usa la propiedad CSS aspect-ratio.
• Reserva espacio para contenido dinámico (anuncios, embeds, iframes) con min-height o placeholders.
• Evita insertar contenido por encima del contenido existente a menos que lo active una interacción del usuario.
• Usa font-display: optional o precarga las fuentes para evitar cambios por FOIT/FOUT.

Ejemplo: reservar espacio para un anuncio:

<div>
  <!-- ad loads here -->
</div>

Herramientas y flujo de trabajo para la mejora continua

El rendimiento no es una solución puntual. Integra la medición en tu flujo de trabajo:

• Establece presupuestos: usa Lighthouse CI para imponer umbrales en las pull requests.
• Monitoriza los datos de campo: configura paneles con CrUX o tu propio RUM.
• Prioriza las correcciones: céntrate en las métricas con mayor diferencia respecto a los umbrales de 'bueno'.
• Prueba en dispositivos reales: emula dispositivos móviles de gama media para detectar problemas.

Para una comprobación rápida, pasa tu página por PageSpeed Insights; combina datos de laboratorio y de campo.

Preguntas frecuentes

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

LCP: bueno ≤2,5 s, necesita mejorar ≤4 s, malo >4 s. INP: bueno ≤200 ms, necesita mejorar ≤500 ms, malo >500 ms. CLS: bueno ≤0,1, necesita mejorar ≤0,25, malo >0,25.

¿Con qué frecuencia se actualizan los datos de CrUX?

Los datos de CrUX se actualizan a diario, pero el conjunto de datos refleja una ventana móvil de 28 días. Search Console se actualiza periódicamente.

¿Puedo mejorar las Core Web Vitals sin cambiar mi diseño?

Sí. Muchas mejoras son técnicas: optimizar imágenes, diferir scripts, reservar espacio para contenido dinámico y reducir el trabajo del hilo principal.

¿Listo para analizar el rendimiento de tu sitio? Usa nuestro analizador de logs de Nginx para identificar respuestas lentas del servidor que afectan al TTFB y al LCP.