Core Web Vitals en 2026: umbrales oficiales, herramientas de medición y prioridades de optimización

Tres métricas siguen determinando cómo evalúa Google la experiencia de usuario: LCP, INP y CLS. Sus umbrales de «bueno», «mejorable» y «deficiente» no han cambiado desde la última actualización de la documentación oficial de web.dev, pese a los rumores persistentes de un endurecimiento durante 2026. Lo que sí cambia es la facilidad con la que una auditoría mal planteada produce un diagnóstico erróneo — y orienta el esfuerzo de optimización en la dirección equivocada.

#Las tres métricas y sus umbrales oficiales

Cada métrica se evalúa en el percentil 75 de las cargas de página, distinguiendo entre móvil y escritorio. Un sitio solo es «bueno» en una métrica si el 75 % de sus visitas reales queda por debajo del umbral «bueno», no si su media lo está.

El INP sustituyó al FID (First Input Delay) como métrica oficial de capacidad de respuesta en marzo de 2024. A diferencia del FID, que solo medía el retraso antes de procesar la primera interacción, el INP observa todas las interacciones de una sesión y se queda con el peor valor representativo — un cálculo mucho más exigente para interfaces con mucho JavaScript.

#Medir bien: datos de campo frente a datos de laboratorio

La confusión más habitual consiste en auditar un sitio únicamente con Lighthouse o PageSpeed Insights en modo «laboratorio» y anunciar después una puntuación, cuando en realidad Google clasifica las páginas según datos de campo procedentes del Chrome User Experience Report (CrUX) y de usuarios reales que han consentido el envío de telemetría.

• Datos de laboratorio (Lighthouse, WebPageTest): una simulación reproducible en una máquina y una red estandarizadas. Útil para depurar, no para evaluar el impacto en el posicionamiento.
• Datos de campo (informe «Métricas web esenciales» de Search Console, pestaña «experiencia real del usuario» de PageSpeed Insights, CrUX directamente): solo estos reflejan lo que Google realmente usa para posicionar.

Un sitio puede mostrar una puntuación excelente en Lighthouse en local y seguir calificado como «deficiente» en INP en producción, simplemente porque sus visitantes reales usan dispositivos de gama baja o una conexión móvil deficiente que la prueba de laboratorio nunca reproduce.

#Reducir el LCP

El LCP mide el tiempo que tarda en renderizarse el elemento visible más grande del viewport inicial — normalmente una imagen principal, un titular o un bloque de texto. Las palancas más eficaces, por orden habitual de impacto:

• Precargar el recurso crítico con <link rel="preload"> en lugar de dejar que el navegador lo descubra tarde.
• Servir imágenes ya dimensionadas y comprimidas en AVIF o WebP, con fetchpriority="high" en el elemento LCP.
• Reducir el tiempo de respuesta del servidor (TTFB), a menudo descuidado aunque marca el punto de partida de toda la cronología.
• Eliminar los recursos que bloquean el renderizado (CSS y JavaScript síncronos) por encima del pliegue.

#Reducir el INP

El INP se degrada cuando el hilo principal permanece ocupado demasiado tiempo tras una interacción — un clic, una pulsación de tecla, un toque — antes de que el navegador pueda pintar el resultado. La solución casi nunca consiste en «acelerar» una función aislada, sino en fragmentar el trabajo para que el hilo principal pueda respirar:

import {onINP} from 'web-vitals';

onINP((metric) => {
  // Registra cada interacción medida, con el elemento responsable
  console.log('INP:', metric.value, metric.attribution.interactionTarget);
  navigator.sendBeacon('/analytics/web-vitals', JSON.stringify(metric));
});

La biblioteca oficial web-vitals expone un campo attribution que identifica el elemento del DOM responsable de la interacción más lenta — a menudo más útil para depurar que una puntuación aislada de Lighthouse. Las soluciones habituales incluyen fragmentar tareas largas con scheduler.yield(), aplazar el JavaScript no crítico hasta después de la primera interacción del usuario, y reducir el trabajo de renderizado que provoca cada actualización de estado.

#Estabilizar el CLS

El CLS penaliza los desplazamientos de diseño inesperados tras el primer renderizado: una imagen sin dimensiones reservadas, un cambio de fuente que llega tarde, un banner publicitario insertado sobre contenido que el usuario ya ha empezado a leer. Reservar el espacio de antemano, con atributos width/height explícitos o un diseño CSS Subgrid con pistas dimensionadas previamente, evita la mayoría de las regresiones. Para las animaciones, conviene limitarse a transform y opacity, que nunca provocan un recálculo del diseño — un principio central en las buenas prácticas detalladas en la guía sobre animaciones CSS controladas por el scroll, donde el más mínimo salto de diseño rompe el efecto tanto como la puntuación.

Un sitio puede mostrar una puntuación excelente en Lighthouse en local y seguir clasificado como «deficiente» en producción: solo los datos de campo cuentan para el posicionamiento.

#Priorizar con los datos de CrUX

Antes de lanzar una reconstrucción, conviene saber si el problema afecta a todo el sitio o a una sola plantilla. El conjunto de datos público de CrUX, consultable gratuitamente mediante BigQuery o la API CrUX History, permite seguir la evolución mensual de las tres métricas por origen o por URL, segmentada por tipo de conexión efectiva (4G, 3G) y por tipo de dispositivo. Comparar la propia tendencia con la de un competidor directo, en el mismo periodo, ayuda a distinguir una regresión específica del sitio de un efecto estacional más amplio (un cambio en el comportamiento de los dispositivos, saturación de un CDN compartido, etc.).

Para evitar que una regresión pase inadvertida entre dos auditorías mensuales, un presupuesto de rendimiento fijado directamente en la integración continua sigue siendo el método más fiable: la compilación falla si el LCP simulado supera un umbral establecido, antes incluso de llegar a producción.

{
  "ci": {
    "assert": {
      "assertions": {
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}],
        "total-blocking-time": ["warn", {"maxNumericValue": 300}]
      }
    }
  }
}

Esta configuración de Lighthouse CI no sustituye a la medición de campo — sigue siendo una red de seguridad de laboratorio — pero evita que una regresión evidente (una imagen sin comprimir colada en un commit, un script de terceros añadido sin async) llegue a producción sin que nadie se dé cuenta.

#Lo que hay que recordar

Los umbrales en sí son estables y están bien documentados; lo que marca la diferencia es la disciplina de medición. Auditar con datos de campo, aislar la plantilla de página realmente responsable antes de actuar, y tratar el LCP, el INP y el CLS como tres problemas distintos, con palancas técnicas distintas, en lugar de como una única puntuación que hacer subir.

Para profundizar: la documentación oficial y la metodología completa están disponibles en web.dev.