Volver al blog Desarrollo Web

Core Web Vitals: cómo medirlos y qué corregir primero

Qué miden LCP, INP y CLS, por qué Lighthouse y Search Console no coinciden y en qué orden corregir cada métrica, según la documentación oficial de Google.

David López · CEO - Fundador 4 de noviembre de 2026 10 min de lectura

Un sitio puede tener buen puntaje en Lighthouse y reprobar Core Web Vitals en Search Console, o al revés. No es un error: Lighthouse carga tu página una vez, en un equipo simulado; Search Console resume lo que vivieron tus visitantes reales en las últimas semanas.

Aprobar no es trivial. Según los datos de Chrome (CrUX) de septiembre de 2026, el 55,9 % de los 18,4 millones de orígenes medidos tenía buenas Core Web Vitals. LCP es la que más falla: 68,3 % en "bueno", contra 81,7 % en CLS y 85,4 % en INP.

Esta guía explica qué miden, cómo medirlas, cuánto pesan en el buscador y qué corregir primero, según la documentación oficial de Google y Chrome revisada en noviembre de 2026.

Las tres métricas y sus umbrales

Métrica	Qué mide	Bueno	Necesita mejorar	Deficiente
LCP (Largest Contentful Paint)	Cuándo se pinta el elemento visible más grande: imagen, video o bloque de texto	hasta 2,5 s	hasta 4 s	más de 4 s
INP (Interaction to Next Paint)	Cuánto tarda la página en responder visualmente a clics, toques y teclas	hasta 200 ms	hasta 500 ms	más de 500 ms
CLS (Cumulative Layout Shift)	Cuánto se mueve el contenido de forma inesperada	hasta 0,1	hasta 0,25	más de 0,25

Tres detalles que cambian cómo se leen:

Se evalúan en el percentil 75, por separado para móvil y escritorio. Una página aprueba si las tres están en "bueno" en ese percentil. Google eligió el percentil 75 para reflejar las experiencias más frustrantes, no el promedio.
INP no es un promedio. Es la interacción más lenta de la visita, ignorando la más alta por cada 50 interacciones; como la mayoría de las visitas no llega a 50, casi siempre se reporta la peor. Desplazarse, hacer zoom o pasar el mouse por encima no cuentan.
INP reemplazó a FID el 12 de marzo de 2024. FID solo medía la primera interacción. En septiembre de 2024 FID salió de CrUX, y la biblioteca web-vitals eliminó onFID() en su versión 5, de mayo de 2025. Si tu panel todavía muestra FID, mide algo que Google ya no usa.

¿Cambió algo en 2026?

Los umbrales no. Según web.dev, las métricas estables no cambian más de una vez al año y todo cambio se anuncia en su documentación; las notas de CrUX de 2025 y 2026 no registran cambios de umbrales. Si lees que el LCP bueno bajó a 2 segundos, pide la fuente oficial: no la encontramos.

Lo nuevo: el 13 de octubre de 2026, CrUX publicó variantes experimentales de LCP, INP y CLS que incluyen las "navegaciones suaves" de las aplicaciones de una sola página (SPA). Los puntajes estables no cambian mientras se evalúan; Google apunta a sacarlas de la fase experimental en mayo de 2027, y entonces Search Console pasará a usarlas. Si tu sitio es una SPA, revísalas desde ya.

Datos de campo y de laboratorio

Datos de campo son visitas reales. La fuente de Google es CrUX: PageSpeed Insights muestra sus datos de los 28 días anteriores y el informe de Search Console también se alimenta de CrUX. Solo incluye usuarios de Chrome en escritorio y Android que cumplen ciertas condiciones (no Chrome en iOS ni Edge), y la página debe ser pública y tener suficientes visitas.

Datos de laboratorio son una carga simulada en un solo equipo y una sola red. Es lo que hace Lighthouse, y sirve para diagnosticar.

Por qué no coinciden, según web.dev:

El laboratorio carga con la caché vacía; tus visitantes recurrentes no.
Otro tamaño de pantalla o contenido personalizado cambian cuál es el elemento LCP.
Las páginas restauradas desde la caché de atrás y adelante (bfcache) cargan casi al instante y solo cuentan en campo.
En campo la gente interactúa y provoca desplazamientos que una prueba automática no dispara.
Lighthouse no puede medir INP porque nadie interactúa. Usa TBT (Total Blocking Time), que web.dev considera una aproximación razonable, no un reemplazo.

La regla oficial: si tienes ambos, prioriza con los de campo.

Cómo medir

PageSpeed Insights

Pega la URL en PageSpeed Insights. Arriba están los datos de campo; si la URL no tiene suficientes, la herramienta usa los del origen completo, así que fíjate en qué nivel estás mirando. Abajo está el diagnóstico de Lighthouse: úsalo para buscar causas, no para saber si apruebas.

Search Console

El informe Core Web Vitals agrupa URLs parecidas y les asigna el peor estado de sus métricas: CLS deficiente con LCP que necesita mejorar queda como "deficiente". Una URL solo aparece si tiene datos de LCP y de CLS. Tras corregir, pulsa "Iniciar seguimiento": la validación dura 28 días.

La biblioteca web-vitals

Para medir con tus propios usuarios, incluidos los de Safari y Firefox, usa web-vitals, de Google. Al 4 de noviembre de 2026 la versión vigente en npm es la 6.2.3:

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

function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,            // 'CLS', 'INP' o 'LCP'
    value: metric.value,
    rating: metric.rating,        // 'good', 'needs-improvement' o 'poor'
    id: metric.id,                // sirve para deduplicar reportes
    navigationType: metric.navigationType,
    page: metric.navigationURL ?? location.href,
  });
  // sendBeacon envía aunque la página se esté cerrando
  navigator.sendBeacon('/analytics', body);
}

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

Llama a cada función una sola vez por página.
Un reporte puede llegar más de una vez: CLS e INP se envían cada vez que la página pasa a segundo plano. Guarda el último valor por id. Al volver con el botón atrás llegan métricas nuevas, con otro id.
Si los valores son malos, importa desde web-vitals/attribution: cada métrica trae pistas sobre la causa, como el elemento LCP o el script que demoró una interacción.
onCLS() solo funciona en navegadores basados en Chromium; LCP e INP también se miden en Firefox y Safari.

¿Cuánto pesan en Google?

Lo que dice Google en su documentación de Search Central:

Sus sistemas de clasificación usan Core Web Vitals. Los demás aspectos de experiencia de página no ayudan directamente a posicionar, y no existe una única "señal de experiencia de página".
Google busca mostrar el contenido más relevante aunque la experiencia sea mala. Pero cuando hay mucho contenido útil para una búsqueda, una buena experiencia puede contribuir.
Un buen resultado en Search Console no garantiza el primer lugar, y perseguir un puntaje perfecto solo por SEO puede no ser el mejor uso de tu tiempo.
La evaluación es en general por página, aunque hay algunas evaluaciones a nivel de sitio.

En resumen: no compensan contenido irrelevante, pero entre resultados parecidos pueden pesar.

Qué corregir en LCP

web.dev divide el LCP en cuatro partes: tiempo hasta el primer byte (TTFB), demora en empezar a cargar el recurso, duración de la descarga y demora en pintarlo. Lo ideal es que casi todo el tiempo se vaya en TTFB y descarga, con demoras mínimas.

La imagen principal no tiene prioridad. Usa fetchpriority="high" en la imagen que probablemente sea el LCP, y en no más de una o dos. En una prueba de Google sobre Google Flights, este atributo bajó el LCP de 2,6 a 1,9 segundos.
La imagen LCP tiene carga diferida. Nunca uses loading="lazy" en ella.
El navegador la descubre tarde. Si se inserta con JavaScript, va en data-src o es un fondo CSS, ponla en el HTML inicial o precárgala con <link rel="preload">.
Recursos que bloquean el renderizado. Scripts síncronos en el <head> y CSS innecesario retrasan el primer pintado: difiere lo no crítico y usa async o defer. Desde Lighthouse 13 aparece como "Render-blocking requests".
Servidor lento. Un TTFB alto puede hacer difícil o imposible llegar a 2,5 s. web.dev sugiere 0,8 s o menos como guía: revisa el hosting, usa una CDN con caché y elimina redirecciones encadenadas.

<img src="/img/portada.webp" width="1200" height="630"
     alt="Descripción de la imagen" fetchpriority="high">

Qué corregir en INP

Una interacción tiene tres fases: demora de entrada, ejecución de los manejadores de eventos y demora hasta pintar el siguiente cuadro.

Tareas largas. Es cualquier tarea de más de 50 ms; mientras corre, el navegador no responde. Divide el trabajo y cede el control entre partes.
JavaScript de terceros. Chats, píxeles y widgets compiten por el mismo hilo. Cárgalos con async o defer salvo que sean críticos y elimina los que no aporten valor claro.
Manejadores pesados. Haz primero lo visible y deja para después lo demás, como guardar o enviar analítica.
Renderizado costoso. Un DOM muy grande o generar mucho HTML en el cliente alargan la última fase.

web.dev propone ceder con scheduler.yield() y un respaldo para navegadores sin soporte:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function guardar() {
  validarFormulario();
  mostrarIndicador();
  await yieldToMain();   // el navegador pinta antes de seguir
  guardarEnServidor();
  enviarAnalitica();
}

Qué corregir en CLS

Imágenes y videos sin dimensiones. Incluye siempre width y height, o usa aspect-ratio.
Anuncios, embebidos e iframes. Reserva su espacio con min-height o aspect-ratio. Si no llega el anuncio, deja un marcador: colapsar el hueco también desplaza.
Contenido insertado arriba. Banners y avisos que empujan el contenido: mientras más arriba, mayor suele ser el salto. Reserva el espacio o superponlos.
Fuentes web. Si la fuente final mide distinto que la de respaldo, el texto salta. Usa font-display: optional, una fuente de respaldo adecuada ajustada con size-adjust y precarga las críticas.
Animaciones. Usa transform, no top ni left.

Los desplazamientos dentro de 500 ms después de un clic, toque o tecla no cuentan, porque el usuario los espera.

Orden de trabajo

Mira los datos de campo: qué métrica falla, en qué dispositivo y en qué grupo de páginas.
Empieza por lo "deficiente" en las plantillas con más tráfico. Un arreglo en una plantilla mejora muchas URLs a la vez.
Instala web-vitals con atribución para saber qué elemento, script o interacción causa el problema.
Aplica los arreglos baratos: dimensiones en imágenes, fetchpriority en la imagen LCP, sin loading="lazy" en ella, y async o defer en scripts de terceros.
Ataca lo estructural: TTFB, tareas largas, peso de JavaScript y fuentes.
Valida en Search Console y espera los 28 días.

Lista de verificación

Revisión	Métrica
Tus paneles reportan INP, no FID	INP
La imagen LCP está en el HTML inicial, con `fetchpriority="high"` y sin `loading="lazy"`	LCP
TTFB cerca de 0,8 s o menos: hosting, CDN, caché, sin redirecciones encadenadas	LCP
Scripts de terceros con `async` o `defer`; retirados los que no aportan	INP
Imágenes y videos con `width` y `height` o `aspect-ratio`	CLS
Espacio reservado para anuncios, embebidos y banners	CLS
Medición propia con web-vitals, revisando el percentil 75 por dispositivo	Todas
Si es una SPA, revisión de las métricas experimentales con navegaciones suaves	Todas

Fuentes

Si quieres revisar las métricas de tu sitio y ordenar qué corregir primero, conversemos.