LCP, INP y CLS: qué miden y con qué umbrales se evalúan

Los Core Web Vitals son tres números: LCP mide cuánto tarda en aparecer el contenido principal, INP cuánto tarda la página en responder cuando la tocas y CLS cuánto se mueve el diseño sin que nadie lo pida. Cada uno tiene dos umbrales que separan «bueno», «necesita mejora» y «malo». Lo que suele confundir no son los umbrales, sino cómo se aplican: sobre visitas reales, en el percentil 75 y por separado en móvil y escritorio.

La tabla de umbrales

Estos son los valores que publica web.dev. Desde el 12 de marzo de 2024, INP sustituye a FID (First Input Delay) como métrica de respuesta.

Una página «aprueba» la evaluación cuando las tres métricas están en la franja buena en el percentil 75. Si LCP y CLS van bien pero INP está en 240 ms, la página no aprueba: no hay compensación entre métricas.

Percentil 75, móvil y escritorio por separado

web.dev recomienda medir el percentil 75 de las cargas de página, segmentando entre móvil y escritorio. Dicho de otro modo: al menos tres de cada cuatro visitas deben tener una experiencia buena. No se usa la media porque unas pocas visitas muy lentas la arrastran, ni la mediana porque esconde a la mitad de los usuarios.

Los datos de campo de Google (el informe CrUX, que alimenta PageSpeed Insights y Search Console) agregan visitas reales de Chrome durante una ventana móvil de 28 días. Por eso un cambio que subas hoy tarda semanas en reflejarse del todo. Y por eso la misma URL puede aprobar en escritorio y suspender en móvil: son dos poblaciones distintas, con redes y procesadores distintos. Si quieres entender la diferencia entre estos datos y los de laboratorio, está explicada en cómo montar un experimento web.

Esta última observación es la parte útil del ejemplo: el p75 lo mueven las visitas «medianamente lentas», no los casos extremos. A menudo corresponden a móviles de gama media con redes corrientes, no a casos extremos como un usuario en un túnel.

LCP: qué elemento cuenta

LCP registra el momento en que se pinta el elemento visible más grande del área visible (viewport). Según web.dev, los candidatos son:

• elementos <img> (en GIF o PNG animados cuenta el primer fotograma);
• elementos <image> dentro de un <svg>;
• elementos <video>: la imagen de póster o el primer fotograma;
• elementos con imagen de fondo cargada con url() (los degradados CSS no cuentan);
• elementos de bloque que contienen nodos de texto.

Chrome excluye además elementos con opacidad 0, elementos que cubren todo el viewport (se interpretan como fondo) e imágenes de baja entropía, como marcadores de posición borrosos. El tamaño que cuenta es el visible en la carga inicial: si un elemento está recortado, se usa sólo la parte dentro del viewport, y en las imágenes se toma la menor entre la dimensión intrínseca y la mostrada.

En la práctica, en un artículo de blog el LCP suele ser la imagen de portada o, si no hay imagen arriba, el primer párrafo o el titular. Conviene confirmarlo en DevTools antes de optimizar nada, porque en móvil y escritorio puede ser un elemento distinto. Si es una imagen, la mayoría de ajustes están en imágenes ligeras y sin saltos de diseño.

INP: las tres partes de una interacción

INP observa las interacciones de clic, toque y teclado durante toda la visita. El desplazamiento (scroll) y el paso del ratón por encima (hover) no cuentan. Cada interacción se divide en tres fases:

1. Retraso de entrada (input delay): desde que el usuario toca hasta que empiezan a ejecutarse los manejadores de eventos. Crece cuando el hilo principal está ocupado con otra tarea, por ejemplo un script de terceros.
2. Procesamiento (processing duration): lo que tardan en terminar los manejadores de eventos asociados a esa interacción.
3. Retraso de presentación (presentation delay): desde que terminan los manejadores hasta que el navegador pinta el siguiente fotograma con el resultado. Aquí pesan el recálculo de estilos, el diseño y el pintado.

El valor de INP de una visita es la interacción más lenta, descontando valores atípicos: según web.dev, en páginas con muchas interacciones se ignora la más lenta por cada 50, de modo que en páginas con pocas interacciones el INP es simplemente la peor. Ten presente que una visita sin ninguna interacción no aporta valor de INP.

Un ejemplo ilustrativo: un botón «Ver más» con 60 ms de retraso de entrada, 130 ms de procesamiento y 40 ms de presentación suma 230 ms, que ya cae en «necesita mejora». El retraso de entrada no lo provoca el botón en sí, sino lo que estaba ocupando el hilo principal en ese momento.

CLS: cómo se suman los saltos

Cada desplazamiento inesperado tiene una puntuación que es el producto de dos fracciones: la de impacto (qué parte del viewport ocupa el elemento que se mueve, sumando su posición antes y después) y la de distancia (cuánto se ha movido respecto a la dimensión mayor del viewport). El ejemplo de web.dev: un elemento que ocupa la mitad del viewport y baja un 25 % tiene una fracción de impacto de 0,75 y una de distancia de 0,25, así que su puntuación es 0,75 × 0,25 = 0,1875.

Desde 2021, CLS no suma todos los saltos de la visita. Los agrupa en ventanas de sesión: una ventana sigue abierta mientras haya menos de 1 segundo entre saltos y dura como máximo 5 segundos. El CLS es la puntuación de la peor ventana. Los desplazamientos que ocurren en los 500 ms posteriores a un clic, toque o pulsación de tecla se consideran esperados y no cuentan.

Qué revisar primero según la métrica que falla

Antes de tocar código, confirma en qué dispositivo falla y con qué datos. Una puntuación de laboratorio baja no significa que falle el campo, y la puntuación de PageSpeed Insights también oscila entre ejecuciones por motivos que se explican en por qué PageSpeed Insights da una puntuación distinta cada vez. Con el dato de campo delante, esta ruta ordena el trabajo:

1. Falla LCP. Identifica el elemento LCP en móvil. Si es una imagen: que esté en el HTML inicial (no inyectada por JavaScript), sin loading="lazy", con fetchpriority="high" y con un tamaño ajustado a la caja donde se muestra. Si es texto: revisa CSS y fuentes que bloquean el renderizado (ver tipografías web sin frenar la carga). En ambos casos, mira el tiempo de respuesta del servidor (TTFB), que se suma a todo lo demás.
2. Falla INP. Busca qué fase domina. Retraso de entrada alto: tareas largas en el hilo principal, a menudo scripts de terceros; divídelas o retrásalas. Procesamiento alto: el manejador hace demasiado trabajo síncrono; muestra primero la respuesta visual y aplaza el resto. Presentación alta: el DOM es grande o la interacción fuerza mucho recálculo de diseño.
3. Falla CLS. Reserva espacio para todo lo que llega tarde: width y height o aspect-ratio en imágenes y vídeos, contenedores con altura mínima para anuncios e iframes, nada de insertar banners encima del contenido ya pintado y fuentes con métricas de reserva ajustadas.
4. Fallan varias. Empieza por la que esté más lejos de su umbral en proporción, y vuelve a medir con datos de campo después de 28 días antes de pasar a la siguiente.