Core Web Vitals sin jerga: LCP, INP y CLS explicados

Core Web Vitals son tres métricas con las que Google evalúa la experiencia de usar una página: cuánto tarda en mostrar lo principal (LCP), cuánto tarda en responder cuando la tocás (INP) y cuánto se mueve el contenido mientras carga (CLS). Un sitio “pasa” cuando las tres están en verde para la mayoría de sus visitas reales. Forman parte de las señales que usan los sistemas de ranking de Google y, traducidas del inglés técnico, son bastante sentido común.

Las tres métricas y sus umbrales

Métrica	Qué mide	Bueno	Necesita mejorar	Malo
LCP (Largest Contentful Paint)	Cuánto tarda en verse el elemento más grande de la pantalla inicial	hasta 2,5 s	2,5 a 4 s	más de 4 s
INP (Interaction to Next Paint)	Cuánto tarda la página en reaccionar visualmente a un clic, toque o tecla	hasta 200 ms	200 a 500 ms	más de 500 ms
CLS (Cumulative Layout Shift)	Cuánto se desplaza el contenido de forma inesperada	hasta 0,1	0,1 a 0,25	más de 0,25

Hay un detalle que cambia cómo se leen estos números: Google no mira el promedio, mira el percentil 75. Es decir, tres de cada cuatro visitas tienen que estar dentro del umbral “bueno”. Y lo evalúa por separado en celular y en escritorio.

LCP: cuándo aparece lo importante

El LCP no mide la carga completa, sino el momento en que se pinta el elemento más grande de la primera pantalla: casi siempre la imagen principal o el título. Es lo más parecido a la pregunta “¿ya cargó?” que se hace cualquier persona.

INP: cuánto tarda en reaccionar

INP reemplazó a FID como métrica oficial en marzo de 2024. La diferencia es importante: FID solo miraba la primera interacción, mientras que INP observa todas las de la visita (clics, toques, teclas) y se queda, a grandes rasgos, con la peor. Un menú que tarda medio segundo en abrirse arruina el INP aunque la página haya cargado rapidísimo.

CLS: cuánto se mueve la página

CLS no se mide en segundos: es un puntaje que combina cuánto espacio de la pantalla se movió y qué tan lejos. Es el botón que se corre justo cuando lo ibas a tocar porque arriba apareció un banner.

Cómo medirlos: datos de laboratorio y datos de campo

Hay dos tipos de medición y conviene no mezclarlos.

• Datos de campo: vienen de personas reales usando Chrome. Google los publica en el Chrome UX Report (CrUX), calculados sobre una ventana móvil de 28 días. Son los que cuentan para la búsqueda.
• Datos de laboratorio: una prueba simulada, en un dispositivo y una conexión definidos. Es lo que hace Lighthouse. Sirven para diagnosticar y para probar un cambio antes de publicarlo, pero no son la nota final.

Las herramientas que usamos, de menor a mayor esfuerzo:

1. PageSpeed Insights. Pegás una URL y te muestra arriba los datos de campo (si la página tiene tráfico suficiente para aparecer en CrUX) y abajo el análisis de laboratorio con recomendaciones.
2. Google Search Console. El informe de Core Web Vitals agrupa las URL del sitio por estado y por tipo de problema. Es la mejor vista de conjunto y la que conviene revisar una vez por mes.
3. Chrome DevTools. El panel Performance muestra las métricas en vivo mientras navegás y permite simular un celular lento. Es donde se encuentra la causa concreta.
4. La librería web-vitals. Para sitios con mucho tráfico, permite mandar las métricas de cada visita a la analítica propia y ver qué páginas y qué dispositivos fallan.

Dos aclaraciones que evitan confusiones frecuentes. Primero: Lighthouse no puede medir INP, porque en una prueba automática nadie interactúa; usa el Total Blocking Time como aproximación. Segundo: un puntaje de Lighthouse de 100 no garantiza Core Web Vitals en verde, ni al revés. Si tu sitio es nuevo o tiene pocas visitas, es normal que no haya datos de campo; en ese caso el laboratorio es la mejor referencia disponible.

Qué los rompe (y cómo se arregla)

Lo que arruina el LCP

• Servidor lento. Si el HTML tarda en llegar, todo lo demás arranca tarde. Pasa mucho en sitios que arman cada página consultando una base de datos.
• Imagen principal pesada o mal priorizada. Un JPG de 2 MB en la portada, o una imagen de portada con loading="lazy", que le dice al navegador que no la apure.
• CSS y JavaScript que bloquean el render. El navegador no pinta nada hasta terminar de procesarlos.
• Contenido que depende de JavaScript para aparecer. Si el título se dibuja recién cuando termina de ejecutarse un framework, el LCP espera.

Arreglos típicos: HTML pregenerado servido desde una CDN, imágenes en AVIF o WebP con el tamaño justo, fetchpriority="high" en la imagen principal y fuentes precargadas.

Lo que arruina el INP

• Demasiado JavaScript. Mientras el navegador ejecuta un script largo, no puede responder a un toque.
• Scripts de terceros. Chats, píxeles de publicidad, mapas de calor y widgets suman trabajo en cada interacción.
• Páginas con un DOM enorme. Cada cambio visual cuesta más cuando hay miles de elementos.

Arreglos típicos: cargar menos JavaScript, diferir lo que no es urgente, partir las tareas largas y revisar qué scripts de terceros siguen justificando su costo.

Lo que arruina el CLS

• Imágenes y videos sin dimensiones. Sin width y height, el navegador no reserva el espacio y el contenido salta cuando llegan.
• Banners, avisos y embeds que se insertan tarde. El aviso de cookies que empuja toda la página es el caso clásico.
• Fuentes web. Cuando la tipografía definitiva reemplaza a la de respaldo y ocupa otro ancho, el texto se reacomoda. Lo contamos en detalle en cómo elegimos la tipografía.

Arreglos típicos: declarar dimensiones o aspect-ratio, reservar el lugar de todo lo que carga después y ajustar las métricas de la fuente de respaldo.

Cuánto pesan en el posicionamiento

Menos de lo que se suele vender y más de lo que conviene ignorar. Google es explícito: la relevancia del contenido sigue mandando, y una página lenta con la mejor respuesta puede superar a una rápida que no responde nada. Pero entre resultados parecidos, la experiencia de página suma. Y hay un efecto que no depende de Google: un sitio que tarda o que salta pierde visitas antes de que lean una sola línea.

Nuestra meta

Verde en las tres, en un celular de gama media, con datos móviles. Por eso elegimos arquitecturas que traen la mayor parte resuelta de fábrica, como explicamos en por qué construimos sitios estáticos, y por eso estas métricas están en la checklist que repasamos antes de lanzar.

El siguiente paso

Pasá tu página principal por PageSpeed Insights y mirá primero la sección de datos de campo. Si alguna de las tres métricas está en amarillo o rojo, es un problema con arreglo: en nuestro servicio de performance y SEO técnico auditamos exactamente esto y lo corregimos, con medición antes y después. Si preferís que lo miremos juntos, escribinos.