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

Qué son las Core Web Vitals

Las Core Web Vitals forman parte de la iniciativa Web Vitals de Google, que busca dar indicadores unificados de calidad de experiencia de usuario. En el momento de escribir, son tres:

Métrica	Qué mide	Bueno	Necesita mejorar	Deficiente
LCP — Largest Contentful Paint	Carga: cuándo se muestra el elemento de contenido más grande visible en pantalla.	≤ 2,5 s	2,5–4 s	> 4 s
INP — Interaction to Next Paint	Interactividad: cuánto tarda la página en responder visualmente a las interacciones del usuario.	≤ 200 ms	200–500 ms	> 500 ms
CLS — Cumulative Layout Shift	Estabilidad visual: cuánto se mueven inesperadamente los elementos mientras se usa la página.	≤ 0,1	0,1–0,25	> 0,25

INP sustituyó a FID (First Input Delay) como Core Web Vital en marzo de 2024. FID solo medía el retraso de la primera interacción; INP tiene en cuenta prácticamente todas las interacciones de la visita (clics, toques y pulsaciones de teclado) y mide la respuesta completa hasta que el navegador pinta el siguiente fotograma. Es una métrica bastante más exigente, y muchas webs que aprobaban con FID no aprueban con INP.

Cómo se evalúan: el percentil 75 de usuarios reales

Para decidir si una página o un sitio "aprueba", Google no usa una única medición, sino datos de usuarios reales de Chrome recogidos en el Chrome User Experience Report (CrUX). La regla es:

• Se toma el percentil 75 de las mediciones de cada métrica, por separado para móvil y escritorio. Es decir, el valor que cumplen al menos tres de cada cuatro visitas.
• Una página (o un grupo de páginas similares) se considera "buena" en Core Web Vitals si las tres métricas están en el umbral "bueno" en ese percentil.
• Los datos de CrUX son un agregado de los últimos 28 días, por lo que cualquier mejora tarda semanas en reflejarse por completo.

Si una URL no tiene suficiente tráfico para tener datos propios, las herramientas pueden mostrar datos agregados de un grupo de páginas similares o del origen completo. Webs pequeñas pueden no tener datos de campo en absoluto; en ese caso solo queda medir en laboratorio o instalar medición propia.

El percentil 75 explica por qué tu web puede ir "rapidísima" en tu ordenador y suspender: lo que cuenta son los usuarios reales, muchos con móviles de gama media y conexiones irregulares.

Datos de campo frente a datos de laboratorio

Es la distinción más importante para no perder el tiempo:

	Datos de campo (RUM)	Datos de laboratorio
Origen	Visitas reales (CrUX o tu propia medición con la librería web-vitals).	Una carga simulada en condiciones controladas (Lighthouse).
Para qué sirven	Saber cómo es la experiencia real y si apruebas.	Diagnosticar causas y probar cambios antes de publicarlos.
INP	Se mide.	No se puede medir sin interacción real; Lighthouse usa Total Blocking Time (TBT) como aproximación.
Limitación	Retraso de 28 días en CrUX; poco detalle sobre causas.	Puede no parecerse a la experiencia de tus usuarios.

El flujo correcto es: usar los datos de campo para decidir qué arreglar y en qué plantillas, usar el laboratorio para entender por qué y validar la corrección, y volver a los datos de campo para confirmar el efecto.

Herramientas para medir

• Informe de Core Web Vitals de Search Console: agrupa URLs similares por estado y métrica; ideal para detectar plantillas problemáticas en todo el sitio.
• PageSpeed Insights: muestra arriba los datos de campo de CrUX para la URL y el origen, y debajo un análisis de laboratorio con Lighthouse y recomendaciones.
• Lighthouse y Chrome DevTools: el panel Performance permite grabar cargas e interacciones, ver tareas largas, el elemento LCP y los desplazamientos de diseño.
• CrUX vía su API, su panel o BigQuery: histórico y comparación con competidores, siempre que tengan suficiente tráfico.
• Medición propia (RUM): la librería JavaScript web-vitals enviando datos a GA4 u otra plataforma. Permite segmentar por página, dispositivo o país y, sobre todo, identificar qué elementos e interacciones causan los problemas.

Cómo montar tu propia medición de campo

Si CrUX no tiene datos suficientes de tus páginas, o necesitas saber por qué falla una plantilla, la medición propia compensa el esfuerzo. Una configuración mínima:

1. Carga la librería web-vitals y envía cada métrica a tu plataforma de analítica como evento, con su valor y su calificación.
2. Usa la versión con atribución de la librería para registrar el elemento LCP, el elemento de la interacción más lenta y el elemento que se desplaza.
3. Añade la plantilla de página y el tipo de dispositivo como parámetros para poder agregar por plantilla.
4. Informa del percentil 75, no de la media, para que tus cifras sean comparables con CrUX.

Cómo mejorar LCP

El elemento LCP suele ser la imagen principal (hero), un bloque de texto grande o un vídeo de cabecera. Su tiempo se puede descomponer en cuatro partes, y conviene saber cuál domina antes de actuar:

1. TTFB (tiempo hasta el primer byte): lo que tarda el servidor en empezar a responder.
2. Retraso de carga del recurso: cuánto tarda el navegador en empezar a descargar el recurso LCP desde que llega el HTML.
3. Duración de la carga del recurso: lo que tarda en descargarse.
4. Retraso de renderizado: el tiempo entre que el recurso está descargado y se pinta.

Correcciones habituales

• Servidor: caché de página completa, CDN, menos trabajo en el backend, alojamiento cerca de tus usuarios.
• Descubrimiento temprano: que la imagen LCP esté en el HTML inicial (no inyectada por JavaScript ni como fondo CSS cargado tarde), con fetchpriority="high" y, si hace falta, <link rel="preload">.
• No aplicar lazy loading a la imagen LCP. Es uno de los errores más frecuentes: loading="lazy" en la imagen hero retrasa justo lo que más importa.
• Peso: formatos modernos (AVIF, WebP), tamaños adecuados con srcset y compresión razonable.
• Bloqueos de renderizado: CSS crítico en línea, el resto diferido; scripts no esenciales con defer o async; fuentes web optimizadas.
• Sin ocultar el contenido tras pruebas A/B o animaciones que esperan a JavaScript para mostrarse.

Cómo mejorar INP

INP mide la latencia de las interacciones, y el valor que se reporta para una visita es, simplificando, el de una de sus peores interacciones. Cada interacción tiene tres fases: el retraso de entrada (el hilo principal está ocupado con otra cosa cuando el usuario toca), el tiempo de procesamiento (lo que tardan tus manejadores de eventos) y el retraso de presentación (lo que tarda el navegador en recalcular estilos, maquetar y pintar).

Correcciones habituales

• Reducir el JavaScript: eliminar código y scripts de terceros que no se usan, cargar el resto solo cuando hace falta. Los widgets de chat, mapas, reproductores y etiquetas de marketing son sospechosos habituales.
• Dividir tareas largas: las tareas de más de 50 ms bloquean el hilo principal. Trocea el trabajo y cede el control al navegador entre partes (por ejemplo con setTimeout o, donde esté disponible, scheduler.yield()).
• Dar respuesta visual inmediata: actualizar la interfaz primero (abrir el menú, marcar el botón) y hacer el trabajo pesado después.
• Evitar recálculos costosos: DOM muy grande, cambios de estilo que obligan a recalcular toda la página, lecturas y escrituras de diseño intercaladas.
• Revisar el gestor de etiquetas: cada etiqueta añadida en Tag Manager se ejecuta en el mismo hilo principal que tu web.

Cómo mejorar CLS

CLS suma la magnitud de los desplazamientos inesperados de los elementos visibles. No cuenta toda la visita: se agrupan los desplazamientos en "ventanas de sesión" (ráfagas de hasta 5 segundos con menos de 1 segundo entre cambios) y se toma la peor. Los desplazamientos que ocurren justo después de una interacción del usuario no cuentan.

Correcciones habituales

• Dimensiones en imágenes y vídeos: atributos width y height o aspect-ratio en CSS para que el navegador reserve el espacio.
• Espacio reservado para anuncios, iframes y elementos incrustados (mapas, reseñas, redes sociales), con una altura mínima.
• No insertar contenido encima del existente: banners de cookies, avisos o promociones que empujan la página hacia abajo. Mejor superpuestos o en un espacio reservado.
• Fuentes web: font-display adecuado, precarga de las fuentes críticas y ajustes de métricas (size-adjust) para que la fuente de reserva ocupe lo mismo.
• Animaciones con transform en lugar de propiedades que alteran el diseño (top, height…).
• Caché de avance y retroceso (bfcache): que la página sea apta mejora la experiencia al volver atrás y evita desplazamientos en esas navegaciones.

Problemas típicos según el tipo de web

Las causas se repiten según cómo esté construida la web. No es una regla fija, pero sirve para saber dónde mirar primero:

Tipo de web	Sospechosos habituales
CMS con muchos plugins (p. ej. WordPress)	Temas pesados y constructores visuales, plugins que cargan scripts en todas las páginas, alojamiento compartido lento (TTFB), sliders en la cabecera.
Plataformas de e-commerce alojadas	Aplicaciones de terceros que inyectan JavaScript (reseñas, chat, upsells), imágenes de producto sin dimensiones, banners promocionales que empujan el contenido.
Aplicaciones JavaScript (SPA)	Contenido renderizado solo en el cliente (LCP tardío), paquetes JavaScript grandes, hidratación que bloquea interacciones (INP).
Webs de medios y portales	Anuncios sin espacio reservado (CLS), muchas etiquetas de terceros (INP), imágenes grandes sin optimizar.
Webs inmobiliarias y de turismo	Galerías y mapas incrustados, buscadores con filtros pesados, vídeos en la cabecera.

En todos los casos, el paso decisivo es el mismo: identificar en los datos qué elemento es el LCP, qué interacción es la lenta y qué elemento se desplaza, y corregir exactamente eso.

Core Web Vitals y SEO: cuánto importan de verdad

Google incluye las Core Web Vitals entre las señales de experiencia de página que usan sus sistemas de clasificación, pero también ha dejado claro que la relevancia y la calidad del contenido pesan más: una página con mejor contenido puede superar a otra más rápida. Dicho de otro modo, aprobar las Core Web Vitals no te hará posicionar si el contenido no está a la altura, y suspenderlas raramente es la única causa de un mal posicionamiento.

Eso no las hace irrelevantes. En mercados competidos, donde varias páginas tienen contenido comparable, la experiencia puede marcar diferencias. Y su impacto en negocio es directo: una página que tarda en mostrarse o que mueve el botón justo cuando vas a tocarlo pierde usuarios, se mida o no en el ranking. Por eso las tratamos como parte del trabajo de desarrollo web y CRO, no solo como una casilla SEO.

Cómo priorizar

1. Empieza por el informe de Search Console y agrupa por plantilla (home, categoría, ficha, artículo).
2. Prioriza móvil y las plantillas con más tráfico orgánico y más conversiones.
3. Ataca la métrica que suspende, con la corrección que corresponde a su causa, no con una lista genérica de "optimizaciones".
4. Valida en laboratorio, publica y confirma con datos de campo tras unas semanas.
5. Establece un presupuesto de rendimiento para que las mejoras no se pierdan con el siguiente plugin o etiqueta.

Errores frecuentes

• Perseguir la puntuación de Lighthouse en lugar de las métricas de campo. Un 100 en laboratorio no garantiza aprobar con usuarios reales, y viceversa.
• Instalar un plugin de "optimización" que aplica lazy loading a todo, incluida la imagen LCP.
• Medir solo la home, cuando el tráfico orgánico llega sobre todo a fichas, categorías y artículos.
• Olvidar los scripts de terceros, que con frecuencia son la principal causa de un mal INP.
• Rediseñar sin presupuesto de rendimiento y descubrir el problema después de una migración.
• Esperar resultados inmediatos: los datos de CrUX tardan hasta 28 días en reflejar un cambio.

Conclusión

LCP, INP y CLS miden tres cosas que cualquier usuario nota: si la página aparece rápido, si responde cuando la tocas y si se queda quieta mientras la lees. Mídelas con datos de usuarios reales en el percentil 75, diagnostica en laboratorio y corrige la causa concreta de cada métrica. Si tu web suspende y no sabes por dónde empezar, nuestra auditoría técnica identifica las plantillas y los recursos responsables y prioriza las correcciones. Más términos en el glosario SEO.