¿Qué son los Core Web Vitals? LCP, INP y CLS explicados (2026)
Todo lo que necesitas saber sobre los Core Web Vitals: métricas, umbrales, herramientas de medición y cómo aprobarlos.
Compartir
Los Core Web Vitals son tres métricas de Google que se miden en visitantes reales: Largest Contentful Paint (LCP) para la carga, bueno por debajo de 2,5 segundos; Interaction to Next Paint (INP) para la interactividad, bueno por debajo de 200 milisegundos; y Cumulative Layout Shift (CLS) para la estabilidad visual, bueno por debajo de 0,1. Google los evalúa en el percentil 75 de las visitas.
Los Core Web Vitals en resumen
Google usa los Core Web Vitals para juzgar cómo cargan, responden y se mantienen estables tus páginas. Hay tres: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS).
¿Qué son los Core Web Vitals?
Cada Core Web Vital cubre un momento de la visita. Los datos proceden de usuarios reales de Chrome:
- Carga (LCP): cuánto tarda en aparecer el contenido principal en pantalla
- Interactividad (INP): cuánto tarda la página en reaccionar a un clic, toque o pulsación de tecla
- Estabilidad (CLS): cuánto se mueve el contenido mientras carga
Las métricas cambian. En marzo de 2024, el INP sustituyó a First Input Delay (FID). El FID solo medía la espera hasta procesar la primera interacción. El INP mide cada interacción de principio a fin, y muchos más sitios suspenden.
¿Cuándo se aprueban los Core Web Vitals?
Google clasifica cada métrica como Bueno, Necesita mejorar o Pobre. Apruebas cuando al menos el 75 % de las visitas a la página en CrUX tienen un buen LCP, un buen INP y un buen CLS. Google mira primero la URL. Si esa URL tiene muy poco tráfico, recurre a un grupo de URL similares o al origen completo. PageSpeed Insights muestra el resultado arriba del todo en la página: «Core Web Vitals Assessment: Passed» o «Failed».
| Bueno | Necesita mejorar | Pobre | |
|---|---|---|---|
| Largest Contentful Paint | < 2500ms | 2500ms - 4000ms | > 4000ms |
| Interaction to Next Paint | < 200ms | 200ms - 500ms | > 500ms |
| Cumulative Layout Shift | < 0,1 | 0,1 - 0,25 | > 0,25 |
¿Por qué el percentil 75?
La mediana solo te habla de la mitad más rápida de los visitantes. Un percentil más estricto haría que unas pocas visitas desde un tren con una raya de cobertura suspendieran la página entera. El p75 se queda en el medio: tres de cada cuatro visitas tienen que ser buenas.
Tu portátil con la wifi de la oficina sirve de muy poco. Las visitas que deciden el p75 son las de teléfonos más lentos en redes móviles.
Las tres métricas Core Web Vitals
Largest Contentful Paint (LCP): carga
El Largest Contentful Paint mide la carga: el tiempo transcurrido desde el inicio de la navegación hasta que se pinta el elemento más grande del viewport.
Ese elemento debe tener contenido: una imagen (las imágenes de fondo y los pósteres de vídeo también cuentan) o un bloque de texto. En la mayoría de las páginas, el elemento LCP es la imagen hero o el encabezado principal.
Bueno es por debajo de 2,5 segundos. En la publicación de CrUX de agosto de 2026, el 68,1 % de los orígenes lo consiguió, el porcentaje más bajo de los tres.
El LCP sigue lo que ve el visitante. En cuanto el elemento más grande aparece en pantalla, la mayoría piensa que la página ya terminó, aunque sigan cargando scripts. La métrica se diseñó para responder a una sola pregunta: '¿Cuándo es visible el contenido de una página?'.
Cuando el elemento LCP tarda en aparecer, el motivo suele ser de lo más previsible. Un loading="lazy" en la imagen hero. Un hero configurado como fondo CSS, que el navegador solo descubre tras procesar la hoja de estilos. El script de un slider que debe ejecutarse antes de que se muestre la primera diapositiva. Corrige primero el descubrimiento; luego, precarga la imagen si el HTML todavía la oculta, añade fetchpriority="high" y reduce el tamaño del archivo. La guía de Largest Contentful Paint analiza las cuatro fases del LCP.
Interaction to Next Paint (INP): interactividad
El Interaction to Next Paint mide la interactividad: cuánto tarda la pantalla en actualizarse después de que el visitante haga clic, pulse o presione una tecla. El scroll y el hover no cuentan.
Cada interacción se mide desde el input, pasando por el JavaScript que ejecuta, hasta el siguiente fotograma en pantalla. La página se queda con el tiempo de su interacción más lenta. En páginas con muchas interacciones, Google descarta un caso atípico por cada 50 interacciones, lo que equivale aproximadamente al percentil 98.
Una ejecución normal de Lighthouse no puede medir el INP. Carga la página y nunca hace clic en nada. El valor de laboratorio más cercano es el Total Blocking Time. El INP suele ser mucho más bajo que el TBT, pero cuando el TBT baja, el INP suele bajar también.
A menudo, el propio manejador del clic es rápido. El main thread está ocupado con otra cosa cuando llega el clic: un tag manager, un widget de chat o un framework que todavía se está hidratando. La mayor parte de ese JavaScript se puede posponer o programar. El 85,3 % de los orígenes tuvo un buen INP en agosto de 2026, frente al 87,2 % de marzo (notas de la versión de CrUX). Es el único Core Web Vital que empeoró durante el último año. La guía de Interaction to Next Paint muestra cómo localizar las interacciones lentas.
Cumulative Layout Shift (CLS): estabilidad visual
El Cumulative Layout Shift mide la estabilidad visual: cuánto contenido visible se mueve sin que el visitante lo pida. Vas a pulsar un enlace y la página pega un salto.
Cada desplazamiento recibe una puntuación: la fracción de impacto (cuánto del viewport se ve afectado) multiplicada por la fracción de distancia (cuánto se movió el contenido en relación con el viewport). Los desplazamientos que ocurren muy seguidos se suman en una ventana de sesión. El CLS de la página es su peor ventana de sesión.
Las causas habituales: imágenes sin width ni height; anuncios, banners de cookies e incrustaciones que empujan el contenido hacia abajo al aparecer; y fuentes web más anchas o altas que su fallback. Para las fuentes, alójalas en tu servidor y elige la configuración adecuada de font-display. El CLS es la métrica que mejor resuelven la mayoría de los sitios: el 81,5 % de los orígenes tuvo un buen CLS en agosto de 2026. Más información en la guía de Cumulative Layout Shift.
¿Por qué importan los Core Web Vitals?
- Los visitantes se van. Si un botón no hace nada durante medio segundo, el usuario hace clic dos veces y abandona. Google recopiló casos de estudio de sitios que corrigieron sus Core Web Vitals y consiguieron tasas de rebote más bajas y más conversiones.
- Posicionamiento. Los Core Web Vitals son un factor de posicionamiento de Google. Uno pequeño. Si dos páginas son igual de buenas, la más rápida tiene ventaja.
- Móvil. Lo más probable es que la mayor parte de tu tráfico venga del móvil, y ahí es donde las páginas suspenden. El Web Almanac de 2025 (la última edición) detectó que un 48 % de las páginas móviles aprobaban, frente al 56 % en desktop.
- Google Ads. La experiencia de la página de destino influye en tu Quality Score. Una landing lenta lo empeora y cada clic cuesta más.
Google también documenta con exactitud cómo se mide cada métrica, hasta llegar al código del propio navegador. Para un factor de posicionamiento, eso casi nunca ocurre.
Caso de estudio de Vodafone
Vodafone Italia mejoró su Largest Contentful Paint un 31 % y consiguió un 8 % más de ventas, un 15 % más de leads y una tasa de visitas a carrito un 11 % mejor (fuente: caso de estudio de web.dev).
Field data frente a lab data
Los field data (también llamados datos de Real User Monitoring o RUM) proceden de visitantes reales, en sus propios dispositivos y redes. El dataset de CrUX de Google reúne field data de usuarios de Chrome que dieron su consentimiento. Los Core Web Vitals son exclusivamente field data.
Los lab data proceden de pruebas en un dispositivo simulado con una configuración fija. Lighthouse y WebPageTest generan lab data. Una prueba de laboratorio ofrece prácticamente el mismo resultado en cada ejecución, lo que viene muy bien para depurar. Pero no refleja lo que experimentan los visitantes.
Lighthouse marca 100, ¿por qué suspendo?
Porque Google evalúa con CrUX, y Lighthouse solo prueba una visita simulada. Tus visitantes usan móviles Android baratos y una mala wifi de hotel, y hacen clic en elementos que Lighthouse jamás toca. El INP ni siquiera existe en una ejecución de Lighthouse.
CrUX te indica si apruebas o suspendes por grupo de URL. Para averiguar qué página, dispositivo y elemento provocan el fallo, uso Real User Monitoring: CoreDash, que creé justo para esto. Desglosa los datos por dispositivo, país y plantilla de página, y señala directamente el elemento LCP o la interacción que va lenta.
Cómo medir los Core Web Vitals
Comparativa de herramientas de medición
| Herramienta | Tipo de datos | ¿Mide los CWV? | Úsala para |
|---|---|---|---|
| CrUX (Chrome User Experience Report) | Field | Sí (oficial) | Las cifras que usa Google, por origen o URL |
| PageSpeed Insights | Field + Lab | Sí (vía CrUX) | Revisión rápida: datos de CrUX más una ejecución de Lighthouse |
| Lighthouse | Solo Lab | No | Detectar problemas en una página |
| Chrome DevTools | Solo Lab | No | Analizar un trace, el waterfall y el elemento LCP |
| CoreDash (RUM) | Field | Sí | Datos de hoy, por página, dispositivo y elemento |
| Google Search Console | Field (CrUX) | Sí | Qué grupos de URL aprueban y cuáles suspenden |
Datos de CrUX
El dataset de CrUX recopila los Core Web Vitals de cada sitio con suficiente tráfico en Chrome. Es el dataset oficial del programa Web Vitals. Puedes consultarlo de varias formas:
- CrUX Vis muestra cómo ha puntuado un origen o una URL durante los últimos meses. Sustituyó al antiguo CrUX Dashboard en Looker Studio, que Google cerró a finales de 2025.
- CrUX on BigQuery incluye los datos a nivel de origen de cada sitio en CrUX, con histogramas completos por métrica y actualizaciones mensuales. Es ideal para comparar un sitio con sus competidores.
- La API de CrUX proporciona los datos por página u origen, filtrados por tipo de dispositivo y métrica, por si quieres integrar las cifras en tus propias herramientas.
- PageSpeed Insights muestra los datos de CrUX de una URL por encima de un informe de Lighthouse. Se abre en la pestaña de móvil. Quédate ahí: la pestaña de desktop suele estar en verde y hace creer a la gente que aprueba.
Monitorización con RUM
Los datos de RUM proceden de un pequeño script en tu propio sitio que mide cada visita. Mide los mismos Core Web Vitals que CrUX, pero con los detalles que CrUX deja fuera. CrUX es anónimo, se queda a nivel de URL y siempre mira los últimos 28 días. RUM te muestra el día de ayer, por página, dispositivo, país y navegador, y te indica qué elemento causó el LCP lento o el layout shift. Por eso casi todos los que nos dedicamos a optimizar Core Web Vitals usamos RUM junto con CrUX.
Lighthouse
Lighthouse no mide los Core Web Vitals. Carga una página, una sola vez, en un móvil simulado con la conexión limitada. Empieza con la caché vacía, nunca navega a una segunda página y jamás hace clic.
Aun así, sigue siendo la forma más rápida de ver qué bloquea el renderizado, qué imagen es el elemento LCP y qué scripts mantienen ocupado el main thread. Eso sí, ignora la mitad de la lista. Minificar el CSS ahorra unos pocos kilobytes y ninguno de tus visitantes lo notará.
Ejecútalo en PageSpeed Insights, en Chrome DevTools o con la herramienta de línea de comandos de Lighthouse.
¿Cuántos sitios aprueban?
El equipo de Chrome publica las cifras de CrUX cada mes, el segundo martes, en las notas de la versión de CrUX. Estos son los porcentajes de orígenes con una buena puntuación, sumando todos los dispositivos:
| Métrica | Agosto de 2025 | Agosto de 2026 | Notas |
|---|---|---|---|
| LCP | 66,7 % | 68,1 % | El más bajo de los tres; para la mayoría de los sitios, el LCP decide el aprobado |
| INP | 85,7 % | 85,3 % | Baja cada mes desde marzo; Google todavía no tiene explicación |
| CLS | 80,1 % | 81,5 % | El mejor de los tres |
| Los tres | 53,5 % | 55,6 % | Sobre 18,3 millones de orígenes |
Compara siempre el mismo mes año tras año. Diciembre oscila todos los años (el equipo de Chrome lo lleva viendo desde el lanzamiento de CrUX), así que un mal mes no dice gran cosa. Para el TTFB y el FCP, que no aparecen en las notas de la versión, consulta la guía de Time to First Byte y la guía de First Contentful Paint.
Cómo mejorar los Core Web Vitals
Por dónde empiezo: el p75 de cada métrica en móvil, luego el grupo de URL que señala Search Console y después la tendencia. Una caída repentina suele apuntar a un deploy. Un declive progresivo se debe a scripts de terceros que se van acumulando, etiqueta tras etiqueta.
Cada release puede volver a romper algo, así que sigue vigilando los field data después de publicar el fix. Además, las métricas se influyen entre sí. font-display: swap muestra el texto en pantalla antes, lo que puede ayudar al LCP; pero si la fuente web tiene un tamaño distinto al del fallback, el swap provocará un layout shift. Una guía para cada métrica:
- Cómo mejorar el Largest Contentful Paint
- Cómo mejorar el Interaction to Next Paint
- Cómo mejorar el Cumulative Layout Shift
Hay dos métricas de diagnóstico que frenan el LCP:
- Time to First Byte (TTFB): el navegador no puede empezar a procesar la página antes de que llegue el HTML. Con un TTFB lento, conseguir un buen LCP es prácticamente imposible. Cachear el HTML en tu CDN suele ser la victoria más rápida.
- First Contentful Paint (FCP): el primer renderizado de cualquier contenido. Hasta ese momento, el visitante se queda mirando una pantalla en blanco.
Para ver una lista paso a paso, consulta la Checklist de Core Web Vitals.
Core Web Vitals en Search Console
Google solía agrupar los Core Web Vitals con HTTPS, la adaptabilidad a móviles y los intersticiales intrusivos bajo la etiqueta de «page experience». Google eliminó el informe de Page Experience de Search Console en noviembre de 2024. El informe de Core Web Vitals sigue ahí, en «Experiencia».
Ese informe agrupa tus URL por plantilla y muestra qué grupos aprueban. Cubre los últimos 28 días, por lo que dos semanas después de publicar un fix, la mitad de lo que muestra todavía pertenece al sitio antiguo.
¿Necesitas una web más rápida?
Soy Arjen y llevo 17 años arreglando webs lentas. Si te encuentras con problemas que no puedes resolver por tu cuenta, envíame tu URL y hablamos.
Envíame tu URL¿Por qué no funciona nuestro fix?
A veces la CDN sigue sirviendo el HTML antiguo, o el fix se metió en la plantilla de desktop y el móvil usa otra. Envíame tu URL y el problema, y te respondo con varias opciones. Primero reviso tus field data, luego dedicamos una hora a tu web, y en menos de un día tienes mis notas por escrito. 350 € sin IVA.
Envíame tu URL¿No tienes desarrollador para hacer el fix? Hago el trabajo yo mismo, en una copia de tu web.
Preguntas frecuentes sobre Core Web Vitals
Aprender sobre los Core Web Vitals
¿Qué hay que aprender para ser un experto en Core Web Vitals?
Algunos problemas de Core Web Vitals se resuelven en cinco minutos. Otros requieren años de experiencia. Necesitas cuatro cosas.
Primero, cómo funcionan los navegadores. Analiza un trace en el panel Performance hasta que distingas parsing, style, layout y paint sin mirar las etiquetas.
Segundo, JavaScript. Paso gran parte de mi tiempo explicando a desarrolladores por qué su código es lento. El código lento perjudica al INP, y casi siempre también al LCP y al FCP.
Tercero, HTML y CSS. Casi siempre hay una forma rápida y otra lenta de maquetar el mismo componente.
Cuarto, redes y servidores: cabeceras de caché, compresión, HTTP/2 y HTTP/3. Las grandes empresas cuentan con buenos desarrolladores, y te van a preguntar por las cuatro cosas.
Cómo mejorar los Core Web Vitals
¿Funcionan los plugins para Core Web Vitals?
A veces. Hay muchos plugins que prometen mejorar los Core Web Vitals, como WP Rocket. Podría hablar horas sobre ellos, así que seré breve.
Depende de cuál sea el problema. Imágenes sin lazy loading, scripts sin diferir: eso lo arregla un plugin. Un slider que reconstruye el layout con JavaScript o un DOM con 5.000 elementos se quedan tal cual. Y el truco de «retrasar todo el JavaScript hasta la primera interacción» traslada toda esa carga al primer clic, que es justo lo que mide el INP.
Un plugin hace lo que un buen desarrollador puede resolver en pocas horas. Los problemas difíciles siguen estando ahí después.
¿Debería centrarme en móvil o en desktop?
En el móvil. Los teléfonos tienen menos ancho de banda, menos memoria y una CPU más lenta que el ordenador medio. Si apruebas en móvil, casi siempre apruebas también en desktop.
Hay excepciones. El viewport de desktop es más grande, por lo que el elemento LCP puede cambiar: en móvil suele ser un encabezado y en desktop una imagen situada más abajo. Además, en desktop hay más elementos en pantalla que pueden desplazarse, así que el CLS puede ser peor.
Medición: CrUX, RUM y datos sintéticos
Si los datos a nivel de URL no están disponibles, ¿cómo evalúa Google los Core Web Vitals?
Google consulta primero los datos de CrUX para la URL. Si esa URL tiene muy poco tráfico, Google puede recurrir a un grupo de URL similares (Search Console muestra estos grupos). Si no hay datos de grupo, utiliza los datos de todo el origen.
¿Los datos de Core Web Vitals son en tiempo real?
No, pero tampoco tienen 28 días de antigüedad. Los datos de CrUX tienen un desfase de unos dos días. Lo que ves es el p75 de los últimos 28 días, por lo que un fix publicado hoy representará mañana un solo día de 28. En un sitio que estaba al límite, el p75 puede variar en una o dos semanas. En un sitio que era lento en todas partes, dale las cuatro semanas completas. Más sobre la ventana de 28 días.
¿Por qué no hay datos en Search Console ni en ninguna otra herramienta de CrUX?
Google no tiene suficientes visitas de usuarios de Chrome en tu sitio. CrUX solo recopila datos de páginas y orígenes que superan un mínimo de tráfico. Los sitios nuevos, los pequeños y las páginas protegidas por login a menudo no tienen ningún dato.
¿Influyen las puntuaciones de Lighthouse en los Core Web Vitals?
No. Google utiliza field data de CrUX, y tu puntuación de Lighthouse no forma parte de ellos. Usa Lighthouse para detectar qué ralentiza la página. Los Core Web Vitals solo mejoran cuando los visitantes reales reciben una página más rápida.
Preguntas habituales sobre Core Web Vitals
¿Cuáles son los 3 Core Web Vitals?
Largest Contentful Paint (LCP) para la carga, bueno por debajo de 2,5 segundos; Interaction to Next Paint (INP) para la interactividad, bueno por debajo de 200 milisegundos; y Cumulative Layout Shift (CLS) para la estabilidad visual, bueno por debajo de 0,1. Una página aprueba cuando las tres métricas son buenas en el percentil 75.
¿Existe una puntuación de Core Web Vitals?
No. No existe un número único. Cada métrica es buena, necesita mejorar o es pobre en el p75, y una URL aprueba cuando las tres son buenas. La puntuación de 0 a 100 en PageSpeed Insights es la puntuación de rendimiento de Lighthouse. Esa es una puntuación de laboratorio y Google no la usa para posicionar.
¿Son los Core Web Vitals un factor de posicionamiento?
Sí, desde junio de 2021. Uno pequeño. Una página lenta con la mejor respuesta sigue superando a una rápida con una floja. Si dos páginas son igual de buenas, la que aprueba tiene ventaja.
¿Cuál es la diferencia entre field data y lab data?
Los field data proceden de visitantes reales, medidos por sus propios navegadores en sus propios dispositivos y redes. Los lab data proceden de pruebas en un dispositivo simulado, como Lighthouse o WebPageTest. Los lab data son reproducibles e ideales para depurar. Google solo utiliza field data para los Core Web Vitals, por lo que una puntuación perfecta en Lighthouse no significa que apruebes, y una mala tampoco significa que suspendas.