Consejos basados en datos para la carga diferida de imágenes, teniendo en cuenta las Métricas web esenciales.
La carga diferida es una técnica para diferir la descarga de un recurso hasta que sea necesario, lo que conserva los datos y reduce la contención de red para los elementos críticos. Se convirtió en un estándar web en 2019 y, hoy, loading="lazy" para imágenes es compatible con la mayoría de los navegadores principales. Suena genial, pero ¿existe demasiada carga diferida?
En esta publicación, se resume cómo analizamos los datos de transparencia web disponibles de forma pública y las pruebas A/B ad hoc para comprender las características de adopción y rendimiento de la carga diferida de imágenes nativas. Descubrimos que la carga diferida puede ser una herramienta increíblemente eficaz para reducir bytes de imagen innecesarios, pero el uso excesivo puede afectar negativamente el rendimiento. Concretamente, nuestro análisis muestra que cargar con más anticipación las imágenes dentro del viewport inicial, a la vez que cargamos de forma diferida el resto, puede brindarnos lo mejor de ambos mundos: menos bytes cargados y mejores Métricas web esenciales.
Adopción
Según los datos más recientes del archivo HTTP, un 17% de los sitios web usan la carga diferida de imágenes nativas y su adopción está creciendo rápidamente. Esta gran presencia en el ecosistema es notable para una API relativamente nueva.
Consultar los datos sin procesar en el proyecto de archivo HTTP 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 nativas utilizan WordPress, el 2% usa otro CMS y el 14% restante no utiliza un CMS conocido. Estos resultados dejan en claro cómo WordPress es el líder en su 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 usaban carga diferida formaban parte del corpus de alrededor de 6 millones de sitios web (el 1% del total). Desde entonces, la adopción de la carga diferida solo en WordPress aumentó a más de 1 millón de sitios web (un 14% del total).
Rendimiento correlacional
Si profundizamos más en el archivo HTTP, podemos comparar el rendimiento de las páginas con y sin carga diferida de imágenes nativas con la métrica Largest Contentful Paint (LCP). Los datos del LCP provienen de experiencias de usuarios reales del Informe sobre la experiencia del usuario en Chrome (CrUX), en lugar de las pruebas sintéticas del lab. En el siguiente gráfico, se usa un diagrama de cuadros 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 casillas representan los percentiles 25 y 75.
La mediana de la página sin carga diferida tiene un percentil 75 de LCP de 2,922 ms, en comparación con los 3,546 ms de la mediana de página con carga diferida. En general, los sitios web que usan la carga diferida suelen tener un rendimiento de LCP peor.
Es importante señalar que estos son resultados correlales y no necesariamente apuntan a la carga diferida como la causa del rendimiento más lento. En términos hipotéticos, si los sitios de WordPress suelen ser un poco más lentos y, dada la medida en que conforman la cohorte de carga diferida, eso podría explicar la diferencia. Intentemos eliminar esa variabilidad con solo mirar los sitios de WordPress.
Lamentablemente, surge el mismo patrón cuando desglosamos las páginas de WordPress: aquellas que usan la carga diferida tienden a tener un rendimiento más lento del LCP. La mediana de la página de WordPress sin carga diferida tiene un percentil 75 de LCP de 3,495 ms, en comparación con los 3,768 ms de la mediana de página con carga diferida.
Esto no demuestra que la carga diferida hace que las páginas se vuelvan más lentas, pero su uso coincide con un rendimiento más lento. Para tratar de responder a la pregunta de causalidad, configuramos una prueba A/B basada en laboratorio.
Rendimiento causal
El objetivo de la prueba A/B era demostrar o refutar la hipótesis de que la carga diferida de imágenes nativas, como se implementó en WordPress Core, generaba un rendimiento de LCP más lento y menos bytes de imágenes. La metodología que utilizamos fue probar un sitio web de demostración de WordPress con el tema twentytwentyone. Probamos los tipos de página única y de archivo, como las páginas principal y de artículo, en computadoras de escritorio y dispositivos móviles emulados con WebPageTest. Probamos cada combinación de páginas con y sin carga diferida habilitada y ejecutamos cada prueba nueve veces para obtener la mediana del valor de LCP y la cantidad de bytes de la imagen.
| Serie | predeterminado | inhabilitado | Diferencia con la configuración predeterminada |
|---|---|---|---|
| twentytwentyone-archive-desktop | 2.029 | 1,759 | −13% |
| twentytwentyone-archive-mobile | 1.657 | 1.403 | 15% menos |
| twentytwentyone-single-desktop | 1.655 | 1.726 | 4% |
| twentytwentyone-solo-dispositivo móvil | 1.352 | 1.384 | 2% |
En los resultados anteriores, se compara la mediana del LCP en milisegundos de las pruebas de archivo y las páginas únicas para computadoras de escritorio y dispositivos móviles. Cuando inhabilitamos la carga diferida en las páginas de archivo, observamos que el LCP mejora en un margen significativo. Sin embargo, en páginas individuales, la diferencia fue más neutral.
Ten en cuenta que el efecto de 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 de computadoras de escritorio y dispositivos móviles, por lo que atribuimos esto a la varianza y consideramos que el cambio es neutral en general. En comparación, la diferencia para las páginas de archivo es más de dos o tres desviaciones estándar.
| Serie | predeterminado | inhabilitado | Diferencia con la configuración predeterminada |
|---|---|---|---|
| twentytwentyone-archive-desktop | 577 | 1173 | Un 103% |
| twentytwentyone-archive-mobile | 172 | 378 | 120% |
| twentytwentyone-single-desktop | 301 | 850 | 183% |
| twentytwentyone-solo-dispositivo móvil | 114 | 378 | 233% |
En los resultados anteriores se compara la mediana de bytes de imagen (en KB) de cada prueba. Como era de esperar, la carga diferida tiene un efecto positivo muy claro en la reducción de la cantidad de bytes de imagen. Si un usuario real desplazara toda la página hacia abajo, todas las imágenes se cargarían de todas formas a medida que cruzan el viewport, pero estos resultados muestran el rendimiento mejorado de la carga inicial de la página.
Para resumir los resultados de la prueba A/B, la técnica de carga diferida que usa WordPress ayuda a reducir de forma muy clara los bytes de la imagen, pero a costa de un LCP retrasado.
Prueba una corrección
Antes de ver cómo se implementó la solución, veamos cómo funciona la carga diferida en WordPress. El aspecto más importante de la implementación actual es que carga de forma diferida las imágenes en la mitad superior de la página (dentro del viewport). En la entrada de blog del CMS, se reconoce que esto es un patrón que se debe evitar, pero los datos experimentales de la época indicaban que el efecto en el LCP era mínimo y valía la pena simplificar la implementación en WordPress Core.
Con estos datos nuevos, creamos una corrección experimental que evita la carga diferida de imágenes que se encuentran en la mitad superior de la página y las probamos en las mismas condiciones que en la primera prueba A/B.
| Serie | predeterminado | inhabilitado | fix | Diferencia con la configuración predeterminada | Diferencia con inhabilitada |
|---|---|---|---|---|---|
| twentytwentyone-archive-desktop | 2.029 | 1,759 | 1.749 | −14% | -1% |
| twentytwentyone-archive-mobile | 1.657 | 1.403 | 1.352 | −18% | −4% |
| twentytwentyone-single-desktop | 1.655 | 1.726 | 1.676 | 1% | −3% |
| twentytwentyone-solo-dispositivo móvil | 1.352 | 1.384 | 1.342 | -1% | −3% |
Estos resultados son mucho más prometedores. La carga diferida de solo las imágenes de la mitad inferior de la página genera una reversión completa de la regresión de LCP y, posiblemente, incluso una leve mejora sobre la inhabilitación por completo del LCP. ¿Cómo puede ser más rápido que no realizar una carga diferida? Una explicación es que, si no se cargan las imágenes de la mitad inferior de la página, hay menos contención de red con la imagen de LCP, lo que permite que se cargue más rápido.
| Serie | predeterminado | inhabilitado | fix | Diferencia con la configuración predeterminada | Diferencia con inhabilitada |
|---|---|---|---|---|---|
| twentytwentyone-archive-desktop | 577 | 1173 | 577 | 0% | −51% |
| twentytwentyone-archive-mobile | 172 | 378 | 172 | 0% | −54% |
| twentytwentyone-single-desktop | 301 | 850 | 301 | 0% | −65% |
| twentytwentyone-solo-dispositivo móvil | 114 | 378 | 114 | 0% | -70% |
En términos de bytes de imagen, la corrección no tiene ningún cambio en comparación con el comportamiento predeterminado. Esto es excelente porque esa fue una de las fortalezas del enfoque actual.
Esta solució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 cargarán inicialmente en él. Por lo tanto, la corrección usa heurísticas sobre la ubicación relativa de las imágenes en el lenguaje de marcado para adivinar si estarán 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 que 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 del 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 pueden afectar la precisión de la heurística, especialmente 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 estos motivos, es importante reconocer que la corrección solo se calibra para proporcionar un buen rendimiento en los casos generales, y es posible que sea necesario realizar ajustes para que estos resultados sean aplicables a todas las situaciones del mundo real.
Lanzando
Ahora que identificamos una mejor manera de hacer una carga diferida de imágenes, todos los ahorros en imágenes y el rendimiento de LCP más rápido, ¿cómo podemos hacer que los sitios comiencen a usar esta tecnología? El cambio de mayor prioridad es enviar un parche al núcleo de WordPress para implementar la corrección experimental. También actualizaremos la guía de la entrada de blog sobre la carga diferida en el nivel del navegador para CMS para aclarar los efectos negativos de la carga diferida en la mitad superior de la página y la forma en que 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 valer la pena marcar los antipatrones de carga diferida en herramientas como Lighthouse. Consulta la solicitud de funciones en GitHub si te interesa seguir el progreso de esa auditoría. Hasta entonces, una cosa que los desarrolladores podían hacer para encontrar instancias de elementos LCP que se cargaban de forma diferida era agregar registros más detallados 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 fue de carga diferida.
Esto también destaca una ventaja nítida 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 con anticipación, de manera similar a la corrección, a pesar del atributo loading.
Finalización
Si tu sitio usa la carga diferida de imágenes nativas, verifica cómo se implementó y ejecuta pruebas A/B para comprender mejor sus costos de rendimiento. Es posible que te convenga cargar las imágenes con más anticipación en la parte superior de la página. Si tienes un sitio de WordPress, con suerte habrá un parche en la página principal de WordPress pronto. Y, si usas otro CMS, asegúrate de que estén al tanto de los posibles problemas de rendimiento que se describen aquí.
Probar APIs de plataformas web relativamente nuevas puede conllevar tanto riesgos como recompensas; estas se denominan funciones de vanguardia por una razón. Si bien estamos comenzando a tener una idea de lo difícil que es la carga diferida de imágenes nativas, también estamos observando las ventajas de cómo usarla para lograr un mejor rendimiento.
Foto de Frankie Lopez en Unsplash