Efectos del rendimiento de demasiada carga diferida

Consejos basados en datos para la carga diferida de imágenes teniendo en cuenta las Core Web Vitals.

Felix Arntz

Rick Viscomi

La carga diferida es una técnica que pospone la descarga de un recurso hasta que se necesita, para conservar los datos y reducir la contención de la red para los recursos críticos. Se convirtió en un estándar web en 2019 y, hoy en día, la mayoría de los navegadores principales admiten loading="lazy" para las imágenes.

En esta guía, se resume cómo se analizaron los datos de transparencia web disponibles públicamente y las pruebas A/B ad hoc para comprender las características de adopción y rendimiento de la carga diferida de imágenes a nivel del navegador. Entre los hallazgos, se descubrió que la carga diferida puede ser una herramienta increíblemente eficaz para reducir los bytes de imágenes innecesarios, pero el uso excesivo puede afectar negativamente el rendimiento. En concreto, este análisis muestra que cargar imágenes de forma más rápida dentro del viewport inicial, mientras se carga de forma diferida el resto, puede darnos lo mejor de ambos mundos: menos bytes cargados y mejores métricas web esenciales.

Adopción

Según los datos más recientes de HTTP Archive, el 29% de los sitios web usa la carga diferida de imágenes integrada, y la adopción está creciendo rápidamente.

Consultar los datos sin procesar en el proyecto HTTP Archive nos permite comprender con mayor claridad qué tipos de sitios web impulsan la adopción: el 84% de los sitios que usan la carga diferida de imágenes a nivel del navegador usan WordPress, el 2% usa otro CMS y el 14% restante no usa un CMS conocido. Estos resultados dejan en claro que WordPress lidera la adopción.

También vale la pena destacar la tasa de adopción. Hace un año, en julio de 2020, los sitios de WordPress que usan la carga diferida representaban decenas de miles de sitios web en el corpus de alrededor de 6 millones (1% del total). Desde entonces, la adopción de la carga diferida solo en WordPress creció a más de 1 millón de sitios web (14% del total).

Rendimiento correlacional

Si profundizamos en HTTP Archive, podemos comparar el rendimiento de las páginas con y sin carga diferida de imágenes a nivel del navegador con la métrica Largest Contentful Paint (LCP). Los datos de LCP provienen de experiencias de usuarios reales del Informe sobre la experiencia del usuario en Chrome (CrUX), en lugar de pruebas sintéticas en el laboratorio. En el siguiente gráfico, se usa un diagrama de caja y bigotes para visualizar las distribuciones del LCP del percentil 75 de cada página: las líneas representan los percentiles 10 y 90, y las cajas representan los percentiles 25 y 75.

La página mediana sin carga diferida tiene un LCP en el percentil 75 de 2,922 milisegundos, en comparación con los 3,546 milisegundos de la página mediana con carga diferida. En general, los sitios web que usan la carga diferida suelen tener un peor rendimiento de LCP.

Es importante señalar que estos son resultados correlacionales y no necesariamente indican que la carga diferida sea la causa del rendimiento más lento. Hipotéticamente, si los sitios de WordPress tienden a ser un poco más lentos, y dado que constituyen una gran parte de la cohorte de carga diferida, eso podría explicar la diferencia. Para eliminar esa variabilidad, el enfoque se puede limitar específicamente a los sitios de WordPress.

Lamentablemente, surge el mismo patrón cuando se analizan en detalle las páginas de WordPress; aquellas que usan la carga diferida tienden a tener un rendimiento de LCP más lento. La página de WordPress promedio sin carga diferida tiene un LCP en el percentil 75 de 3,495 milisegundos, en comparación con los 3,768 milisegundos de la página promedio con carga diferida.

Esto aún no demuestra que la carga diferida provoque que las páginas se vuelvan más lentas, pero su uso coincide con un rendimiento más lento. Para tratar de responder la pregunta sobre la causalidad, se configuró una prueba A/B de laboratorio.

Rendimiento causal

El objetivo de la prueba A/B era probar o refutar la hipótesis de que la carga diferida de imágenes integrada, tal como se implementa en el núcleo de WordPress, generaba un rendimiento de LCP más lento y menos bytes de imagen. La metodología que se usó fue probar un sitio web de demostración de WordPress con el tema twentytwentyone. Se probaron los tipos de páginas de archivo y de una sola página, que son como las páginas de inicio y de artículos, en computadoras de escritorio y dispositivos móviles emulados con WebPageTest. Se probaron todas las combinaciones de páginas con y sin carga diferida habilitada, y cada prueba se ejecutó nueve veces para obtener el valor de LCP mediano y la cantidad de bytes de imagen.

En estos resultados, se compara la mediana del LCP en milisegundos para las pruebas en páginas de archivo y páginas individuales en computadoras de escritorio y dispositivos móviles. Cuando se inhabilitó la carga diferida en las páginas de archivo, el LCP mejoró de forma significativa. Sin embargo, en las páginas individuales, la diferencia fue menor.

Inhabilitar la carga diferida parece hacer que las páginas individuales sean un poco más rápidas. Sin embargo, la diferencia en el LCP es inferior a una desviación estándar para las pruebas en computadoras de escritorio y dispositivos móviles, por lo que esto podría atribuirse a la variación y considerar el cambio como neutral en general. En comparación, la diferencia para las páginas de archivo se acerca más a dos o tres desviaciones estándar.

En estos resultados, se compara la mediana de la cantidad de bytes de imagen (en KB) para cada prueba. Como se esperaba, la carga diferida tiene un efecto positivo muy claro en la reducción de la cantidad de bytes de imagen. Si un usuario real se desplazara por toda la página, todas las imágenes se cargarían de todos modos a medida que ingresaran al viewport, pero estos resultados muestran el rendimiento mejorado de la carga de página inicial.

Para resumir los resultados de la prueba A/B, la técnica de carga diferida que usa WordPress ayuda claramente a reducir los bytes de imagen a costa de un LCP retrasado.

Prueba una corrección

El aspecto más importante de la implementación actual de carga diferida de WordPress para este experimento es que carga de forma diferida las imágenes dentro del viewport (en la mitad superior de la página). La entrada de blog del CMS reconoce que este es un patrón que se debe evitar, pero los datos experimentales de ese momento indicaban que el efecto en el LCP era mínimo y que valía la pena simplificar la implementación en el núcleo de WordPress.

Con estos datos nuevos, se creó una corrección experimental que evita la carga diferida de las imágenes que están en la mitad superior de la página, y se probó la corrección en las mismas condiciones que la primera prueba A/B.

Estos resultados son mucho más prometedores. La carga diferida solo de las imágenes que se encuentran en la mitad inferior de la página genera una reversión completa de la regresión de LCP y, posiblemente, incluso una leve mejora en comparación con la inhabilitación total de la carga diferida. ¿Cómo podría ser más rápido que no usar la carga diferida? Una explicación es que, al no cargar imágenes en la mitad inferior de la página, hay menos contención de red con la imagen del LCP, lo que permite que se cargue más rápido.

En términos de bytes de imagen, la corrección no tiene ningún cambio en comparación con el comportamiento predeterminado. Esto es genial porque era uno de los puntos fuertes del enfoque actual.

Esta corrección tiene algunas advertencias. WordPress determina qué imágenes se deben cargar de forma diferida en el servidor, lo que significa que no sabe nada sobre el tamaño del viewport del usuario ni si las imágenes se cargan inicialmente dentro de él. Por lo tanto, la corrección usa heurística sobre la ubicación relativa de las imágenes en el lenguaje de marcado para adivinar si se carga en el viewport. Específicamente, si la imagen es la primera imagen destacada de la página o la primera imagen del contenido principal, se supone que está en la mitad superior de la página o cerca de ella, y no se cargará de forma diferida.

Las condiciones a nivel de la página, como la cantidad de palabras en el encabezado o la cantidad de texto de párrafo al principio del contenido principal, pueden afectar si la imagen está dentro del viewport. También hay condiciones a nivel del usuario que podrían afectar la precisión de la heurística, en especial el tamaño del viewport y el uso de vínculos de anclaje que cambian la posición de desplazamiento de la página.

Por esos motivos, es importante reconocer que la corrección solo se calibra para proporcionar un buen rendimiento en el caso general, y es posible que se necesite un ajuste para que estos resultados se apliquen a todas las situaciones del mundo real.

Implementación

Ahora que se identificó una mejor manera de realizar la carga diferida de imágenes, con todos los ahorros de imágenes y un rendimiento de LCP más rápido, ¿cómo pueden los sitios comenzar a usarla? El cambio de mayor prioridad es enviar un parche al núcleo de WordPress para implementar la corrección experimental. La guía de la entrada de blog Carga diferida a nivel del navegador para CMS también se actualizará para aclarar los efectos negativos de la carga diferida de contenido que se encuentra en la mitad superior de la página y cómo los CMS pueden usar la heurística para evitarla.

Dado que estas prácticas recomendadas se aplican a todos los desarrolladores web, también puede ser útil marcar los antipatrones de carga diferida en herramientas como Lighthouse. Consulta la solicitud de función en GitHub si te interesa seguir el progreso de esa auditoría. Hasta entonces, una cosa que los desarrolladores podrían hacer para encontrar instancias de elementos de LCP que se cargan de forma diferida es agregar un registro más detallado a sus datos de campo.

new PerformanceObserver((list) => {
  const latestEntry = list.getEntries().at(-1);

  if (latestEntry?.element?.getAttribute('loading') == 'lazy') {
    console.warn('Warning: LCP element was lazy loaded', latestEntry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

El fragmento de JavaScript anterior evaluará el elemento LCP más reciente y registrará una advertencia si se cargó de forma diferida.

Esto también destaca un aspecto negativo de la técnica de carga diferida y el potencial de mejoras de la API a nivel de la plataforma. Por ejemplo, hay un problema abierto en Chromium para experimentar con la carga nativa de las primeras imágenes de forma inmediata, similar a la corrección, a pesar del atributo loading.

Conclusión

Si tu sitio usa la carga diferida de imágenes a nivel del navegador, verifica cómo se implementa y ejecuta pruebas A/B para comprender mejor sus costos de rendimiento. Podría beneficiarse de una carga más rápida de las imágenes en la mitad superior de la página. Si tienes un sitio de WordPress, esperamos que pronto se lance un parche en el núcleo de WordPress. Si usas otro CMS, asegúrate de que conozcan los posibles problemas de rendimiento que se describen aquí.

Probar APIs de plataformas web relativamente nuevas puede conllevar riesgos y recompensas; por algo se llaman funciones de vanguardia. Si bien estamos empezando a comprender la complejidad de la carga diferida de imágenes a nivel del navegador, también vemos las ventajas de usarla para lograr un mejor rendimiento.