Core Web Vitals: qué miden LCP, INP y CLS, cómo comprobarlas gratis y cómo arreglarlas

Las Core Web Vitals (en español, «Métricas web principales») son tres medidas con las que Google comprueba si una página se nota rápida y estable: el LCP mide cuánto tarda en verse lo principal, el INP cuánto tarda en reaccionar cuando tocas algo y el CLS cuánto se mueve el contenido mientras carga. Una página aprueba cuando, en al menos el 75 % de las visitas reales, el LCP es de 2,5 segundos o menos, el INP de 200 milisegundos o menos y el CLS de 0,1 o menos¹.

Se comprueban gratis con PageSpeed Insights y con Search Console. Los fallos típicos son pocos: estilos y fuentes que retrasan la carga, scripts que dejan el navegador ocupado y bloques que aparecen sin un hueco reservado. Abajo va cada métrica sin jerga, cómo medirla y qué tocar, con un ejemplo real: la portada de esta misma web, que sale mal parada.

Qué son las Core Web Vitals y cuánto pesan en Google

Son las tres métricas que Google ha elegido como principales para medir la experiencia de una página: carga, respuesta y estabilidad. Se calculan con visitas reales de usuarios de Chrome, que el navegador envía de forma anónima, en quienes lo tienen activado, a una base de datos llamada CrUX (Chrome User Experience Report), y se miden por separado en móvil y en ordenador¹.

Lo del 75 % tiene su motivo. Google mira el percentil 75: de cada 100 visitas, 75 tienen que ir bien. Que la web vuele en tu ordenador con fibra no basta si la mayoría de tus visitas llega desde un móvil normal con una cobertura regular.

¿Cuentan para posicionar? Sí, con matices. Google dice que unas buenas métricas, junto con otros aspectos de la experiencia, se corresponden con «lo que nuestros sistemas de posicionamiento principales buscan recompensar»². Pero también que «la Búsqueda de Google siempre intenta mostrar el contenido más relevante, aunque la experiencia en la página sea deficiente», y que tener buenos resultados «no garantiza que tus páginas vayan a aparecer al principio»³.

Traducido: una página lenta con la mejor respuesta puede seguir ganando. Donde más se nota es en la gente: una página que salta o que no responde cuando tocas un botón hace que te vayas, con o sin Google de por medio.

LCP, INP y CLS: qué mide cada una y cuándo es buena

Search Console clasifica cada métrica en tres franjas⁴:

LCP (Largest Contentful Paint). El tiempo hasta que aparece lo más grande que se ve al abrir la página: casi siempre la foto de cabecera o el bloque de texto principal. En móvil, en el 76 % de las páginas ese elemento es una imagen⁵, así que la mayoría de los arreglos pasan por ella.

INP (Interaction to Next Paint). Lo que tarda la pantalla en cambiar después de que hagas algo: abrir un menú, pulsar «Añadir al carrito», escribir en un buscador. Tiene en cuenta las interacciones de toda la visita. Sustituyó el 12 de marzo de 2024 al FID (First Input Delay), que, como dice su nombre, se fijaba solo en la primera⁶. Si tu lista de Core Web Vitals es LCP, FID y CLS, está caducada.

CLS (Cumulative Layout Shift). Suma los saltos del contenido que no esperas: vas a tocar un enlace, carga un anuncio encima y acabas pulsando otra cosa. Un 0 significa que nada se mueve. Los saltos del medio segundo siguiente a un toque tuyo no cuentan, porque se dan por esperados⁷.

Aprobar las tres no es lo normal. El Web Almanac de HTTP Archive, que analiza millones de webs cada año, contó con datos de julio de 2025 que solo el 48 % las pasa en móvil (el 56 % en ordenador). La que más cuesta es el LCP⁵:

Cómo comprobar las Core Web Vitals gratis

Antes de abrir ninguna herramienta hay que separar dos tipos de datos, porque casi toda la confusión viene de mezclarlos. Los datos de campo son los de las visitas reales que recoge Chrome, y son los que usa Google para aprobarte o suspenderte. Los de laboratorio salen de una carga simulada con Lighthouse, la herramienta de auditoría de Google que viene dentro de Chrome: sirven para encontrar la causa, no son la nota que cuenta. En una simulación nadie toca la pantalla, así que el INP no se puede medir y se usa en su lugar el TBT (Total Blocking Time), el tiempo en que el navegador está demasiado ocupado para atender un toque¹.

1. PageSpeed Insights (pagespeed.web.dev). Pegas la dirección de una página y te da las dos cosas: arriba, los datos de campo, si tu web tiene visitas suficientes; abajo, el informe de Lighthouse con la lista de problemas. Empieza por móvil. La nota de 0 a 100 es de laboratorio; el aprobado que interesa es el de arriba.
2. Search Console, en Experiencia → Métricas web principales. Agrupa las páginas parecidas y te dice cuáles fallan y en qué. Con poco tráfico es normal que no salga nada: el informe no muestra los grupos sin un mínimo de datos⁴. Si nunca lo has abierto, en la guía de Google Search Console está cómo dar de alta tu web.
3. Las herramientas para desarrolladores de Chrome (F12 → Rendimiento). Miden las tres métricas mientras usas la página, también el INP al hacer clic¹. Es la forma más directa de ver qué botón tarda en responder.

Cuando arregles algo, en Search Console puedes pulsar «Validar corrección». Empieza entonces un seguimiento de 28 días, y si el problema reaparece en alguna página durante ese tiempo, la corrección se da por fallida⁴.

Lo que salió al medir esta web

Antes de escribir esto pasé Lighthouse en modo móvil por tres páginas de tato9689.com, el 29 de octubre de 2026, con la configuración por defecto: un móvil de gama media simulado, con el procesador cuatro veces más lento y 150 milisegundos de latencia de red⁸.

Los dos problemas de la portada vienen del mismo adorno: un retrato mío hecho con 1.822 cuadraditos que se montan con una animación y se inclinan siguiendo el ratón. Lighthouse atribuye a ese script 7,4 segundos de trabajo del navegador, con una tarea de casi 3 segundos seguidos en la que un toque en el menú se queda esperando. Cada cuadradito es un elemento independiente, y el script recalcula la inclinación en cada fotograma, sin parar, aunque en un móvil no haya ratón que seguir.

El CLS de 0,241, a nada de la franja mala, sale de un único salto. En móvil el retrato va encima del texto y su caja no tiene tamaño hasta que el script se ejecuta. Cuando lo hace, pasa de 0 a 284 píxeles de alto y todo el bloque de presentación baja de golpe.

Los dos artículos medidos no tienen bloqueos ni saltos. Su LCP pasa un par de décimas de los 2,5 segundos, y el elemento más grande es el texto del bocadillo con mi foto. Lo retrasa que la página espera a descargar la hoja de estilos de Google Fonts y la del sitio antes de pintar nada.

Ojo: son cifras de laboratorio, de una sola pasada y lanzadas desde mi propio servidor. Sirven para encontrar causas; si Google me aprueba o no lo deciden los datos de campo.

Cómo arreglar los fallos más comunes

La mayoría no exige programar, pero sí mirar qué señala PageSpeed para tu página concreta en vez de aplicar una lista a ciegas.

Si falla el LCP

• No cargues en diferido la imagen principal. La carga diferida (lazy loading) retrasa las imágenes hasta que el navegador cree que vas a verlas. Google lo dice sin rodeos: «Nunca cargues en diferido la imagen del LCP»⁹. Aun así lo hace entre el 16 % y el 17 % de las páginas⁵. Si usas un plugin de optimización en WordPress, comprueba que no la toca.
• Dale prioridad con fetchpriority="high", solo en una o dos imágenes: si lo marcas en todas, pierde el efecto⁹.
• Sirve las imágenes al tamaño en que se ven. El logo de la cabecera de esta web mide 729 × 796 píxeles para mostrarse a 35 × 38⁸. Son 27 KB, poca cosa, pero es el error de siempre.
• Quita lo que bloquea el pintado. Las hojas de estilo enlazadas en la cabecera retrasan el primer pintado hasta que se descargan, y con font-display: swap el texto se ve con una fuente provisional mientras llega la buena⁹.
• Revisa el servidor. El tiempo hasta el primer byte (TTFB) es una de las cuatro partes en que Google divide el LCP⁹. Medido desde el propio servidor, el de esta web contesta en 50-80 milisegundos⁸ (desde fuera será algo más), pero en un hosting compartido saturado puede ser el cuello de botella.

Si falla el INP (o el TBT)

• Busca las tareas largas. Toda tarea de más de 50 milisegundos es larga, y mientras dura el navegador no atiende clics¹⁰. PageSpeed lista los scripts que más tiempo ocupan: empieza por los de arriba.
• Quita antes de optimizar. Un chat, un mapa o una animación que nadie usa se arregla borrándolo. Lo que se queda puede cargarse cuando la página ya esté lista.
• Trocea el trabajo pesado. Para quien programa: partir la tarea y ceder el turno al navegador entre trozos, con scheduler.yield() o setTimeout, le deja atender al usuario entre medias¹⁰.
• No trabajes en cada fotograma si nada cambia. Es el fallo de mi portada. Parar el bucle cuando no hay movimiento, o pintar el retrato como una sola imagen, lo resuelve.

Si falla el CLS

• Pon ancho y alto a imágenes y vídeos, con los atributos width y height o con aspect-ratio en el CSS, para que el navegador reserve el hueco⁷. En móvil, el 62 % de las páginas tiene al menos una imagen sin medidas⁵.
• Reserva sitio para lo que llega tarde: anuncios, vídeos incrustados, avisos de cookies o bloques que mete un script. Un min-height en el contenedor evita que empujen lo demás⁷. En mi portada bastaría con fijar en el CSS el tamaño final del retrato (259 × 284 píxeles en móvil).
• Precarga las fuentes importantes, para que el cambio de la provisional a la buena no mueva el texto, y anima con transform: mover cosas cambiando top o left provoca desplazamientos⁷.

Las Core Web Vitals son una pieza del SEO técnico, que a su vez es una parte del conjunto. Para ver dónde encajan, el punto de partida es qué es el SEO.

Preguntas frecuentes

¿Las Core Web Vitals afectan al SEO?

Sí, pero no deciden solas. Google dice que unas buenas métricas, junto con otros aspectos de la experiencia, son lo que sus sistemas de posicionamiento buscan recompensar, y también que siempre intenta mostrar el contenido más relevante aunque la experiencia en la página sea deficiente.

¿Qué pasó con el FID?

El 12 de marzo de 2024 el INP sustituyó al FID como métrica de respuesta. El FID se fijaba solo en la primera interacción; el INP, en las de toda la visita. Las Core Web Vitals actuales son LCP, INP y CLS.

¿Cómo hago un test de Core Web Vitals gratis?

Con PageSpeed Insights (pagespeed.web.dev): pegas la dirección y te enseña los datos de visitas reales, si los hay, y un diagnóstico de Lighthouse. Para la web entera, el informe Métricas web principales de Search Console.

¿Por qué Search Console dice que no hay datos suficientes?

Porque el informe usa visitas reales de usuarios de Chrome y no muestra los grupos de páginas que no llegan a un mínimo de datos. Es lo habitual en webs con poco tráfico y no es un error.

¿Por qué la nota de PageSpeed no coincide con Search Console?

La nota de 0 a 100 de PageSpeed sale de una carga simulada y varía algo de una pasada a otra. Search Console usa visitas reales, que son las que cuentan para aprobar.

¿Cuánto tarda en notarse un arreglo en Search Console?

Al pulsar «Validar corrección» empieza un seguimiento de 28 días. Si el problema reaparece en alguna página durante ese tiempo, la corrección se da por fallida.