Core Web Vitals en 2026: métricas actuales
Las métricas actuales son LCP, INP y CLS. LCP mide rendimiento de carga, INP capacidad de respuesta y CLS estabilidad visual. Google las presenta como aspectos clave de la experiencia real del usuario. [1][3]
FID ya no forma parte del conjunto. INP sustituyó a FID en marzo de 2024 y FID fue retirado posteriormente de CrUX. [7][14]
Umbrales y percentil 75
| Métrica | Bueno | Necesita mejora | Malo | Qué mide |
|---|---|---|---|---|
| LCP | ≤ 2.5 s | 2.5 s - 4.0 s | > 4.0 s | Carga del contenido principal |
| INP | ≤ 200 ms | 200 ms - 500 ms | > 500 ms | Capacidad de respuesta |
| CLS | ≤ 0.1 | 0.1 - 0.25 | > 0.25 | Estabilidad visual |
Los valores buenos son LCP ≤ 2,5 s, INP ≤ 200 ms y CLS ≤ 0,1. Necesitan mejora entre 2,5 y 4,0 s, 200 y 500 ms y 0,1 y 0,25. Por encima son malos. [3][4]
Google usa el percentil 75, no la media. Al menos el 75% de experiencias debe cumplir el umbral o mejorarlo. Mobile y desktop se evalúan por separado. [3][4]
Para aprobar, las tres métricas deben estar en el rango bueno. [3]
Core Web Vitals y SEO
Google confirma que Core Web Vitals forma parte de sus sistemas de ranking como señal de experiencia de página. Buenas métricas no garantizan una posición alta porque la relevancia y la calidad del contenido siguen siendo fundamentales. [1][2]
La optimización mejora la experiencia real y elimina una debilidad técnica, pero no sustituye una buena estrategia de contenido.
LCP: qué mide realmente
Largest Contentful Paint mide desde el inicio de la navegación hasta que se renderiza el mayor elemento de contenido elegible dentro del viewport. En campo puede incluir redirecciones, establecimiento de conexión y TTFB. [5]
LCP no es simplemente el tiempo de descarga de la imagen más grande. El retraso puede empezar mucho antes de descargar el recurso. [5][6]
LCP en la práctica: cuatro partes
web.dev divide LCP en TTFB, retraso de carga del recurso, duración de carga y retraso de renderizado del elemento. [6]
Si el recurso LCP se descubre tarde, comprimirlo puede no cambiar el resultado. Debe ser detectable pronto en el HTML inicial y una imagen LCP no debe cargarse con lazy loading. La prioridad o preload pueden ayudar. [6]
Diagnostica en este orden: TTFB, descubrimiento del recurso, transferencia y retraso de renderizado. [6]
- Reduce TTFB con caché, CDN, menos redirecciones y un backend más rápido.
- Expón el recurso LCP en el HTML inicial.
- No uses `loading="lazy"` para la imagen LCP.
- Usa prioridad adecuada o preload si se descubre tarde.
- Optimiza tamaño y formato solo cuando la transferencia sea el cuello de botella.
- Reduce JavaScript o CSS que bloquee el renderizado final.
INP: capacidad de respuesta durante toda la visita
Interaction to Next Paint observa clics, toques y teclado durante toda la visita. En la mayoría de páginas se informa de la interacción más lenta. En páginas con muchas interacciones se ignora una peor interacción por cada 50 para reducir anomalías. [7]
INP no es FID: incluye retraso de entrada, procesamiento y tiempo hasta el siguiente paint. [7][8]
Si no hay clics, toques o teclado, una visita puede no tener INP. Scroll y hover no cuentan. [7]
INP en la práctica: tres fuentes de latencia
La latencia total incluye input delay, processing duration y presentation delay. Un INP malo puede venir de un main thread ocupado, handlers lentos o layout y rendering costosos. [8]
Las mejoras habituales son tareas más cortas, dividir trabajo, reducir JavaScript pesado, simplificar layout, usar Web Workers cuando proceda y dar feedback visual rápido. [8]
Empieza con datos RUM que identifiquen la interacción lenta y después reprodúcela en DevTools. Lighthouse por sí solo no representa el INP real completo. [8][11][12]
CLS: estabilidad visual durante toda la vida de la página
Cumulative Layout Shift mide movimientos inesperados de elementos visibles. Usa la mayor ventana de sesión donde los desplazamientos consecutivos están separados por menos de un segundo y la ventana completa dura como máximo cinco segundos. [9]
CLS no tiene unidad y combina impacto y distancia del movimiento. Algunos cambios ligados directamente a una interacción pueden quedar excluidos. [9]
Los problemas suelen aparecer después de la carga por anuncios, banners, widgets o fuentes. Un único test de laboratorio puede no detectarlos. [10][11]
CLS en la práctica: causas frecuentes
web.dev señala imágenes sin dimensiones, anuncios, embeds e iframes sin espacio reservado, contenido inyectado y web fonts como causas habituales. [10]
Reserva espacio antes de que aparezca el contenido. Usa `width` y `height` o `aspect-ratio`, define dimensiones para anuncios y embeds y evita insertar contenido encima de lo que el usuario ya está leyendo. [10]
Con fuentes, reduce diferencias métricas entre fallback y fuente final y mide el efecto real. `font-display` no resuelve todos los casos por sí solo. [10]
Datos de campo frente a laboratorio
Core Web Vitals son principalmente métricas de campo. CrUX y RUM reflejan usuarios reales, mientras Lighthouse sirve para reproducir y diagnosticar en condiciones controladas. [11][12]
Lighthouse no mide el INP completo de una visita natural y utiliza métricas como TBT como apoyo de laboratorio. CLS de laboratorio también puede ser menor si los desplazamientos aparecen después de interacciones. [11][12]
Usa campo para saber si existe un problema real y laboratorio para encontrar la causa.
Qué herramienta usar
| Herramienta | Tipo de datos | Mejor uso |
|---|---|---|
| PageSpeed Insights | CrUX + Lighthouse | Evaluación rápida de URL y origin |
| Search Console | CrUX, grupos de URL | Encontrar grupos con problemas SEO |
| Chrome DevTools | Laboratorio + contexto CrUX | Diagnóstico detallado de LCP, INP y CLS |
| Lighthouse | Laboratorio | Auditorías automáticas y regresiones en CI |
| RUM / web-vitals | Datos de tus usuarios | Monitorización y diagnóstico más precisos |
PageSpeed Insights combina CrUX y Lighthouse. Search Console agrupa URL similares. DevTools ofrece métricas en vivo y trazas detalladas. [12][13]
CrUX API y PageSpeed Insights utilizan una ventana móvil de aproximadamente 28 días. Una mejora reciente no cambia inmediatamente el p75 público. RUM propio permite verlo antes. [12][13]
Un flujo sólido usa RUM para monitorizar, Search Console para grupos SEO, PSI para controles rápidos y DevTools para diagnóstico.
CrUX en 2026: estado reciente de la web
| Métrica | Origins con buen resultado, julio de 2026 |
|---|---|
| LCP | 68,3% |
| INP | 85,7% |
| CLS | 81,6% |
| Todos los Core Web Vitals | 55,7% |
El último dataset mensual publicado antes del 4 de septiembre de 2026 corresponde a julio de 2026 y se publicó el 11 de agosto. Incluye 18.059.068 origins. El 68,3% tuvo buen LCP, 81,6% buen CLS, 85,7% buen INP y 55,7% aprobó los tres Core Web Vitals. [14]
Son cifras agregadas del web representado en CrUX, no objetivos individuales. CrUX exige, entre otros criterios, descubribilidad pública y suficiente popularidad. [13][14]
No tener datos CrUX no significa que una página sea rápida o lenta, sino que no hay datos elegibles suficientes.
SPA y soft navigations: cambio importante en 2026
Históricamente Core Web Vitals se centró en navegaciones completas. Chrome 151 introdujo en 2026 nuevas API para medir soft navigations y la documentación se actualizó el 2 de septiembre de 2026. [15]
Chrome DevTools 152, publicado el 25 de agosto de 2026, muestra Core Web Vitals de soft navigations en Live Metrics por defecto mediante `web-vitals` 6.0.0. [16]
Es relevante para React, Angular, Vue y otras SPA. No debe asumirse que todos los informes públicos de CrUX ya tratan las soft navigations exactamente igual.
Monitorización en producción con contexto
Un p75 público suele indicar que existe un problema sin mostrar la causa. RUM propio puede adjuntar elemento y subpartes de LCP, interacción INP, route, dispositivo y versión de la aplicación. web.dev recomienda RUM como complemento de CrUX. [3][8][12]
Etiqueta despliegues por versión y compara distribuciones antes y después. Una media puede ocultar regresiones en dispositivos lentos.
CI evita regresiones obvias de laboratorio, pero no sustituye la monitorización en producción. [11][12]
Plan práctico de mejora
Identifica primero qué métrica falla en p75 y en qué tipos de página. Reduce el problema con RUM o CrUX, reprodúcelo en DevTools, corrige la causa concreta y monitoriza después del despliegue. [12]
Para LCP encuentra la subparte dominante, para INP la interacción real más lenta y para CLS los desplazamientos y elementos concretos.
Comprueba después datos de laboratorio y de campo. CrUX público tarda en reflejar un release, por lo que RUM es útil para validación rápida.
- Identifica primero el problema en datos de campo.
- Separa mobile y desktop.
- Para LCP revisa TTFB, descubrimiento, transferencia y retraso de renderizado.
- Para INP analiza la interacción y sus tres fases.
- Para CLS registra desplazamientos durante toda la sesión.
- Publica una mejora medible y compara antes y después.
- Mantén RUM y alertas de regresión activas.
