Core Web Vitals explicado: LCP, INP y CLS sin complicaciones

Los Core Web Vitals son tres métricas de Google que miden la experiencia real de una página: LCP (velocidad de carga, ideal hasta 2,5 segundos), INP (respuesta a los clics, ideal hasta 200 milisegundos) y CLS (estabilidad visual, ideal hasta 0,1). Forman parte de la experiencia de página y ayudan al SEO, pero no sustituyen a un contenido relevante.

Resumen rápido

• LCP mide cuándo termina de aparecer el elemento visible más grande de la página. Bueno: hasta 2,5 s. Malo: más de 4 s.
• INP mide el tiempo entre un clic, un toque o una tecla y la respuesta visual de la página. Bueno: hasta 200 ms. Malo: más de 500 ms. Sustituyó al FID en marzo de 2024.
• CLS mide cuánto "salta" el diseño mientras la página carga. Bueno: hasta 0,1. Malo: más de 0,25.
• El objetivo es el percentil 75 de las visitas reales, separando móvil y ordenador.
• Para medir, usa el informe de Search Console y PageSpeed Insights. Los datos reales vienen de CrUX, y la prueba de laboratorio sirve para depurar.
• Google dice que la relevancia va primero: una página excelente en velocidad pero débil en contenido no gana.

Cómo leer este artículo: si te encargas de un sitio pero no programas, lee las definiciones, la tabla de umbrales y la lista de pasos, que te dicen qué pedirle al desarrollador. Si ya haces SEO técnico, ve a las secciones sobre datos de campo frente a datos de laboratorio, peso en el posicionamiento y correcciones por métrica. Este artículo complementa el SEO técnico para quien no es programador y usa términos que están en el glosario de SEO, AEO y GEO.

¿Qué son los Core Web Vitals?

Son tres métricas que Google eligió para representar la experiencia de uso de una página: carga (LCP), interactividad (INP) y estabilidad visual (CLS). La documentación de Google Search recomienda lograr buenos valores en ellas para tener éxito en la Búsqueda, y dice que se alinean con lo que los sistemas centrales de posicionamiento buscan recompensar.

En lenguaje sencillo: imagina entrar en una tienda física. El LCP es cuánto tarda en aparecer el mostrador principal. El INP es el tiempo que tarda el dependiente en reaccionar cuando levantas la mano. El CLS es el suelo que se mueve: vas a pulsar un botón y, de repente, se desplaza y haces clic en el equivocado.

Para quien ya trabaja en SEO: los Core Web Vitals son el subconjunto de métricas que Google trata como esenciales y recopila en CrUX. Hay otras métricas útiles para el diagnóstico (TTFB, FCP, TBT), pero solo LCP, INP y CLS entran en la evaluación de "aprobado o suspendido" del informe de Search Console.

¿Cuáles son los umbrales oficiales de LCP, INP y CLS?

Los umbrales oficiales, según la documentación de web.dev, son los de la tabla de abajo. Se evalúan en el percentil 75 de las visitas, es decir, el 75 % de los accesos debe estar dentro del umbral "bueno" para que la página sea aprobada, y los datos se segmentan entre móvil y ordenador.

Métrica	Qué mide	Bueno	Necesita mejorar	Malo
LCP (Largest Contentful Paint)	Cuándo termina de renderizarse el elemento visible más grande	hasta 2,5 s	de 2,5 s a 4 s	más de 4 s
INP (Interaction to Next Paint)	Latencia de las interacciones hasta el siguiente fotograma visual	hasta 200 ms	de 200 ms a 500 ms	más de 500 ms
CLS (Cumulative Layout Shift)	Suma de la mayor ráfaga de cambios inesperados de diseño	hasta 0,1	de 0,1 a 0,25	más de 0,25

Dos observaciones evitan confusiones. Primero, el CLS no tiene unidad: es una puntuación, calculada por el impacto del cambio en la pantalla multiplicado por la distancia recorrida por los elementos. Segundo, el INP sustituyó al FID (First Input Delay) como métrica oficial el 12 de marzo de 2024, según el anuncio de web.dev. Si un informe antiguo todavía cita el FID, está desactualizado.

¿Qué es el LCP y cómo mejorarlo?

El LCP registra cuándo termina de cargar el elemento visible más grande (normalmente una imagen destacada, un vídeo o un bloque grande de texto). La definición de web.dev considera imágenes, vídeos, imágenes de fondo mediante CSS y bloques de texto, y el valor final es el último elemento más grande registrado antes de la primera interacción del usuario.

La guía de optimización del LCP de web.dev divide el tiempo en cuatro partes: tiempo hasta el primer byte (cerca del 40 %), retraso para que el recurso empiece a cargar (menos del 10 %), duración de la descarga del recurso (cerca del 40 %) y retraso hasta el renderizado (menos del 10 %). El orden de ataque sugerido es eliminar primero el retraso de carga y el de renderizado, después reducir la descarga y, por último, el tiempo de respuesta del servidor.

Correcciones que suelen dar más resultado:

• Nunca apliques loading="lazy" a la imagen principal que aparece sin hacer scroll. La carga diferida (lazy loading) es para lo que queda más abajo.
• Marca la imagen principal con fetchpriority="high" y déjala visible en el HTML inicial, no inyectada después por JavaScript.
• Comprime la imagen y sírvela en el tamaño correcto, en un formato moderno como WebP o AVIF, y usa una CDN.
• Reduce las redirecciones y acelera el servidor, porque el LCP incluye el tiempo de conexión y de respuesta. Es preferible renderizar el contenido principal en el servidor.

Para quien ya trabaja en SEO: mira la imagen del hero en el informe de laboratorio y comprueba si es el elemento de LCP. Un error frecuente es el carrusel o slider que carga la primera diapositiva mediante script. Otro: corregir el peso de la imagen cuando el cuello de botella real es el TTFB, algo que la descomposición en cuatro partes muestra de inmediato.

¿Qué es el INP y cómo mejorarlo?

El INP mide la capacidad de respuesta de la página observando la latencia de todos los clics, toques y teclas durante la visita, desde el momento de la acción hasta que el navegador muestra el siguiente fotograma con una respuesta visual. El scroll, el paso del ratón por encima y el zoom no cuentan, según la explicación de web.dev sobre el INP. A diferencia del antiguo FID, que solo miraba la primera interacción, el INP cubre toda la página.

Cada interacción tiene tres fases: retraso de entrada (el navegador sigue ocupado), tiempo de procesamiento (tu código reacciona) y retraso de presentación (el navegador dibuja el resultado). La guía de optimización del INP de web.dev recomienda dividir las tareas largas de JavaScript, hacer lo mínimo posible dentro de los manejadores de eventos, posponer el trabajo no esencial, reducir el tamaño del DOM y evitar alternar lecturas y escrituras de diseño.

En términos prácticos:

• Elimina o pospón los scripts de terceros que bloquean la página: chat, píxeles, pruebas A/B.
• Divide las funciones pesadas en trozos más pequeños, devolviendo el control al navegador entre ellos.
• Muestra algún feedback inmediato al hacer clic (un estado de carga) antes de procesarlo todo.

En lenguaje sencillo: el INP es el "clic" del botón. Si pulsas "Añadir al carrito" y no pasa nada durante medio segundo, el INP es malo, aunque la página haya cargado rápido.

¿Qué es el CLS y cómo mejorarlo?

El CLS mide cuánto cambian de lugar de forma inesperada los elementos visibles mientras usas la página. web.dev agrupa los cambios en "ventanas de sesión" (ráfagas con un máximo de 1 segundo entre ellas y 5 segundos de duración) e informa de la mayor ventana. Los cambios provocados por un clic del usuario, dentro de los 500 ms, se consideran esperados y no cuentan.

Las causas más comunes y sus correcciones, según la guía de optimización del CLS de web.dev:

• Imágenes y vídeos sin dimensiones: declara siempre width y height, o usa aspect-ratio en CSS.
• Anuncios, embeds y banners que aparecen después: reserva el espacio con min-height o aspect-ratio antes de que llegue el contenido.
• Fuentes que cambian después de cargar: usa font-display: optional o fuentes de reserva parecidas para reducir el salto del texto.
• Animaciones: prefiere transform en lugar de cambiar top, left o los tamaños, porque transform no obliga al resto de la página a moverse.

¿Cómo medir los Core Web Vitals en tu sitio?

Mide con tres herramientas: el informe de Core Web Vitals de Search Console para ver todo el sitio, PageSpeed Insights para analizar una URL y el propio navegador para depurar. La diferencia que lo cambia todo es datos de campo (usuarios reales) frente a datos de laboratorio (una prueba simulada).

El informe de Search Console usa CrUX, el Informe de Experiencia del Usuario de Chrome, que reúne métricas anónimas de visitas reales. Agrupa URL similares, clasifica cada grupo como bueno, necesita mejorar o malo, y el estado del grupo es el de su peor métrica. Cuando corriges un problema y haces clic en validar, Google sigue CrUX durante 28 días para confirmarlo.

PageSpeed Insights muestra los dos tipos de datos. Los datos de campo son el historial de los últimos 28 días en CrUX. Los datos de laboratorio vienen de una simulación de Lighthouse, en una sola condición de dispositivo y red. Si el sitio no tiene tráfico suficiente, PSI no muestra datos de campo de la URL y puede pasar al nivel del origen, o no mostrar nada.

Para quien ya trabaja en SEO: cuando el campo y el laboratorio divergen, confía en el campo para decidir si hay un problema y usa el laboratorio para encontrar la causa. Las pruebas de laboratorio que solo cargan la página no miden el INP; reproduce flujos reales (abrir el menú, filtrar, añadir al carrito) en DevTools. Para medir en tu propio sitio, la biblioteca JavaScript web-vitals, mantenida por el equipo de Chrome, recopila las métricas tratando casos que la API cruda del navegador deja pasar.

Paso a paso para un diagnóstico en 30 minutos

1. Abre el informe de Core Web Vitals en Search Console, en móvil y en ordenador, y mira qué grupos de URL están "malos" o "necesitan mejorar".
2. Toma una URL representativa de cada grupo (un producto, una categoría, un artículo) y pásala por PageSpeed Insights.
3. Compara los datos de campo con los de laboratorio. Anota cuál de las tres métricas suspende.
4. Para el LCP, identifica el elemento y las cuatro partes del tiempo. Para el CLS, mira qué elementos se mueven. Para el INP, prueba en DevTools las interacciones más usadas.
5. Corrige una causa a la vez, publica y espera unos 28 días de datos de campo antes de concluir. Valida en Search Console.

¿Los Core Web Vitals pesan en el posicionamiento?

Pesan, pero poco y sin sustituir a la relevancia. La orientación de Google sobre la experiencia de página dice que la Búsqueda siempre intenta mostrar el contenido más relevante, aunque la experiencia de la página no sea buena, y que no hay una señal única: los sistemas miran varias señales ligadas a la experiencia general.

En la práctica: no sacrifiques contenido para ganar 0,2 segundos, y no ignores una página que suspende las tres métricas. Una página lenta y que se traba pierde visitantes antes de que intervenga cualquier algoritmo, lo cual es una razón práctica (conversión y retención) independiente del posicionamiento. En cuanto a la prioridad, el orden sensato es indexación y contenido primero, Core Web Vitals después y rendimiento fino al final. La auditoría de SEO paso a paso muestra dónde encaja esta revisión, y la lista de verificación de SEO on-page cubre los elementos de la propia página.

Ejemplo hipotético: una tienda tiene una página de categoría con un LCP de 3,8 s. El elemento de LCP es un banner promocional que se carga por JavaScript después de todo lo demás. El equipo aplica fetchpriority="high" al banner, elimina el loading="lazy" y lo sirve en el HTML inicial. El LCP de laboratorio baja hasta cerca del umbral bueno. El resultado en datos de campo solo aparece tras unas cuatro semanas, y el efecto en el posicionamiento, si lo hay, será discreto. La ganancia segura es la experiencia de quien accede.

Preguntas frecuentes

¿Los Core Web Vitals son un factor de posicionamiento de Google?

Sí, forman parte de las señales de experiencia de página, pero Google deja claro que la relevancia del contenido va primero y que no hay una única señal decisiva. Los buenos valores ayudan, pero no compensan un contenido débil. Trátalos como parte de una base sana, junto con la indexación, el contenido y los enlaces.

¿Qué cambió del FID al INP?

El FID solo medía el retraso de la primera interacción. El INP observa todos los clics, toques y teclas de la visita e incluye el tiempo hasta que el navegador muestra el resultado. Pasó a ser un Core Web Vital estable el 12 de marzo de 2024, y el FID se retiró. Por eso el INP es más exigente y revela problemas que el FID ocultaba.

¿Por qué PageSpeed Insights muestra notas distintas a las de Search Console?

Porque miden cosas diferentes. Search Console usa datos de campo agregados por grupo de URL, con un historial de 28 días. PageSpeed Insights muestra la URL concreta, con datos de campo cuando existen y una prueba de laboratorio simulada. Las divergencias son normales. Usa el campo para decidir y el laboratorio para depurar.

Mi sitio tiene poco tráfico y no aparecen datos de campo. ¿Y ahora?

Sin volumen suficiente, CrUX no publica datos de la URL, y PageSpeed Insights usa el origen o no muestra nada. En ese caso, usa las pruebas de laboratorio como guía, sigue las buenas prácticas de cada métrica y, si quieres datos reales, instala la biblioteca web-vitals en el sitio para recopilar tus propias mediciones.

Siguiente paso

Si tu sitio aún tiene problemas básicos de indexación, resuélvelos antes de optimizar milisegundos: repasa cómo rastrea, indexa y posiciona Google y configura Google Search Console para seguir los informes de experiencia. Si publicas artículos en WordPress y quieres mantener el ritmo de contenido, mira cómo Contentor genera artículos con IA y revisa el resultado con las buenas prácticas de esta guía.

Lee también:

• SEO técnico para quien no es programador: lo esencial
• Auditoría de SEO paso a paso: técnico, contenido y autoridad
• SEO on-page: lista de verificación completa para cada página