Core Web Vitals no superados: cómo mejorar LCP, INP y CLS

Por SEOgrinder · Publicado 4 de noviembre de 2026 · 10 min de lectura

Respuesta corta: Una evaluación de Core Web Vitals no superada significa que al menos una de tres métricas incumple su umbral para visitantes reales: el LCP (carga) debe ser de 2,5 segundos o menos, el INP (respuesta) de 200 milisegundos o menos y el CLS (estabilidad visual) de 0,1 o menos, cada uno medido en el percentil 75. Busca la métrica que falla en los datos de campo de visitantes reales, no en la puntuación de laboratorio, y corrige primero esa. Google dice que sus sistemas de clasificación usan Core Web Vitals, pero unos buenos valores no garantizan una posición alta.

¿Qué significa una evaluación de Core Web Vitals no superada?

Los Core Web Vitals son la parte de la iniciativa Web Vitals de Google que se aplica a todas las páginas web. web.dev nombra tres métricas, una por cada aspecto de la experiencia:

Métrica	Qué mide	Valor bueno
LCP, Largest Contentful Paint	Carga: cuándo aparece la imagen, el bloque de texto o el vídeo más grande del área visible	2,5 segundos o menos
INP, Interaction to Next Paint	Respuesta: con qué rapidez reacciona visiblemente la página a un clic, un toque o una pulsación de tecla	200 milisegundos o menos
CLS, Cumulative Layout Shift	Estabilidad visual: cuánto salta el contenido visible mientras usas la página	0,1 o menos

Los valores se juzgan en el percentil 75 de las cargas de página, por separado para móvil y para ordenador. Dicho en llano: en tres de cada cuatro visitas el valor tiene que ser bueno, y el móvil y el ordenador reciben cada uno su propio veredicto. web.dev indica a las herramientas que den una página por superada si cumple los objetivos en el percentil 75 en las tres métricas. Una sola métrica en rojo basta, por tanto, para suspender.

Un detalle en el límite: para el INP y el CLS, web.dev escribe «o menos» (el propio valor límite cuenta como bueno), mientras que la documentación de Búsqueda de Google dice «less than 200 milliseconds» y «less than 0.1», es decir, estrictamente menos. Apunta claramente por debajo de la línea y la diferencia no importa.

Un cambio que conviene conocer: el INP sustituyó al First Input Delay (FID) como Core Web Vital en marzo de 2024, como cuenta el anuncio de web.dev. Una guía que aún menciona el FID está desactualizada. Leímos todas las páginas citadas en este artículo el 4 de noviembre de 2026; el resumen de web.dev se actualizó por última vez el 31 de octubre de 2024.

¿Afectan los Core Web Vitals al posicionamiento en Google?

Sí, según Google, pero sin indicar ningún peso. La página de Google sobre la experiencia de página dice: «Core Web Vitals are used by our ranking systems.» Recomienda buenos valores para tener éxito en la Búsqueda y añade que no existe una única señal de experiencia de página.

La misma página es igual de clara sobre los límites. Buenos resultados en el informe de Core Web Vitals de Search Console o en herramientas de terceros «doesn't guarantee that your pages will rank at the top of Google Search results», es decir, no garantizan que tus páginas queden arriba en los resultados. También dice que perseguir una puntuación perfecta solo por el SEO quizá no sea el mejor uso de tu tiempo. Google siempre intenta mostrar el contenido más relevante, incluso cuando la experiencia de página es mala.

Lo que Google no publica es cuánto pesan las métricas, así que nosotros tampoco damos ninguna cifra. Nuestra lectura, que no es un hecho de Google: trata los umbrales como un listón de calidad para tus visitantes, pon las tres métricas en «bueno» y vuelve después a dedicar tu tiempo al contenido. Los sistemas de clasificación principales de Google suelen evaluar el contenido página a página, así que comprueba cada tipo de página que importe.

¿Datos de laboratorio o de campo? Cuáles cuentan en los Core Web Vitals

La evaluación se basa en datos de campo: mediciones de visitas reales. El Chrome User Experience Report (CrUX) de Google los recoge de usuarios reales de Chrome; PageSpeed Insights y el informe de Core Web Vitals de Search Console los muestran. Según web.dev, un informe de CrUX abarca un periodo de 28 días.

Los datos de laboratorio salen de cargar la página una vez en un entorno controlado: un dispositivo, una red, un lugar. Eso es ideal para encontrar causas y para probar una corrección antes de publicarla, pero la guía del LCP advierte de que «lab tests alone may not be entirely representative», o sea, que las pruebas de laboratorio por sí solas pueden no ser del todo representativas. Cuando los dos tipos de datos discrepan, la guía del LCP dice que te concentres primero en los datos de usuarios reales. Hay buenas razones para que difieran:

El elemento del LCP puede ser otro. Una ejecución de laboratorio siempre encuentra el mismo elemento. Las visitas reales tienen otros tamaños de pantalla, contenido para usuarios con sesión iniciada o pruebas A/B.
El INP necesita personas reales. Lighthouse y otras herramientas de laboratorio cargan una página sin que nadie haga clic, así que no pueden medir el INP. El Total Blocking Time (TBT) es el sustituto en el laboratorio; mejorar el TBT puede mejorar el INP.
El CLS sigue contando después de la carga. Las ejecuciones de laboratorio ven sobre todo la propia carga. En el campo, el contenido que aparece mientras los visitantes hacen scroll también puede desplazar el diseño.
Las cachés ayudan a los visitantes reales. Las pruebas de laboratorio suelen empezar con la caché fría, mientras que los visitantes que vuelven y la caché de ida y vuelta (back/forward cache) cargan las páginas más rápido.

Cómo leer tus números en cuatro pasos:

Pasa tu dirección por PageSpeed Insights. La sección «Discover what your real users are experiencing» (así se llama en la interfaz en inglés) contiene los datos de campo; «Diagnose performance issues» contiene la ejecución de laboratorio.
Comprueba qué estás mirando. Cambia entre móvil y ordenador y entre la URL individual y todo el origen (el sitio entero). Si una URL tiene pocos datos, PageSpeed Insights muestra los del origen.
Encuentra la métrica que supera su línea en el percentil 75. Esa es tu métrica que falla. Con poco tráfico no hay datos de campo; usa los valores de laboratorio y mide a tus propios visitantes con la pequeña biblioteca web-vitals de web.dev.
Abre los diagnósticos de laboratorio de esa métrica para ver la causa y corrige primero esa única cosa.

Cómo mejorar el LCP: el elemento más grande aparece demasiado tarde

El LCP indica cuándo se dibuja la imagen, el bloque de texto o el vídeo más grande del área visible. La guía del LCP de web.dev divide el tiempo en cuatro partes que suman el LCP: la respuesta del servidor (TTFB), el retraso antes de que el navegador empiece a cargar el recurso del LCP, el tiempo que ese recurso tarda en cargar y el retraso hasta que se dibuja el elemento. Encuentra la parte más grande antes de cambiar nada: acortar una parte puede limitarse a trasladar tiempo a otra. Una imagen más comprimida no ayuda si el elemento permanece oculto hasta que se carga un script.

La lista de las correcciones más eficaces del equipo de Chrome incluye estas:

Haz que la imagen del LCP sea fácil de encontrar y dale prioridad. Usa un <img> normal con src o srcset, no un data-src que necesite JavaScript. Prefiere el renderizado en el servidor a construir la página solo en el navegador. Añade fetchpriority="high" y quita loading="lazy" de esa única imagen.
Acorta la respuesta del servidor. Sirve y guarda en caché el contenido cerca de tus visitantes, normalmente con una CDN.

La misma etiqueta se ocupa del LCP y, por su tamaño, del CLS:

<!-- Imagen principal: en el HTML, prioridad alta, sin lazy, con tamaño -->
<img src="/img/portada.webp" width="1200" height="630" alt="Descripción breve" fetchpriority="high">

<!-- Imágenes más abajo en la página: aquí el lazy loading está bien -->
<img src="/img/equipo.webp" width="600" height="400" alt="Descripción breve" loading="lazy">

Cómo mejorar el INP: la página reacciona demasiado despacio

El INP observa cada clic, cada toque y cada pulsación de tecla durante una visita e informa más o menos de la más lenta (en páginas con muchísimas interacciones se ignoran los valores atípicos). Pasar el ratón por encima y hacer scroll no cuentan. Según la guía del INP, cada interacción tiene tres partes: el retraso de entrada, el tiempo que se ejecutan los controladores de eventos y el retraso hasta que se muestra el siguiente fotograma. El culpable habitual es el JavaScript que mantiene ocupado el hilo principal. Las correcciones principales del equipo de Chrome:

Divide las tareas largas. Una tarea de más de 50 milisegundos bloquea el hilo principal. Devuelve el control a menudo: con scheduler.yield() donde el navegador lo admita, y con setTimeout como forma más antigua.
Envía menos JavaScript. Encuentra el código sin usar con la herramienta de cobertura de las DevTools de Chrome, divide el código que no hace falta al principio y limpia las etiquetas antiguas de tu gestor de etiquetas.
Evita grandes actualizaciones de renderizado. Mantén el DOM pequeño, evita el layout forzado y usa CSS containment para el contenido fuera de la pantalla.

Cómo mejorar el CLS: el diseño salta

El CLS no tiene unidad. Combina cuánto contenido visible se movió con cuánto se movió. En el campo cuenta durante toda la visita, pero se excluyen los desplazamientos que ocurren dentro de los 500 milisegundos posteriores a una interacción del usuario. La guía del CLS de web.dev enumera las causas habituales: imágenes sin dimensiones, anuncios, incrustaciones e iframes sin dimensiones, contenido inyectado dinámicamente y fuentes web. Esto ayuda:

Reserva espacio. Da width y height a las imágenes y los vídeos, o usa la propiedad CSS aspect-ratio. Para contenido de tamaño desconocido, un min-height razonable es mejor que el valor por defecto de cero.
Anima con transform. Animar top, left o margin desplaza el diseño. Los avisos de cookies que se deslizan al entrar son un caso típico.
Deja que funcione la caché de ida y vuelta. Restaura páginas ya dibujadas por completo. Los bloqueos habituales son las directivas de caché no-store y los escuchadores del evento unload.
Cuida las fuentes web. font-display: optional, las fuentes de reserva que coinciden gracias a size-adjust y la precarga de las fuentes críticas reducen los desplazamientos causados por las fuentes.

Cómo comprueba SEOgrinder los Core Web Vitals

SEOgrinder es nuestra herramienta; la construimos nosotros. Introduce una dirección pública en SEOgrinder y los datos de velocidad vienen de Google PageSpeed Insights, para móvil y para ordenador. La tarjeta «Core Web Vitals» muestra el LCP y el CLS de la ejecución de laboratorio de Lighthouse y el INP de visitantes reales, y un cuadro aparte muestra datos de usuarios reales de los últimos 28 días. Si Google tiene pocos datos de la página, el informe lo dice en lugar de adivinar. Tareas como «Los visitantes reales en el móvil esperan … hasta ver el contenido» nombran la métrica, el valor y la corrección. Una respuesta lenta del servidor, que influye en el LCP, recibe su propia tarea.

Límites: SEOgrinder lee los números de Google y no sustituye a tu propia monitorización de usuarios reales. No mide posicionamientos. Si se agota la cuota diaria de Google para la medición de velocidad, el informe llega sin ella.

Errores frecuentes

Fiarse solo de la puntuación de laboratorio. No puede medir el INP y puede ser distinta de lo que experimentan los visitantes. Empieza por los valores de visitantes reales.
Comprobar un solo dispositivo. El móvil y el ordenador se juzgan por separado.
Cargar en diferido la imagen principal. loading="lazy" en la imagen del LCP añade retraso.
Omitir el tamaño de las imágenes. Sin width y height, el navegador no puede reservar espacio.
Corregir la parte equivocada del LCP. Comprime las imágenes solo cuando el desglose muestre que el problema es el tiempo de carga.
Esperar un resultado inmediato. Los datos de campo abarcan 28 días, así que cambian poco a poco. Comprueba la ejecución de laboratorio justo después de una corrección y los números de visitantes reales en las semanas siguientes.

Preguntas frecuentes

¿Qué es una buena puntuación de Core Web Vitals?

No hay una puntuación única. Una página supera la evaluación cuando el LCP es de 2,5 segundos o menos, el INP de 200 milisegundos o menos y el CLS de 0,1 o menos en el percentil 75. El número de 0 a 100 que quizá conozcas de Lighthouse es una cifra de laboratorio y otra cosa distinta.

¿Por qué PageSpeed Insights no muestra datos de usuarios reales de mi sitio?

Normalmente hay muy pocas visitas para que CrUX pueda informar. En ese caso, web.dev sugiere añadir tu propia medición de visitantes reales. Mientras tanto, trabaja con los valores de laboratorio.

¿Necesito una puntuación perfecta?

No. El objetivo es superar la evaluación. El propio Google dice que perseguir una puntuación perfecta solo por motivos de SEO quizá no sea el mejor uso de tu tiempo.

Tu siguiente paso

Pasa tu página más importante por SEOgrinder, abre la tarjeta «Core Web Vitals» y mira primero los valores de visitantes reales. Corrige la única métrica que falla, pulsa «Comprobar de nuevo» y lee los valores de laboratorio. El panorama completo está en nuestro checklist SEO.