Ver contenido
Guía Técnica de Core Web Vitals: LCP, CLS e INP Desglosados
Introducción
Saber que el umbral de LCP es 2.5 segundos no te dice qué arreglar cuando tu página lo excede. Esta guía desglosa cada Core Web Vital en sus subcomponentes técnicos medibles—los mismos que usan Chrome DevTools y el reporte de Lighthouse—para que puedas diagnosticar la causa raíz en lugar de adivinar. El UXR SEO Analyzer reporta estas tres métricas en su pestaña "Performance", pero este desglose técnico es lo que te permite decidir qué guía de nuestro Hub Técnico de Rendimiento aplicar primero.
LCP: Cuatro Subfases Medibles
Según la documentación de Chrome sobre performance insights, el tiempo total de Largest Contentful Paint se descompone en cuatro subfases. Idealmente, la mayor parte del tiempo de LCP debería consumirse cargando recursos, no esperando en retrasos:
| Subfase | Qué mide |
|---|---|
| TTFB | Desde que el usuario inicia la carga hasta que el navegador recibe el primer byte del HTML |
| Retraso de carga del recurso | El tiempo entre el TTFB y el momento en que el navegador empieza a cargar el recurso LCP (0 si el elemento no requiere un recurso, por ejemplo texto con fuente del sistema) |
| Duración de carga del recurso | Cuánto tarda en descargarse el recurso LCP mismo (0 si no requiere carga) |
| Retraso de renderizado del elemento | El tiempo entre que el recurso termina de cargar y el elemento LCP se renderiza completamente |
El objetivo es un LCP de 2.5 segundos o menos, reduciendo cada fase—especialmente las fases de retraso, que no aportan valor al usuario. Un LCP lento con TTFB alto apunta al servidor; un retraso de carga alto suele significar que el recurso no se descubrió temprano (falta un <link rel="preload"> o el recurso está oculto detrás de JavaScript).
CLS: La Fórmula del Layout Shift
A diferencia de LCP e INP, CLS no mide tiempo sino movimiento visual. Cada puntaje de layout shift se calcula así:
Puntaje de Layout Shift = Fracción de Impacto × Fracción de Distancia
Fracción de Impacto: porcentaje del viewport afectado por el cambio
Fracción de Distancia: qué tan lejos se movieron los elementos (como % del viewport)
Ejemplo: un elemento que cubre el 50% del viewport (fracción de impacto = 0.5) que se mueve un 25% de la altura del viewport (fracción de distancia = 0.25) produce un puntaje de 0.5 × 0.25 = 0.125.
Los cambios de diseño causados por interacción del usuario, o que ocurren dentro de los 500 ms posteriores a una entrada del usuario, no cuentan para CLS. Las animaciones con transform de CSS tampoco disparan un cambio de layout, porque no afectan el flujo del documento.
INP: Tres Subfases de la Interacción
INP también se descompone en tres subpartes, medidas sobre la interacción más lenta de la página:
| Subfase | Qué indica cuando es alta |
|---|---|
| Retraso de entrada (input delay) | La interacción fue retrasada por otro trabajo del hilo principal—puede que la interacción misma no sea la causa directa |
| Duración de procesamiento | El event handler de la interacción fue la causa directa de un INP lento |
| Retraso de presentación | Hubo un retraso en el renderizado para mostrar el resultado de la interacción después de que el event handler terminó de ejecutarse |
La recomendación de Chrome DevTools es enfocarse en reducir la fase más lenta, y probar varias interacciones distintas al grabar una traza para entender qué contribuye más al INP de una página. Activar el throttling de CPU en DevTools ayuda a diagnosticar interacciones lentas tal como se verían en dispositivos menos potentes.
Errores Comunes de Diagnóstico
Estos son los errores más frecuentes al interpretar un desglose de Core Web Vitals:
Optimizar la fase equivocada de LCP
Es común invertir horas comprimiendo una imagen (reduciendo la duración de carga del recurso) cuando el verdadero problema es el retraso de renderizado—por ejemplo, porque el elemento LCP está oculto detrás de una fuente web que aún no cargó, o porque JavaScript debe ejecutarse antes de que el navegador pueda pintar el elemento.
Confundir CLS acumulado con un solo evento
El puntaje de CLS que reporta una herramienta es la suma de todos los layout shifts que califican durante la sesión de la página (agrupados en ventanas de sesión), no un único evento. Un puntaje alto puede venir de muchos cambios pequeños en lugar de uno grande.
Optimizar INP mirando solo el promedio
INP se calcula sobre la interacción más lenta de la sesión del usuario (o cercana al percentil más alto en agregados de campo), no sobre el promedio de todas las interacciones. Una sola interacción lenta—como abrir un menú con un listener pesado—puede definir el INP de toda la página aunque el resto responda instantáneamente.
Datos de Laboratorio vs. Datos de Campo
Los desgloses de LCP e INP que muestra el panel de Performance de Chrome DevTools provienen de datos de laboratorio: una sola carga de página en condiciones controladas. Los datos de campo—reportados por CrUX y Search Console—agregan miles de sesiones reales con dispositivos y redes variados. Un desglose de laboratorio es ideal para depurar una causa específica; los datos de campo son los que determinan si tu página cumple el umbral "Bueno" para el 75% de los usuarios reales, que es el criterio que usa Google para el ranking.
Cómo se Conectan estos Desgloses con Nuestras Guías
- TTFB alto en LCP → revisa la Guía de Respuesta del Servidor
- Retraso de carga o render alto en LCP → revisa Recursos que Bloquean el Renderizado Explicado y la Guía de CSS Crítico
- Duración de procesamiento alta en INP → revisa la Guía de Rendimiento de JavaScript
Umbrales de Referencia
| Métrica | Bueno | Necesita Mejora | Pobre |
|---|---|---|---|
| LCP | ≤ 2.5s | 2.5s - 4.0s | > 4.0s |
| CLS | ≤ 0.1 | 0.1 - 0.25 | > 0.25 |
| INP | ≤ 200ms | 200ms - 500ms | > 500ms |
Ejemplo Práctico de Diagnóstico
Supongamos que una página de producto reporta un LCP de 4.2 segundos—en la zona "Pobre". El desglose muestra: TTFB 300ms, retraso de carga del recurso 2100ms, duración de carga 900ms, retraso de renderizado 900ms. El TTFB está bien; el problema evidente es el retraso de carga de 2.1 segundos, casi la mitad del tiempo total.
Ese patrón casi siempre significa que el navegador no descubrió la imagen del producto hasta tarde—típicamente porque se carga vía JavaScript después de la hidratación, o porque una fuente web bloqueante retrasó el parseo del CSS que la referencia. La solución no es comprimir la imagen (eso solo reduciría los 900ms de duración de carga); es adelantar el descubrimiento con un <link rel="preload"> en el <head> o renderizando la imagen en el HTML inicial en lugar de inyectarla con JavaScript.
Cómo Medir Cada Desglose
El panel de Performance de Chrome DevTools muestra el desglose de LCP e INP directamente en el marcador de la línea de tiempo cuando grabas una traza. La librería JavaScript web-vitals expone estos mismos subcomponentes en producción a través de su API de atribución, lo que permite enviar el desglose a tu sistema de analítica en lugar de solo el número final.
Preguntas Frecuentes
¿Por qué mi LCP es lento si el recurso se descarga rápido?
Revisa el retraso de carga y el retraso de renderizado. Un recurso que se descarga rápido pero se descubre tarde—porque está oculto detrás de JavaScript o falta un preload—sigue produciendo un LCP lento.
¿CLS puede ser negativo?
No. El puntaje siempre es positivo o cero; se acumula durante toda la sesión de la página dentro de las ventanas de sesión que define el algoritmo de CLS.
¿Cómo sé si mi INP lento es un problema de JavaScript o de renderizado?
El desglose te lo dice directamente: duración de procesamiento alta apunta a tu código; retraso de presentación alto apunta al trabajo de renderizado posterior (estilo, layout, pintado).
¿Estos desgloses aplican igual en móvil y escritorio?
Las subfases son las mismas, pero los números normalmente no. Los dispositivos móviles suelen mostrar mayor retraso de entrada y duración de procesamiento por CPUs más lentas, y mayor TTFB en redes celulares. Siempre diagnostica y prueba en la clase de dispositivo que más usan tus usuarios reales, no solo en escritorio.
Guías Relacionadas
Referencias
- Chrome Developers - LCP breakdown
- Chrome Developers - INP breakdown
- web.dev - Cumulative Layout Shift (CLS)
- Chrome Developers - CrUX methodology: metrics