Puede ser complicado mejorar el Procesamiento de imagen con contenido más grande (LCP) de una página, ya que, a menudo, involucra varias partes móviles y desventajas. En esta publicación, se analizan los datos de campo de las cargas de páginas reales en toda la Web para determinar dónde los desarrolladores deben enfocar sus iniciativas de optimización.
Consejo clásico de LCP: ¡Reduce el tamaño de las imágenes!
En la mayoría de las páginas de la Web, el elemento LCP es una imagen. Por lo tanto, es normal suponer que la mejor manera de mejorar el LCP es optimizar la imagen del LCP.
A menudo, ese ha sido el consejo principal en los últimos cinco años desde que se introdujo el LCP. Asegúrate de que tus imágenes tengan el tamaño adecuado, estén bien comprimidas y quizá uses un formato del siglo XXI. Lighthouse incluso cuenta con tres auditorías diferentes para hacer estas sugerencias.
Parte de la razón por la que esto es un consejo tan común es que los bytes excesivos son fáciles de medir y las herramientas de compresión de imágenes son fáciles de sugerir. Según tus canalizaciones de implementación y compilación, también puede ser fácil de implementar.
Si es así, hazlo. Enviar menos bytes a tus usuarios casi siempre es una buena opción. Hay muchos sitios en la Web que aún entregan imágenes innecesariamente grandes que incluso la compresión básica solucionaría.
Sin embargo, cuando empezamos a analizar los datos de rendimiento de campo de los usuarios en Chrome para determinar dónde se suele dedicar el tiempo de LCP, descubrimos que el tiempo de descarga de imágenes casi nunca es el cuello de botella.
En cambio, otras partes del LCP son un problema mucho mayor.
Desglose de subpartes de LCP
A fin de comprender cuáles eran las áreas de mayor oportunidad para mejorar el LCP, analizamos los datos de las subpartes de LCP, como se describe en Optimiza el LCP.
Si bien cada página y framework pueden adoptar un enfoque diferente para cargar y mostrar lo que se convierte en el elemento LCP de la página, cada una se puede dividir en estas subpartes:
Citando de ese artículo, las subpartes son las siguientes:
- Tiempo hasta el primer byte (TTFB)
- El tiempo que transcurre desde que el usuario comienza a cargar la página hasta que el navegador Recibe el primer byte de la respuesta del documento HTML.
- Retraso en la carga de recursos
- Es el tiempo que transcurre entre el TTFB y el momento en el que el navegador comienza a cargar el recurso LCP. Si
El elemento de LCP no requiere una carga de recursos para su renderización. Esta vez, es
0. - Duración de la carga de recursos
- Es el tiempo que se tarda en cargar el recurso LCP. Si el LCP
no requiere una carga de recursos para renderizarse, esta vez es
0. - Retraso en la renderización de elementos
- El tiempo que transcurre entre el momento en que el recurso LCP termina de cargarse y el elemento de LCP por completo.
Datos reales de rendimiento de la navegación
| Clasificación de LCP | TTFB (ms) | Retraso en la carga de la imagen (ms) | Duración de la carga de la imagen (ms) | Retraso en el procesamiento (ms) |
|---|---|---|---|---|
| Bueno | 600 | 350 | 160 | 230 |
| Necesita mejoras | 1,360 | 720 | 270 | 310 |
| Deficiente | 2 270 | 1,290 | 350 | 360 |
En esta publicación, usamos datos de las navegaciones de páginas con un LCP de imagen de subrecursos en Chrome para observar las subpartes de LCP. Ya vimos este tipo de datos, pero nunca desde los datos de campo para ver dónde pasan su tiempo los usuarios reales mientras esperan el LCP de una página.
Al igual que con las Métricas web esenciales, tomamos el percentil 75 (p75) de cada subparte de LCP para cada origen en el conjunto de datos de CrUX, lo que generó cuatro distribuciones de valores de p75 (una para cada subparte). Para resumir estas distribuciones, tomamos la mediana de esos valores en todos los orígenes para cada una de las cuatro subpartes del LCP.
Por último, dividimos los orígenes en buckets en función de si tienen una “buena”, “necesita mejorar” o “deficiente” LCP en el percentil 75. Esto ayuda a mostrar qué distingue un origen con un LCP bueno de uno con un LCP bajo.
¿Quieres reducir el tamaño de la imagen de LCP? Esta vez con los datos
La duración de la carga es la medida del tiempo que se tarda en recuperar el recurso de LCP, en este caso, una imagen. Este tiempo suele ser proporcional a la cantidad de bytes de la imagen, por lo que se recomienda reducir esa cantidad de bytes en relación con el rendimiento.
Cuando se observa cómo se dirige el tiempo en los gráficos anteriores, lo que se destaca es que no se invierte mucho tiempo en la duración de la carga de imágenes. De hecho, es la subparte de LCP más corta, en todos los buckets de LCP. La duración de la carga es más larga para los orígenes de LCP deficientes en comparación con aquellos con un LCP bueno, pero todavía no es donde se invierte la mayor parte del tiempo.
La mayoría de los orígenes con un LCP deficiente pasan menos del 10% de su tiempo de LCP de p75 descargando la imagen de LCP.
Sí, debes asegurarte de que tus imágenes estén optimizadas, pero eso es solo una parte de mejorar el LCP. Y queda claro a partir de estos datos que, para el origen típico en la Web, las ganancias potenciales de milisegundos para el LCP en general son pequeñas, sin importar lo sofisticado que sea el esquema de compresión.
Una última sorpresa: se solía culpar a las duraciones de carga lentas en los dispositivos móviles y a la calidad de las redes móviles. Es posible que, antes, esperábamos que un teléfono típico tarde varias veces más en descargar la misma imagen que una máquina de escritorio con una conexión por cable. Los datos sugieren que eso ya no es así. Para los orígenes con un LCP deficiente, la mediana de duración de la carga de imágenes de p75 es solo un 20% más lenta en dispositivos móviles que en computadoras de escritorio.
Tiempo hasta el primer byte (TTFB)
Para las navegaciones que hacen una solicitud de red, el TTFB siempre tomará tiempo. Hacer una búsqueda de DNS e iniciar una conexión lleva tiempo. Y no puedes vencer a la física: una solicitud tiene que viajar a través del mundo real a través de cables y cables ópticos para llegar a un servidor y, luego, la respuesta tiene que hacer el viaje de regreso. Incluso el origen medio con un buen LCP pasa más de medio segundo en TTFB en su percentil 75.
Sin embargo, la disparidad de TTFB entre los orígenes de LCP buenos y malos muestra la oportunidad de mejorar. En al menos la mitad de los orígenes con un LCP deficiente, el p75 TTFB de 2,270 milisegundos solo casi garantiza que el LCP p75 no puede ser más rápido que el "bueno" de 2.5 segundos. umbral. Incluso una reducción moderada en el porcentaje de ese tiempo implicaría una mejora significativa en el LCP.
Es posible que no puedas vencer a la física, pero hay cosas que sí se pueden hacer. Por ejemplo, si tus usuarios suelen estar en una ubicación muy diferente a la de tus servidores, una CDN puede acercar tu contenido a ellos.
Para obtener más información, consulta la guía de optimización de TTFB.
Retraso en la carga de recursos: culpable de LCP lento que se pasa por alto
Si el TTFB se puede mejorar, pero cualquier mejora está sujeta a la física, la demora en la carga de recursos podría eliminarse, en la práctica, solo depende de tu arquitectura de entrega.
Esta subparte mide el tiempo desde la llegada del primer byte de la respuesta HTML (TTFB) hasta cuando el navegador inicia una solicitud para la imagen LCP. Nos hemos concentrado durante años en el tiempo que lleva descargar imágenes LCP, pero con frecuencia hemos ignorado el tiempo que se pierde antes de que se le diga al navegador que inicie la descarga.
El sitio medio con un LCP deficiente tarda casi cuatro veces más en esperar para comenzar a descargar la imagen de LCP que en realidad la descarga, y espera 1.3 segundos entre el TTFB y la solicitud de imagen. Eso es más de la mitad del presupuesto de 2.5 segundos del LCP que se gasta en una sola subparte.
Las cadenas de dependencias son una razón común de las demoras en las cargas prolongadas. En el lado más simple, se encuentra una página que carga una hoja de estilo que, una vez que el navegador realiza el diseño, establece una imagen de fondo que se convertirá en el LCP. Todos esos pasos deben realizarse incluso antes de que el navegador sepa que debe comenzar a descargar la imagen de LCP.
Usar datos de rastreo públicos de HTTP Archive, que registran el “iniciador” cadena de solicitudes de red del documento HTML a una imagen LCP, puedes ver la correlación clara de la longitud de la cadena de solicitudes con un LCP más lento.
La clave es permitir que el navegador sepa lo antes posible cuál será el LCP para que pueda empezar a cargarlo, incluso antes de que haya un lugar para él en el diseño de la página. Hay algunas herramientas disponibles para hacerlo, como una etiqueta <img> clásica en HTML para que el escáner de precarga pueda encontrarla rápidamente y comenzar a descargarla, o una etiqueta <link rel="preload"> (o encabezado HTTP) para imágenes que no serán <img>.
También es importante ayudar al navegador a determinar qué recursos priorizar. Sobre todo, si tu página realiza muchas solicitudes durante la carga de la página, ya que a menudo el navegador no sabrá cuál será el elemento LCP hasta que muchos de esos recursos se hayan cargado y se haya producido el diseño. La anotación del elemento LCP probable con un atributo fetchpriority="high" (y asegurarte de evitar loading="lazy") permite que el navegador comience a cargar el recurso de inmediato.
Obtén más consejos sobre la optimización del retraso de la carga.
Demora en la renderización
El retraso de renderización mide el tiempo que transcurre desde que el navegador tiene la imagen LCP cargada y lista, pero, por algún motivo, se produce un retraso antes de que se muestre en la pantalla. A veces, esta es una tarea larga que bloquea el subproceso principal cuando la imagen está lista; en otros casos, puede ser una elección de la IU revelar un elemento oculto.
Para el origen típico en la Web, no parece haber una gran oportunidad de retraso en la renderización, pero, durante la optimización, a veces, puedes crear un retraso de renderización del tiempo que antes se dedicó a otras subpartes. Por ejemplo, si una página comienza a precargar la imagen LCP para que esté disponible rápidamente, ya no habrá una larga demora en la carga, pero si la página en sí no está lista para mostrar la imagen, como a partir de una gran hoja de estilo que bloquea el procesamiento o una app de procesamiento del cliente que tiene que terminar de cargar todo su JavaScript antes de que se pueda mostrar algo, el LCP seguirá siendo más lento de lo que debería ser, y el tiempo de espera se mostrará como retraso de renderización ahora. Por eso, el procesamiento del servidor o el código HTML estático a menudo tienen una ventaja en relación con el LCP.
Si tu contenido se ve afectado, obtén más consejos para optimizar la demora en la renderización.
Marca todas esas subpartes
Está claro que, para optimizar el LCP de manera eficaz, los desarrolladores deben analizar la carga de páginas de manera integral y no solo enfocarse en optimizar las imágenes. Revisa cada parte del tiempo con el LCP, ya que es probable que existan oportunidades mucho más grandes de mejora.
Para recopilar estos datos en el campo, la compilación de atribución de la biblioteca web-vitals incluye los tiempos de las subpartes de LCP. El Chrome User Experience Report (CrUX) aún no incluye todos estos datos, pero sí tiene entradas para TTFB y LCP, por lo que es un comienzo. Esperamos incluir los datos que se usarán para esta publicación en CrUX más adelante, así que no te pierdas las novedades.
Para probar las subpartes del LCP de forma local, prueba la extensión de Métricas web o el fragmento de JavaScript de este artículo. Lighthouse también incluye el desglose en su "elemento de pintura con contenido más grande" auditoría. Busca más consejos sobre la subparte de LCP en el panel Rendimiento de Herramientas para desarrolladores (próximamente).