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

Por Daniele Forciniti

Índice

Los Core Web Vitals son tres medidas con las que Google valora la experiencia real de quien visita una página: el LCP mide cuánto tarda en verse el contenido principal, el INP cuánto tarda la página en responder a clics y toques, y el CLS cuánto se mueve mientras la usas. En 2026 los umbrales siguen siendo los mismos: LCP en 2,5 segundos o menos, INP en 200 milisegundos o menos y CLS en 0,1 o menos, calculados con los datos reales de los visitantes que usan Chrome. Cuentan para el posicionamiento, pero menos de lo que se suele leer: Google los usa entre sus señales, aunque una página más útil sigue por delante de una más rápida.

Por qué se sigue hablando de ellos (y qué no ha cambiado)

Cada año salen artículos que anuncian una revolución: umbrales más estrictos, una nota única, métricas nuevas. En 2026 no ha pasado nada de eso. He revisado la documentación oficial y las métricas siguen siendo tres, con los mismos valores. En web.dev Google explica además cómo funcionan los cambios: una métrica nueva pasa primero por una fase experimental, luego queda «pendiente» al menos seis meses, y las métricas estables no cambian más de una vez al año. Una novedad repentina que solo anuncian algunos blogs hay que tomarla con mucha prudencia.

El último cambio real fue el 12 de marzo de 2024, cuando el INP sustituyó al FID (First Input Delay). Muchas guías en español y en italiano, incluso entre las primeras de Google, siguen hablando del FID: si encuentras una así, tiene por lo menos dos años.

Las métricas de velocidad son una de las partes más técnicas de la gestión SEO de una web, y también una de las que más mitos tienen. Aquí intento separar lo que dice Google de lo que se repite por costumbre.

LCP, INP y CLS explicados de forma sencilla

Los umbrales de LCP, INP y CLS: valores buenos, que necesitan mejorar y deficientes según Google

LCP: cuándo ves el contenido principal

El Largest Contentful Paint mide el tiempo que pasa desde que abres la página hasta que aparece el elemento más grande de la parte visible de la pantalla. Suele ser la imagen principal, un vídeo o un bloque de texto grande, como el título. Es el momento en que quien visita tiene la sensación de que la página ya ha llegado. El valor bueno es de 2,5 segundos o menos.

INP: cuánto responde la página cuando la usas

El Interaction to Next Paint mide cuánto tarda la página en mostrar una reacción después de un clic, un toque o una tecla. No cuenta solo la primera interacción, como hacía el FID, sino todas las de la visita, y se queda con la más lenta (descartando los casos anómalos). Piensa en el menú que se abre con retraso o en el botón «añadir al carrito» que parece no funcionar: eso es un INP alto. El valor bueno es de 200 milisegundos o menos.

CLS: cuánto se mueve la página

El Cumulative Layout Shift mide los movimientos repentinos de los elementos mientras la página carga o mientras la usas. Es el caso típico del texto que baja porque arriba ha aparecido un banner, o del botón que se mueve justo cuando vas a tocarlo. No es un tiempo sino una puntuación: cero significa ningún movimiento, y el valor bueno es de 0,1 o menos.

Métrica	Qué mide	Buena	Necesita mejorar	Deficiente
LCP	Carga del contenido principal	hasta 2,5 s	hasta 4 s	más de 4 s
INP	Respuesta a clics, toques y teclas	hasta 200 ms	hasta 500 ms	más de 500 ms
CLS	Movimientos inesperados del diseño	hasta 0,1	hasta 0,25	más de 0,25

Un detalle que muchos no conocen: para aprobar hay que estar en verde en las tres. El informe de Search Console asigna a cada grupo de páginas el estado de la peor métrica, así que un LCP perfecto no compensa un CLS deficiente.

Cuánto cuentan de verdad para el posicionamiento

Aquí conviene leer las palabras de Google, porque son más prudentes de lo que se piensa. En su página sobre la experiencia en la página, actualizada en septiembre de 2026, Google confirma que estas métricas las usan sus sistemas de clasificación. Pero justo después añade que tener buenos resultados en el informe de Search Console o en herramientas de terceros no garantiza llegar arriba, y que perseguir una puntuación perfecta solo por el SEO puede no ser la mejor forma de usar el tiempo.

En la práctica funciona así:

Primero va la relevancia. Google escribe que siempre muestra el contenido más útil, aunque la experiencia de la página no sea buena.
Con contenidos parecidos, la velocidad ayuda. Cuando para una búsqueda hay muchas páginas válidas, una experiencia mejor puede marcar la diferencia.
No existe una única «señal de experiencia». Google mira varios aspectos a la vez: además de las tres métricas, la seguridad HTTPS, cómo se ve en el móvil, la cantidad de anuncios y las ventanas emergentes invasivas.
La valoración es por página, aunque Google admite que también tiene algunas valoraciones del sitio entero.

El motivo real para ocuparse de ellos, en mi opinión, no es el ranking: es que una página lenta o inestable hace que la gente se vaya antes de leer o comprar algo. La ventaja SEO llega casi como consecuencia.

Datos reales y pruebas de laboratorio: por qué los números no coinciden

Es la pregunta que más me hacen: «PageSpeed me da 45 sobre 100, pero Search Console dice que todo va bien. ¿Quién tiene razón?». Normalmente los dos, porque miden cosas distintas.

Los datos de campo vienen del Chrome UX Report (CrUX): son las medidas anónimas que Chrome recoge de las visitas reales de los últimos 28 días. Google toma el percentil 75, es decir, el valor que cumplen al menos tres de cada cuatro visitas, separado entre móvil y ordenador. Son estos los datos que cuentan para Google.
Los datos de laboratorio vienen de Lighthouse: una prueba simulada, hecha una sola vez con un móvil y una conexión de referencia. La puntuación de 0 a 100 que ves en PageSpeed Insights sale de aquí. Sirve para encontrar los problemas, pero no es lo que Google usa para valorar la web.

Hay también un límite práctico: si la web tiene pocas visitas, CrUX no tiene datos suficientes y Search Console muestra «No hay datos disponibles». Les pasa a menudo a las webs pequeñas y nuevas. En ese caso se trabaja con las pruebas de laboratorio, sabiendo que solo son una orientación.

Cómo medirlos: las herramientas gratuitas

Herramienta	Tipo de datos	Para qué sirve
Search Console, informe Core Web Vitals	Campo (CrUX)	Ver qué grupos de páginas tienen problemas, en móvil y ordenador
PageSpeed Insights	Campo y laboratorio	Revisar una página concreta y recibir las sugerencias técnicas
Lighthouse	Laboratorio	Hacer pruebas repetidas mientras se corrigen los problemas
Chrome DevTools, panel Performance	Laboratorio, en tu navegador	Encontrar el elemento LCP, las interacciones lentas y los movimientos
Chrome UX Report	Campo	Análisis más avanzados e históricos, también por país

Mi orden de trabajo es siempre el mismo. Empiezo por el informe de Search Console, que forma parte de los informes que reviso cada mes, y miro primero el móvil. Cada fila es un grupo de páginas parecidas: abro una URL de ejemplo, la paso por PageSpeed Insights y leo primero la parte con los datos reales, luego las sugerencias de la prueba. Cuando he corregido, en el informe pulso «Empezar revisión»: Google comprueba el problema durante 28 días con los datos nuevos.

Cómo está la web: los números de 2025

Porcentaje de webs con LCP, INP y CLS buenos en móvil y ordenador según el Web Almanac 2025

El Web Almanac 2025 de HTTP Archive ha analizado los datos de Chrome de millones de webs. El resultado sirve para entender dónde se falla más:

Solo el 48% de las webs en móvil supera los tres umbrales (el 56% en ordenador). En 2023, en móvil, era el 36%.
El LCP es el punto débil: en móvil es bueno en el 62% de las webs, frente al 74% en ordenador.
El INP va mucho mejor en ordenador (97% de webs buenas) que en el móvil (77%), porque los móviles tienen menos potencia para ejecutar JavaScript.
El CLS es el único que va mejor en móvil: 81% de webs buenas, frente al 72% en ordenador.
Las imágenes son el elemento LCP en el 76% de las páginas móviles, y alrededor del 16% de las páginas carga esa imagen de forma diferida (lazy loading), es decir, la hace llegar más tarde.
El 62% de las páginas móviles tiene al menos una imagen sin dimensiones definidas, una de las causas más comunes de los movimientos.

Dicho de otra forma: si tu web no aprueba en móvil estás en buena compañía, pero también es una oportunidad. Las correcciones que hacen falta suelen ser sencillas.

Cómo mejorar el LCP

Google ha reunido en una guía las correcciones que mejor funcionan. Para el LCP las más útiles son estas:

No cargues de forma diferida la imagen principal. El lazy loading está bien para las imágenes de más abajo, no para la de arriba de la página. Muchos temas y plugins lo aplican a todas.
Dale prioridad a la imagen principal con el atributo fetchpriority=»high», para que el navegador la descargue antes que el resto de recursos.
Haz que la imagen aparezca enseguida en el HTML. Si la imagen principal es un fondo en CSS o la inserta el JavaScript, el navegador la descubre tarde.
Aligera las imágenes: tamaño adecuado para la pantalla y formatos modernos como WebP o AVIF. Según el Web Almanac, el 57% de las imágenes LCP sigue en JPG.
Reduce el tiempo de respuesta del servidor con una buena caché y, si tienes visitas de varios países, con una CDN.

Cómo mejorar el INP

El INP depende casi siempre del JavaScript: cuando el navegador está ocupado ejecutando código, no puede responder al clic. Las correcciones principales:

Quita el JavaScript que no hace falta. Plugins que no se usan, scripts de chat, mapas y herramientas de marketing cargados en todas las páginas, también donde no sirven.
Divide las tareas largas. Una operación que bloquea el navegador más de 50 milisegundos se llama tarea larga: hay que dividirla en partes más pequeñas, para que el navegador tenga tiempo de responder entre una y otra.
Muestra una reacción enseguida. Cuando alguien hace clic, actualiza primero la parte visible (un menú que se abre, un botón que cambia de estado) y deja el trabajo pesado para después.
Cuidado con los scripts de terceros como píxeles publicitarios y herramientas de analítica: a menudo son ellos los que ralentizan las interacciones, y no se ven en el código de la web.

Cómo mejorar el CLS

Define ancho y alto en imágenes, vídeos e iframes, para que el navegador reserve el espacio antes de que lleguen.
Reserva el espacio para banners, anuncios y avisos de cookies en lugar de insertarlos encima del contenido cuando la página ya se ve.
Controla las fuentes web: una fuente que llega tarde y tiene medidas distintas a la de reserva hace «saltar» el texto.
Anima solo transformaciones y transparencias, no la altura, el ancho o la posición, que obligan al navegador a recalcular la página.
Haz las páginas compatibles con la caché de atrás/adelante (bfcache): al volver atrás, la página reaparece al instante y sin movimientos.

Qué puedes hacer en WordPress y en Wix

En WordPress tienes mucho control, y por eso muchas ocasiones de equivocarte. Las causas que encuentro más a menudo son un tema pesado, un maquetador que lo carga todo en cada página y demasiados plugins. Un plugin de caché y otro para optimizar las imágenes ayudan, pero no arreglan un tema mal hecho: a veces la solución real es rehacer el tema.

En Wix el servidor, la caché y la CDN los gestiona la plataforma, así que en esa parte no puedes intervenir. Sí puedes trabajar en lo que pones en la página: imágenes ligeras, menos animaciones, menos apps externas y menos código incrustado. Muchas veces una web en Wix es lenta por los elementos añadidos, no por la plataforma.

Los fallos más comunes

Cuando analizo webs de pequeñas y medianas empresas, encuentro casi siempre los mismos problemas:

Perseguir el 100 en PageSpeed e ignorar los datos reales de Search Console, que son los que cuentan.
Mirar solo el ordenador. La mayoría de las visitas llega desde el móvil, y ahí los resultados casi siempre son peores.
Un slider con cinco imágenes grandes arriba de la home, que hace lento el LCP.
El banner de cookies o una barra promocional que empuja hacia abajo toda la página.
Plugins de «optimización» uno encima de otro, que a veces rompen la web o empeoran el INP.
Corregir y no validar: sin empezar la revisión en Search Console no sabes si la corrección ha funcionado con los datos reales.

Mi opinión

Llevo más de diez años haciendo webs y posicionamiento, y he visto la velocidad pasar de detalle técnico a tema de reunión. A veces demasiado: he visto empresas dedicar semanas a llevar PageSpeed de 85 a 98 mientras sus páginas de servicio no respondían a las preguntas de los clientes. Es tiempo mal invertido, y lo dice la propia Google.

El punto justo, para mí, es este: superar los tres umbrales en móvil y luego parar, salvo casos concretos como las tiendas online con muchas visitas, donde cada décima de segundo pesa en las ventas. Una vez en verde, el tiempo rinde más si lo dedicas a los contenidos y a los enlaces. Si quieres una revisión de tu web hecha con este criterio, forma parte de mis servicios SEO.

En resumen

LCP, INP y CLS miden tres cosas sencillas: cuánto tardas en ver la página, cuánto tarda en responder y cuánto se queda quieta. En 2026 los umbrales siguen siendo 2,5 segundos, 200 milisegundos y 0,1, y cuentan los datos reales de los visitantes, no la nota de una prueba. Google los usa para el posicionamiento, pero la relevancia va primero. Revisa el informe de móvil en Search Console, corrige las causas más comunes (imágenes, JavaScript, espacios sin reservar) y, cuando estés en verde, vuelve a trabajar en los contenidos.

Preguntas frecuentes

¿Qué son LCP, INP y CLS?

Son las tres métricas con las que Google mide la experiencia en una página. El LCP mide la carga del contenido principal, el INP la rapidez de respuesta a clics y toques, y el CLS la estabilidad de la página mientras carga y mientras se usa.

¿Cuáles son los umbrales en 2026?

Los mismos de los últimos años: LCP en 2,5 segundos o menos, INP en 200 milisegundos o menos y CLS en 0,1 o menos. Se calculan en el percentil 75 de las visitas reales de los últimos 28 días, por separado en móvil y ordenador.

¿Sigue existiendo el FID?

No. Desde el 12 de marzo de 2024 el FID fue sustituido por el INP, que mide todas las interacciones de la visita y no solo la primera. Las herramientas de Google ya no lo muestran.

¿Una nota baja en PageSpeed Insights me hace perder posiciones?

No de forma directa. La nota de 0 a 100 sale de una prueba de laboratorio. Google usa los datos reales de los visitantes, que encuentras en la parte de arriba de PageSpeed Insights y en el informe de Search Console.

¿Por qué Search Console dice «No hay datos disponibles»?

Porque las páginas no tienen suficientes visitas desde Chrome para tener datos fiables, o porque la propiedad se ha creado hace poco. En el primer caso puedes usar las pruebas de laboratorio como orientación.

¿Cuánto tarda en verse la mejora en Search Console?

Los datos reales cubren los últimos 28 días, así que una mejora se ve del todo solo después de unas cuatro semanas. La revisión que inicias en el informe tras una corrección también dura 28 días.

¿Google penaliza las webs lentas?

No existe una penalización para las webs lentas. Las métricas son una de las señales de clasificación: pueden ayudar a una página cuando hay otras igual de útiles, pero no pasan por delante de la relevancia del contenido.

Lee también:
Migrar una web sin perder posiciones en Google: la guía 2026 ·
Contenido duplicado y canibalización SEO en 2026 ·
Title, meta description y snippet en 2026: cómo escribirlos y por qué Google los cambia

Fuentes

Google Search Central, Core Web Vitals y resultados de búsqueda: las tres métricas y los umbrales oficiales.
Google Search Central, experiencia en la página: cómo entran las métricas en el ranking y sus límites.
Ayuda de Search Console, informe Core Web Vitals: estados, grupos de URL y datos de campo.
web.dev, Web Vitals y el anuncio del INP: ciclo de vida de las métricas y paso del FID al INP.
web.dev, las correcciones más eficaces: las recomendaciones de Google para LCP, INP y CLS.
HTTP Archive, Web Almanac 2025, capítulo Performance: los datos reales de las webs en 2025.

Daniele Forciniti

Soy Daniele Forciniti, un experto en diseño web y SEO con más de 10 años de experiencia y diversas certificaciones profesionales. Estoy especializado en HTML y CSS, y utilizo CMS como WordPress. Soy el mayor experto en España en WIX y WIX Studio, y también me encargo del posicionamiento web SEO en buscadores y de marketing digital. Me apasiona mi trabajo y me actualizo constantemente para ofrecer soluciones innovadoras y de alta calidad a mis clientes.