Core Web Vitals: qué mide Google y cómo se arregla

Las tres métricas y sus umbrales, sin rodeos

Estos son los números que usa Google para clasificar cada URL como buena, mejorable o deficiente. Se calculan por separado en móvil y en escritorio, y el grupo móvil es el que más pesa en la práctica.

Métrica	Qué mide	Bien	Mejorable	Deficiente
LCP · Largest Contentful Paint	Cuándo se pinta el elemento visible más grande (imagen principal, titular o bloque de texto)	≤ 2,5 s	2,5 – 4,0 s	> 4,0 s
INP · Interaction to Next Paint	Cuánto tarda la página en mostrar respuesta visual tras un toque, clic o pulsación de tecla	≤ 200 ms	200 – 500 ms	> 500 ms
CLS · Cumulative Layout Shift	Cuánto se desplaza el contenido de forma inesperada durante la carga	≤ 0,1	0,1 – 0,25	> 0,25

Dos matices que cambian la forma de trabajar. El primero: los datos que puntúan son los de usuarios reales (el informe de experiencia del usuario de Chrome), no los de una prueba puntual. El segundo: se evalúa el percentil 75. Si 100 visitas cargan el LCP y solo 20 van lentas, la URL ya suspende. Con una conexión rápida en la oficina no se ve el problema; con un móvil de gama media y cobertura irregular, sí.

INP sustituyó a First Input Delay en marzo de 2024. La diferencia importa: FID solo medía el retardo de entrada, e INP mide el tiempo completo hasta que la interfaz responde de verdad. Muchas webs que aprobaban con FID suspendieron con INP sin haber tocado una línea de código.

Datos de campo frente a datos de laboratorio

La confusión más habitual es creer que una puntuación alta en un test equivale a aprobar. No es así, y conviene tenerlo claro antes de invertir dinero.

• Datos de campo (los que puntúan): recogidos de visitas reales durante ventanas de 28 días. Se consultan en el informe Core Web Vitals de Search Console, en PageSpeed Insights y en el panel de CrUX.
• Datos de laboratorio (para diagnosticar): una carga simulada con red y dispositivo controlados. Sirve para reproducir el problema y comprobar cambios rápido, con la ventaja de que no hay que esperar cuatro semanas.
• Regla práctica: el laboratorio dice qué arreglar, el campo dice si ha funcionado. Trabajar solo con uno de los dos lleva a optimizar cosas que no mueven nada.

Idealmente, se instrumenta además la medición propia con la librería web-vitals enviando los valores a GA4 o a un panel interno. Así se ve la evolución por plantilla y no solo un promedio global de todo el sitio.

LCP: qué lo causa y cómo bajarlo por debajo de 2,5 s

El LCP se compone de cuatro tramos y el problema suele estar en uno solo. Medir el tiempo hasta el primer byte (TTFB) antes de tocar nada ahorra semanas de trabajo mal dirigido.

• Servidor lento (TTFB alto). Si el primer byte tarda más de 800 ms, ninguna optimización de imágenes va a salvarte. Causas: hosting saturado, PHP mal configurado, consultas pesadas, sin caché de página ni de objetos. Aquí el arreglo está en el servidor y, a veces, en cambiar de hosting.
• Imagen principal demasiado grande. Es la causa número uno. Una foto de 2,5 MB en JPEG es un LCP de cuatro segundos en móvil. Solución: formatos AVIF o WebP, tamaño acorde al hueco real, srcset con varias resoluciones, loading="lazy" en todo excepto en el elemento LCP y fetchpriority="high" en él.
• Recursos que bloquean el renderizado. Hojas de estilo enormes, tipografías propias, scripts en el head que no son críticos. Se resuelve incrustando el CSS crítico, difiriendo el resto y precargando solo la fuente que se usa en la primera pantalla.
• Fuentes web. Sin font-display: swap ni precarga, el texto aparece tarde y con un salto visible. Dos familias tipográficas con cinco pesos cada una son un lastre innecesario.
• Caché y CDN mal resueltos. HTML sin caché, imágenes sin cabeceras de caché largas o CDN mal configurada para la zona de tus clientes.

Un caso frecuente: la web carga en 3,8 s en datos de campo y el 70 % del tiempo es la imagen del banner. Comprimir, redimensionar y precargar esa única imagen suele dejar el LCP por debajo del umbral sin tocar el diseño. Es el tipo de intervención que revisamos en el servicio de optimización web.

INP: la métrica que más suspende y menos se revisa

INP aparece cuando el visitante interactúa. Es la medida de cuánto tarda la página en reaccionar. Y suele fallar por exceso de JavaScript: cuanto más código se ejecuta en el hilo principal, más tarda la interfaz en contestar.

• Scripts de terceros. Widget de chat, mapas, vídeos incrustados, píxeles de publicidad, herramientas de analítica y test A/B. Cada uno añade decenas o cientos de milisegundos. La pregunta útil no es “¿puedo optimizarlo?” sino “¿aporta suficiente para lo que cuesta?”.
• Sliders y constructores visuales pesados. Un carrusel con animaciones de entrada y bibliotecas completas puede añadir más de un segundo de trabajo en móvil, para mostrar tres imágenes que el usuario casi nunca desliza.
• Tareas largas. Cualquier bloque de JavaScript que se ejecute más de 50 ms seguidos bloquea la respuesta. Se corrigen dividiendo el trabajo, difiriendo lo que no es urgente y cargando bajo demanda.
• Listeners innecesarios. Cientos de elementos con eventos de scroll o mousemove sin limitar por tiempo. Se resuelven con delegación de eventos y control de frecuencia.

El orden de actuación que mejor funciona: auditar qué scripts carga la plantilla, desactivar los que no se usan, sustituir los pesados por alternativas ligeras, cargar el resto en diferido y medir el efecto en datos de campo.

CLS: por qué la página “salta” al cargar

El CLS mide movimiento inesperado. Un diseño que se desplaza mientras alguien intenta pulsar un botón es un problema de confianza y, además, de conversión: hay clics que aterrizan en el sitio equivocado.

• Imágenes sin dimensiones. Si el navegador no sabe cuánto ocupan, reserva cero y el contenido salta al llegar el archivo. Se corrige con width y height en el HTML o con una relación de aspecto fija en CSS.
• Banners y avisos insertados arriba. Avisos de cookies, promociones o mensajes que empujan el contenido hacia abajo cuando el visitante ya está leyendo.
• Anuncios y bloques externos. Sin espacio reservado y sin altura mínima, cada carga desplaza el contenido a un punto distinto.
• Cambio de tipografía al cargar la fuente. Se mitiga ajustando métricas de fuente o usando una tipografía del sistema para el texto de la primera pantalla.

En qué orden conviene arreglarlo

Si el informe muestra varias métricas en rojo, no se ataca todo a la vez. Esta priorización es la que suele dar resultado en menos tiempo.

Prioridad	Actuación	Impacto típico	Esfuerzo
1	Optimizar el elemento LCP (imagen o titular) y precargarlo	Alto	Bajo
2	Caché de página, caché de objetos y CDN	Alto	Bajo-medio
3	Eliminar o diferir scripts de terceros que no aportan	Alto (INP)	Medio
4	Reservar espacio en imágenes, banners y anuncios	Medio (CLS)	Bajo
5	CSS crítico y carga diferida de lo no visible	Medio	Medio
6	Servidor: PHP, base de datos y recursos del plan	Alto si el TTFB es malo	Medio-alto

Todo se hace sobre copia, con plan de reversión y comprobando después que formularios, buscadores, filtros, pagos y analítica siguen funcionando. Optimizar sin red de seguridad es la forma más rápida de romper una tienda un viernes.

Los Core Web Vitals no son un truco de posicionamiento ni una promesa de primera posición: son el peaje de entrada. Una web lenta pierde posiciones y, sobre todo, pierde ventas antes de que Google opine nada.

Cuánto tarda en reflejarse la mejora

La ventana de datos de campo es de 28 días, así que los informes se mueven despacio. Es normal ver una mejora clara en laboratorio y no verla en Search Console hasta dos o tres semanas después. Un calendario realista:

• Días 1–7: los cambios están publicados y se confirman con pruebas de laboratorio y medición propia.
• Semanas 2–4: los datos de campo empiezan a recoger el nuevo comportamiento y el informe se actualiza parcialmente.
• Semanas 4–8: la ventana de 28 días queda limpia y el informe refleja la situación real por grupo de URLs.

Una precaución: no cambies cinco cosas a la vez. Si algo empeora, no sabrás qué lo causó. Y si el TTFB es el problema de fondo, ninguna optimización de front-end lo va a tapar; en ese caso, revisa cómo migrar de hosting sin perder posiciones, donde medimos el servidor antes de mover nada.

Conclusión: tres números, una ventana de 28 días y un orden de trabajo

LCP por debajo de 2,5 segundos, INP por debajo de 200 milisegundos y CLS por debajo de 0,1, medidos en el percentil 75 de usuarios reales. Eso es todo lo que Google evalúa. La dificultad no está en memorizar los umbrales, sino en saber si el problema es el servidor, la imagen principal, el JavaScript o un banner que empuja el contenido.

Empieza por el informe Core Web Vitals de Search Console y separa por plantillas: portada, categoría y ficha de producto. Casi siempre hay un grupo concreto de URLs que arrastra la media. Arregla ese grupo, mide y repite. Y si tu web ya está bien de rendimiento pero sigues sin aparecer, el trabajo está en otro sitio: SEO técnico y posicionamiento.