Diagnostica el LCP con el panel de rendimiento de Chrome DevTools

Esta guía es parte del hub de Largest Contentful Paint (LCP). Cubre una herramienta: el panel Performance de Chrome DevTools. Grabarás un trace con throttling, leerás las cuatro subpartes del LCP y sabrás cuál corregir primero.

DevTools va al final, no al principio

El panel Performance es una herramienta de laboratorio. Mide una carga de página, en un dispositivo, en una red: la tuya. Por eso es el lugar equivocado para empezar y el correcto para terminar.

Empieza con el field data. CrUX te dice si el LCP es realmente un problema. Los datos de RUM te dicen qué páginas y qué elementos son lentos para tus usuarios reales. Ese flujo de trabajo está cubierto paso a paso en Fix & Identify LCP Issues. DevTools luego responde la única pregunta restante: por qué.

Si omites el field data, terminas optimizando la página que casualmente pruebas en la conexión que casualmente tienes. Este es el patrón que veo en casi toda auditoría: la máquina del desarrollador aprueba, el p75 de CrUX falla y todos están confundidos. Mediste una laptop rápida con fibra. Tus usuarios están en un Android de gama media en un tren.

La vista de métricas en vivo

Abre DevTools (Ctrl+Shift+I en Windows y Linux, Cmd+Option+I en Mac) y ve a la pestaña Performance. El panel ya no se abre vacío. Antes de grabar nada, muestra una vista de métricas en vivo con el LCP, el CLS y el INP de la página en la que estás, medidos localmente mientras navegas.

Tres cosas en esta vista son útiles para el trabajo de LCP. Primero, nombra el elemento LCP, y al pasar el cursor sobre él, resalta el elemento en la página. Así que no hay que adivinar qué imagen o encabezado eligió el navegador. También puedes habilitar el field data en esta vista. DevTools luego extrae los números de CrUX para la URL y el origen y los muestra junto a tus valores locales. Si tu LCP local marca 0,8 segundos y el p75 de field data marca 3,1 segundos, esa diferencia es tu primer hallazgo: tu máquina no es representativa y el throttling no es opcional.

Un consejo rápido: si quieres que el elemento LCP se resalte en cualquier página sin abrir DevTools, usa nuestra extensión gratuita de Chrome Core Web Vitals Visualizer.

Configura el throttling antes de grabar

Un trace sin throttling en la máquina de un desarrollador casi no sirve para nada. Los números serán geniales y ninguno coincidirá con lo que experimentan tus usuarios. Configura el throttling de CPU y de red en el panel antes de grabar.

• Throttling de CPU: usa 4x slowdown como valor por defecto para pruebas móviles. 20x se aproxima a un dispositivo de gama baja. Las versiones recientes de Chrome también pueden calibrar presets para tu máquina específica: la opción Calibrate genera presets móviles de gama baja y media basándose en la velocidad de tu propio hardware. Esto importa porque 4x en una PC de escritorio rápida es un dispositivo muy diferente a 4x en una laptop vieja.
• Throttling de red: usa Slow 4G. Este es el preset que solía llamarse Fast 3G antes de que Chrome lo renombrara, y es lo que simula Lighthouse para móviles. Fast 4G es la opción más ligera para probar conexiones mejores.

Cuando el field data está habilitado, DevTools incluso puede recomendar un preset de throttling que coincida con lo que experimentan tus usuarios reales. Úsalo. Para conocer el razonamiento completo detrás de estas configuraciones, lee nuestra guía sobre las mejores configuraciones de red de DevTools para los Core Web Vitals.

Graba una carga de página

Haz clic en el botón "Record and reload". Chrome navega a una página en blanco, inicia el trace, carga tu página y detiene la grabación por sí solo un par de segundos después de que finaliza la carga. Para el LCP no necesitas tocar nada durante la grabación. Mantén tus manos lejos de la página.

Un consejo rápido: graba en una ventana de incógnito con las extensiones desactivadas. Las extensiones inyectan scripts en cada página, y esos scripts aparecen en tu trace como long tasks que no tienen nada que ver con tu sitio.

Lee el insight de LCP breakdown

Después de que se completa el trace, la barra lateral de Insights a la izquierda enumera lo que DevTools encontró. El que buscas es LCP breakdown (las versiones anteriores de Chrome lo llaman LCP by phase). Divide el tiempo del LCP en sus cuatro subpartes:

Para un LCP de texto sin una webfont no hay nada que descargar, así que las dos subpartes de recurso son cero y la historia completa es el TTFB más el render delay.

Pasa el cursor sobre una subparte en el insight y DevTools resalta esa ventana exacta en la línea de tiempo. Hazle clic y la línea de tiempo se acerca, para que puedas ver qué requests y tareas caen dentro de esa ventana. Y si habilitaste el field data, el insight muestra el valor del p75 de CrUX junto a cada subparte de laboratorio (cuando CrUX tiene datos de LCP de imagen para tu sitio). Esa comparación es la función más infravalorada del panel. Te dice si el trace que observas se parece a lo que experimentan tus usuarios reales, antes de que pases una tarde corrigiéndolo.

¿Cómo debería verse un breakdown saludable? La recomendación de Google es que las dos subpartes de delay estén cerca de cero (menos del 10% del LCP cada una), y casi todo el tiempo vaya al TTFB y a la descarga real. Nuestra propia investigación de los Core Web Vitals en millones de cargas de página muestra lo lejos que está la realidad de eso: el TTFB toma el 48%, el load delay el 24%, el load duration solo el 10% y el render delay el 17%. Lee eso de nuevo: en el sitio mediano, las dos fases de espera juntas desperdician cuatro veces más tiempo que la descarga en sí. Nada se está descargando durante esas fases. Nada se está renderizando tampoco. El navegador está esperando trabajo que podría haber empezado antes, y por eso estas dos subpartes son el primer lugar donde buscar mejoras.

El insight de LCP request discovery

Cuando el LCP es una imagen, hay un segundo insight que vale la pena abrir: LCP request discovery. Ejecuta tres verificaciones en el request del LCP:

• ¿Se le aplica fetchpriority="high" a la imagen (o a su preload)?
• ¿El request es descubrible en el documento HTML inicial?
• ¿El lazy loading está correctamente no aplicado a ella?

Cualquier verificación fallida apunta a un problema de descubrimiento. El insight también anota en la línea de tiempo el momento en que la imagen podría haber empezado a descargarse y una estimación del tiempo que estás perdiendo. Cada una de estas tres fallas tiene una solución concreta, y todas están cubiertas en la guía de Resource Load Delay.

Lee la línea de tiempo tú mismo

Los insights cubren los casos comunes. Para todo lo demás, lee el trace directamente. Tres tracks importan para el LCP.

El track de Timings muestra marcadores para el FCP, el LCP, DCL y el evento load. El marcador del LCP es el momento en que se pintó el elemento. Todo lo que estás diagnosticando ocurre a su izquierda.

El track de Network muestra cada request. Encuentra el recurso del LCP y mira cuándo empieza, no solo cuánto tarda. Un request que empieza a los 2,5 segundos en un LCP de 3 segundos es un problema de descubrimiento, y ninguna cantidad de compresión de imagen lo salvará. Si hubieras hecho esa imagen descubrible desde los primeros bytes del HTML, la descarga habría comenzado mientras el navegador aún estaba parseando el head.

El track Main muestra el trabajo del main thread. Las long tasks están marcadas con un triángulo rojo en la esquina. El patrón a buscar: el recurso del LCP terminó de descargarse, pero el marcador del LCP está cientos de milisegundos más a la derecha. Esa brecha es element render delay, y una de esas tareas marcadas suele ser la causante. Pasa el cursor sobre la tarea para ver qué script es el responsable. En mi experiencia, es un tag manager o un script de consentimiento mucho más a menudo que tu propio código.

Corrige lo que encontraste

La subparte más grande en el breakdown decide a dónde vas después: TTFB, Resource Load Delay, Resource Load Duration o Element Render Delay. Si el elemento LCP es una imagen, la guía Optimize the LCP Image abarca las cuatro.

Una nota final: una página prerenderizada muestra las cuatro subpartes casi en cero, porque el navegador hizo todo el trabajo antes de que el usuario hiciera clic. Si tu problema de LCP es en navegaciones dentro de tu sitio en lugar de en landing pages, las speculation rules pueden evitar todo el diagnóstico.