Core Web Vitals: Guía de Rendimiento y SEO - Ighenatt Blog

Google lleva desde 2021 usando las Core Web Vitals como señal de ranking. En la práctica, hemos visto sitios técnicamente bien construidos perder posiciones frente a competidores más lentos porque sus métricas de campo (no de laboratorio) estaban por debajo del umbral. La distinción importa: PageSpeed Insights y los datos reales de usuarios no siempre cuentan la misma historia.

Lo que pocas guías explican es que las tres métricas miden problemas distintos. LCP habla de carga. CLS habla de estabilidad. INP habla de respuesta. Atacarlos con la misma solución (“optimiza todo”) raramente funciona. Hay que identificar cuál está fallando y por qué.

Qué son las Core Web Vitals: métricas esenciales

Desde que Google las introdujo como señal de ranking en mayo de 2021, las Core Web Vitals se han convertido en la referencia técnica para medir la experiencia real de usuario. No miden velocidad en abstracto: miden tres aspectos concretos de cómo se comporta una página durante la carga y la interacción.

Las tres métricas actuales:

Largest Contentful Paint (LCP) - Carga

El LCP mide el tiempo que tarda en cargarse el contenido principal visible de una página. Para proporcionar una buena experiencia de usuario, el LCP debe ocurrir dentro de los primeros 2,5 segundos desde que la página comienza a cargarse.

<!-- Ejemplo de optimización de imagen para mejorar LCP -->
<img src="imagen-optimizada.webp" alt="Descripción" loading="eager" fetchpriority="high">

Interaction to Next Paint (INP) - Interactividad

El INP mide la latencia de todas las interacciones del usuario durante toda la visita a la página, evaluando la capacidad de respuesta general del sitio web. Un buen INP debería ser de 200 milisegundos o menos, mientras que valores entre 200-500ms necesitan mejora y más de 500ms se consideran pobres.

Nota: Google reemplazó oficialmente la métrica FID por INP en marzo de 2024, ya que INP proporciona una medición más completa de la capacidad de respuesta durante toda la experiencia del usuario.

Cumulative Layout Shift (CLS) - Estabilidad Visual

El CLS mide la suma de todos los cambios inesperados en el diseño que ocurren durante la carga de una página. Una buena puntuación de CLS es de 0,1 o menos.

/* Reservar espacio para imágenes y anuncios para evitar cambios de diseño */
.imagen-container {
  aspect-ratio: 16/9;
  width: 100%;
  height: auto;
}

Impacto en el posicionamiento y herramientas de medición

Las Core Web Vitals actúan como señal de desempate en el ranking: cuando dos páginas tienen contenido y autoridad similares, la que cumple los umbrales tiene ventaja. El impacto es especialmente visible en móvil, donde los umbrales son más difíciles de alcanzar y la diferencia de rendimiento entre sitios es mayor.

Google está experimentando con etiquetas visuales en los resultados para indicar sitios con experiencia de calidad. En nichos competitivos, ser el único en cumplir los tres umbrales puede ser el factor que inclina la balanza.

Herramientas de medición principales:

Google PageSpeed Insights combina datos de laboratorio (Lighthouse) con datos de campo reales del Chrome UX Report (CrUX), ofreciendo recomendaciones específicas para cada métrica.

Lighthouse, integrado en Chrome DevTools, proporciona auditorías detalladas de rendimiento, accesibilidad y mejores prácticas por URL.

Chrome User Experience Report (CrUX) recoge datos reales de navegadores Chrome durante 28 días. Es la fuente que usa Google Search Console y la referencia definitiva para evaluar el impacto en rankings.

Estrategias de optimización para Core Web Vitals

Mejora del LCP:

Para reducir el LCP, el orden de actuación más efectivo es: primero el elemento LCP candidato (normalmente el hero image o el H1), luego el servidor, luego los recursos que bloquean el renderizado.

• Usar WebP o AVIF en la imagen hero, con fetchpriority="high" y sin loading="lazy"
• Aplicar lazy loading al resto de imágenes que no son el elemento LCP
• Reducir el tiempo de respuesta del servidor con CDN, caching y compresión Brotli

// Ejemplo de implementación de lazy loading
document.addEventListener("DOMContentLoaded", function() {
  let lazyImages = [].slice.call(document.querySelectorAll("img.lazy"));

  if ("IntersectionObserver" in window) {
    let lazyImageObserver = new IntersectionObserver(function(entries, observer) {
      entries.forEach(function(entry) {
        if (entry.isIntersecting) {
          let lazyImage = entry.target;
          lazyImage.src = lazyImage.dataset.src;
          lazyImage.classList.remove("lazy");
          lazyImageObserver.unobserve(lazyImage);
        }
      });
    });

    lazyImages.forEach(function(lazyImage) {
      lazyImageObserver.observe(lazyImage);
    });
  }
});

Optimización del INP:

El INP alto casi siempre tiene la misma causa: Long Tasks (tareas de más de 50ms) que bloquean el hilo principal. Las soluciones concretas:

• Code splitting para reducir el JavaScript inicial que se ejecuta al cargar
• Web Workers para mover procesamiento intensivo fuera del hilo principal
• scheduler.yield() para ceder el control al navegador entre tareas largas

Optimización del CLS:

El CLS se genera por elementos que se mueven después de la carga inicial. Las causas más comunes son fáciles de prevenir:

• Especificar siempre width y height en imágenes y vídeos
• Reservar espacio fijo para banners publicitarios con contenedor de dimensiones explícitas
• Precargar fuentes personalizadas con <link rel="preload"> para evitar FOUT (flash of unstyled text)

Caso de estudio y resultados esperados

Un cliente de comercio electrónico experimentaba problemas significativos con sus Core Web Vitals. Después de implementar una serie de optimizaciones:

• Reducción del LCP de 4.2s a 1.8s
• Mejora del CLS de 0.25 a 0.05
• Disminución del INP de 350ms a 180ms

Estos cambios resultaron en:

• 22% de aumento en el tráfico orgánico
• 17% de mejora en la tasa de conversión
• 15% de reducción en la tasa de rebote

Los números del caso son ilustrativos de una realidad frecuente: los problemas de Core Web Vitals rara vez son aislados. Un LCP alto suele venir acompañado de un CLS alto, porque ambos tienen raíces similares en cómo se sirven y cargan los recursos. Atacarlos de forma sistemática (primero lo que bloquea el renderizado, luego las imágenes, luego los desplazamientos visuales) es más eficiente que ir problema a problema.

Una advertencia práctica: las puntuaciones de laboratorio en Lighthouse pueden ser perfectas en páginas que tienen CWV deficientes en campo real. La referencia para saber si el trabajo ha dado resultado es siempre el informe de Core Web Vitals en Google Search Console, que usa datos reales de CrUX de los últimos 28 días.