Core Web Vitals: qué son LCP, INP y CLS y cómo mejorarlos

Las Core Web Vitals son tres métricas de Google que miden, con datos de usuarios reales, la experiencia de una página: el LCP (Largest Contentful Paint) mide la carga, el INP (Interaction to Next Paint) mide la respuesta a las interacciones y el CLS (Cumulative Layout Shift) mide la estabilidad visual. Una página se considera buena cuando, en el percentil 75 de las visitas, el LCP no pasa de 2,5 segundos, el INP no pasa de 200 milisegundos y el CLS no pasa de 0,1, con móvil y escritorio evaluados por separado (web.dev). Los sistemas de clasificación de Google usan estas métricas, pero un buen resultado no garantiza posición ni pasa por delante de la relevancia del contenido (Google Search Central).

Esta guía corresponde a las definiciones vigentes en octubre de 2026. Explica cada métrica, cómo se hace la evaluación, qué dice Google sobre el posicionamiento, dónde ver las cifras y por dónde empezar a mejorar cada una.

Las tres métricas y sus umbrales

Cada métrica tiene tres franjas: bueno, necesita mejorar y deficiente. Los umbrales de abajo son los mismos en PageSpeed Insights y en el informe de Search Console (documentación de PageSpeed Insights, ayuda de Search Console).

LCP: cuándo aparece el contenido principal

El LCP marca el momento en que se renderiza el elemento visible más grande del área inicial de la pantalla, contado desde el inicio de la navegación. Son candidatos las imágenes (<img> y <image> dentro de un SVG), los vídeos (cuenta el póster o el primer fotograma, lo que llegue antes), los elementos con imagen de fondo cargada con url() en el CSS (los degradados no cuentan) y los bloques de texto (web.dev, LCP). El elemento elegido puede cambiar según el tamaño de la pantalla, porque cada dispositivo muestra una parte distinta de la página (web.dev, diferencias entre laboratorio y campo).

INP: cuánto tarda la página en responder

El INP observa los clics, toques y pulsaciones de teclas durante toda la visita y mide cuánto tarda cada interacción hasta que la pantalla muestra la respuesta. El desplazamiento, el hover y el zoom no entran. El valor de la visita es la interacción más lenta; en páginas con muchas interacciones se descarta la más lenta de cada grupo de 50, para que un caso aislado no defina el resultado (web.dev, INP).

El INP sustituyó al FID (First Input Delay) como Core Web Vital el 12 de marzo de 2024. El FID medía solo el retraso hasta que el navegador empezaba a atender la primera interacción; el INP tiene en cuenta todas las interacciones y llega hasta que se actualiza la pantalla. Chrome dio de plazo hasta el 9 de septiembre de 2024 a quien consumía el FID en las API de CrUX y de PageSpeed Insights para migrar al INP (web.dev, anuncio del INP). El material que todavía presenta el FID como Core Web Vital está desactualizado.

CLS: cuánto salta la página

El CLS mide los desplazamientos de diseño inesperados, como un botón que baja porque encima se cargó un banner. Los desplazamientos se agrupan en ventanas: entran en la misma ventana los que ocurren con menos de 1 segundo de diferencia entre sí, y cada ventana dura como máximo 5 segundos. El CLS de la página es la ventana con la suma más alta, observada durante toda la vida de la página, también después del desplazamiento. Los desplazamientos que ocurren hasta 500 ms después de un clic, un toque o una tecla se consideran esperados y quedan fuera (web.dev, CLS).

Cómo funciona la evaluación: percentil 75, móvil y escritorio

Google no evalúa una visita aislada. La medida recomendada es el percentil 75 (p75) de las visitas, separado entre móvil y escritorio (web.dev). Percentil 75 significa que tres de cada cuatro visitas tuvieron ese valor o uno mejor. Según web.dev, este corte asegura que la mayoría de las visitas alcanzó el objetivo sin dejar que los casos extremos distorsionen la cifra (web.dev, definición de los umbrales).

Una página u origen aprueba la evaluación cuando el p75 de las tres métricas está en la franja buena. En PageSpeed Insights, cuando no hay datos suficientes de INP, la evaluación tiene en cuenta solo LCP y CLS (PageSpeed Insights).

Los umbrales son los mismos para móvil y escritorio, porque lo que espera el usuario no cambia con el dispositivo. Como el móvil tiene hardware y red más limitados, la mayoría de los umbrales se definió pensando en él (web.dev). Los resultados, en cambio, salen por separado: en Search Console, cada grupo de páginas recibe un estado para móvil y otro para escritorio, y el estado del grupo es el de la peor métrica (ayuda de Search Console). Un buen resultado en escritorio no dice nada sobre el móvil.

Qué dice Google sobre las Core Web Vitals en el posicionamiento

La documentación sobre experiencia en la página de Google Search Central, actualizada en septiembre de 2026, afirma lo siguiente (Google Search Central, experiencia en la página):

• Los sistemas de clasificación usan las Core Web Vitals, y Google recomienda tener buenos resultados en ellas para el éxito en la búsqueda y para la experiencia del usuario en general.

• Los buenos resultados en el informe de Search Console o en herramientas de terceros no garantizan que las páginas queden en lo más alto de los resultados.

• Buscar una puntuación perfecta solo por motivos de SEO puede no ser el mejor uso de tu tiempo.

• La búsqueda siempre intenta mostrar el contenido más relevante, incluso cuando la experiencia en la página es mala. Cuando hay mucho contenido útil disponible para una consulta, una buena experiencia en la página puede contribuir al resultado.

• No existe una única señal de experiencia en la página; los sistemas miran varias señales.

• Aparte de las Core Web Vitals, los demás aspectos de la experiencia en la página no ayudan directamente en la clasificación, aunque hacen que el sitio sea más agradable de usar.

• La evaluación se hace en general por página, con algunas evaluaciones del sitio completo.

Google no publica el peso de las Core Web Vitals en la clasificación. La lectura prudente de esa documentación es tratar las métricas como un factor entre muchos: vale la pena corregir lo que está en la franja deficiente, sobre todo en páginas que compiten por consultas con mucho contenido útil, pero no tiene sentido esperar que pasar de "necesita mejorar" a "bueno" cambie posiciones por sí solo. La razón más sólida para mejorar sigue siendo el visitante, que espera menos y no hace clic donde no quería.

Dónde ver las cifras de tu sitio

Hay dos tipos de datos. Los datos de campo vienen de visitas reales, con los dispositivos y las redes que usan de verdad los visitantes. Los datos de laboratorio vienen de una carga simulada, con dispositivo y red fijos. La recomendación de web.dev es empezar por el campo para saber si hay un problema y usar el laboratorio para descubrir la causa (web.dev, herramientas). La diferencia entre las fuentes está explicada en detalle en Lighthouse, CrUX y RUM: qué datos de Core Web Vitals usar.

Las fuentes de la tabla están en la documentación de PageSpeed Insights, la ayuda de Search Console, la metodología de CrUX, la página de Web Vitals y el repositorio de la biblioteca web-vitals.

CrUX (Chrome User Experience Report) es la base pública de datos de campo de Google. Reúne visitas de usuarios de Chrome en escritorio y en Android que activaron el envío de estadísticas de uso y la sincronización del historial. Solo entran páginas y orígenes que se pueden descubrir públicamente y que tienen visitas suficientes; Google no publica el mínimo (metodología de CrUX). La CrUX API es gratuita, actualiza los datos cada día y devuelve la media móvil de los últimos 28 días, con desglose por móvil, escritorio y tablet.

RUM (real user monitoring, o monitorización de usuarios reales) es la recogida de datos que hace el propio sitio. La biblioteca web-vitals, que mantiene el equipo de Chrome, mide las métricas igual que las mide Chrome para las herramientas de Google (web-vitals). Eso permite ver datos por página, por tipo de página y con el elemento responsable, algo que CrUX no muestra.

FCP, TTFB y TBT: métricas de apoyo, no Core Web Vitals

Algunas herramientas muestran otras métricas junto a las Core Web Vitals. Ayudan a encontrar la causa de un problema, pero no entran en la evaluación (web.dev).

La propia web.dev dice que un TTFB por encima de 0,8 s no es un problema en sí mismo cuando no perjudica a las métricas que importan (web.dev, TTFB). El mismo razonamiento vale para FCP y TBT: úsalos para explicar un LCP o un INP malos, no como objetivo aislado.

Cómo mejorar cada métrica

Las recomendaciones de abajo resumen las que web.dev considera más eficaces (web.dev, las formas más eficaces de mejorar las Core Web Vitals). Cada métrica tiene su propia guía en este blog.

LCP

El punto de partida es que el recurso del LCP (normalmente una imagen) aparezca ya en el HTML inicial, sin carga diferida (lazy loading) y con prioridad alta. Después viene el tiempo de respuesta del servidor, que puede bajar con la caché del HTML en una CDN cerca del usuario. Las navegaciones instantáneas, con la caché de páginas completas (back/forward cache) y el prerenderizado, también reducen el LCP. El paso a paso, dividido en las cuatro partes del tiempo del LCP, está en Cómo mejorar el LCP.

INP

El INP empeora cuando el hilo principal del navegador está ocupado con JavaScript en el momento del clic. Los frentes principales son dividir las tareas largas para devolver el control al navegador con frecuencia, enviar menos JavaScript (incluidas las etiquetas antiguas de terceros) y evitar actualizaciones grandes de renderizado, con un DOM más pequeño. Más detalles en Cómo mejorar el INP.

CLS

La mayor parte del CLS desaparece cuando todo el contenido que se carga después (imágenes, anuncios, inserciones) tiene espacio reservado, con width y height, aspect-ratio o una altura mínima. También ayuda que la página sea apta para la back/forward cache y animar con transform en lugar de propiedades que alteran el diseño, como top o margin. Consulta Cómo corregir el CLS.

Después de corregir, los datos de campo de CrUX tardan hasta 28 días en reflejar el cambio por completo, porque son una media móvil. Si gestionas muchos sitios y necesitas detectar regresiones justo después de un despliegue, el proceso está en Cómo monitorear el rendimiento de varios sitios.

Cómo verificar tu sitio

El test de Core Web Vitals de WebVyze muestra los datos de CrUX de los últimos 28 días, para móvil y escritorio, de hasta 10 URL. Cuando una métrica está mal, los diagnósticos de LCP, INP y CLS usan Google PageSpeed para señalar la causa. Para hacer un seguimiento a lo largo del tiempo, los planes de pago incluyen auditorías programadas, alertas y un script de visitantes reales (unos 10 KB, basado en la biblioteca web-vitals) que registra LCP, INP y CLS de cada visita con la causa. WebVyze solo lee páginas públicas y no modifica el sitio.