Consejos basados en datos para las imágenes de carga diferida que tienen en cuenta las Métricas web esenciales.
La carga diferida es una técnica que aplaza la descarga de un recurso hasta que sea necesario para conservar datos y reducir la contención de red de los recursos críticos. Se convirtió en un estándar web en 2019 y, hoy en día, loading="lazy" para imágenes es compatible con la mayoría de los navegadores principales.
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. Los resultados incluyeron que la carga diferida puede ser una herramienta increíblemente eficaz para reducir los bytes de imagen innecesarios, pero su uso excesivo puede afectar negativamente el rendimiento. En concreto, este análisis muestra que cargar imágenes con mayor urgencia dentro del viewport inicial, mientras se carga de forma diferida el resto, puede proporcionarnos lo mejor de ambos mundos: menos bytes cargados y Métricas web esenciales mejoradas.
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 mejor qué tipos de sitios web están impulsando la adopción: el 84% de los sitios que usan la carga diferida de imágenes a nivel del navegador usan WordPress, el 2% usan otro CMS y el 14% restante no usan un CMS conocido. Estos resultados dejan en claro cómo WordPress es líder en el sector en materia de adopción.
También vale la pena mencionar el porcentaje de adopción. Hace un año, en julio de 2020, los sitios de WordPress que utilizan la carga diferida representaban decenas de miles de sitios web en el corpus de alrededor de 6 millones (el 1% del total). Desde entonces, la adopción de la carga diferida sola 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 del LCP provienen de experiencias del usuario reales del Informe sobre la experiencia del usuario en Chrome (CrUX) y no de las pruebas sintéticas del lab. El siguiente gráfico usa un diagrama de caja y bigote para visualizar las distribuciones de cada página Percentil 75: LCP: Las líneas representan los percentiles 10 y 90, y los cuadros representan los percentiles 25 y 75.
La mediana de página sin carga diferida tiene un LCP del 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 utilizan la carga diferida tienden a tener un peor rendimiento en el LCP.
Es importante señalar que estos son resultados correlales y que no indican necesariamente que la carga diferida sea la causa del rendimiento más lento. De manera hipotética, si los sitios de WordPress tienden a ser un poco más lentos y, en función de cuánto componen la cohorte de carga diferida, esto podría explicar la diferencia. Para eliminar esa variabilidad, el enfoque puede limitarse específicamente a los sitios de WordPress.
Lamentablemente, aparece el mismo patrón cuando se desglosan las páginas de WordPress: aquellos que usan la carga diferida tienden a tener un rendimiento de LCP más lento. La página mediana de WordPress sin carga diferida tiene un LCP del percentil 75 de 3,495 milisegundos, en comparación con los 3,768 milisegundos de la página mediana con carga diferida.
Esto aún 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 intentar responder a la pregunta de causalidad, se configuró una prueba A/B basada en 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, 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 utilizada fue probar un sitio web de demostración de WordPress con el tema twentytwentyone. Se probaron los tipos de archivo y de página única, que son como las páginas principal y de artículo, en computadoras de escritorio y dispositivos móviles emulados con WebPageTest. Se probó cada combinación de páginas con y sin carga diferida habilitada, y cada prueba se ejecutó nueve veces para obtener el valor medio de LCP y la cantidad de bytes de imagen.
| Serie | predeterminado | inhabilitado | Diferencia con respecto a 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-un solo dispositivo móvil | 1.352 | 1.384 | 2% |
Estos resultados comparan la mediana del LCP en milisegundos de las pruebas en páginas de archivo y páginas individuales para computadoras de escritorio y dispositivos móviles. Cuando se inhabilitó la carga diferida en las páginas de archivo, el LCP mejoró con un margen significativo. Sin embargo, en páginas individuales, la diferencia no fue tan importante.
Inhabilitar la carga diferida hace 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 general como neutral. En comparación, la diferencia para las páginas de archivo es de alrededor de dos a tres desviaciones estándar.
| Serie | predeterminado | inhabilitado | Diferencia con respecto a la configuración predeterminada |
|---|---|---|---|
| twentytwentyone-archive-desktop | 577 | 1173 | 103% |
| twentytwentyone-archive-mobile | 172 | 378 | 120% |
| twentytwentyone-single-desktop | 301 | 850 | Un 183% |
| twentytwentyone-un solo dispositivo móvil | 114 | 378 | Un 233% |
Estos resultados comparan la mediana de bytes de imagen (en KB) para cada prueba. Como era de esperar, 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 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 es muy clara para reducir los bytes de imágenes a costa de un LCP retrasado.
Prueba una corrección
El aspecto más importante de WordPress La implementación actual de carga diferida para este experimento es que realiza cargas diferidas de imágenes dentro del viewport (mitad superior de la página). En la entrada de blog del CMS, se reconoce esto como un patrón que se debe evitar, pero los datos experimentales en ese momento indicaron 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 nuevos datos, se creó una corrección experimental que evita la carga diferida de imágenes que se encuentran en la mitad superior de la página, y la corrección se probó en las mismas condiciones que en la primera prueba A/B.
| Serie | predeterminado | inhabilitado | Corregir | Diferencia con respecto a la configuración predeterminada | Diferencia respecto de los inhabilitados |
|---|---|---|---|---|---|
| twentytwentyone-archive-desktop | 2 029 | 1,759 | 1749 | −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-un solo dispositivo móvil | 1.352 | 1.384 | 1.342 | -1% | −3% |
Estos resultados son mucho más prometedores. La carga diferida solo de las imágenes de la mitad inferior de la página da como resultado una reversión completa de la regresión de LCP y tal vez incluso una leve mejora en comparación con inhabilitar la carga diferida por completo. ¿Cómo podría ser más rápido que no la carga diferida en absoluto? Una explicación es que, cuando no se cargan imágenes en 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 | Corregir | Diferencia con respecto a la configuración predeterminada | Diferencia respecto de los inhabilitados |
|---|---|---|---|---|---|
| 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-un solo dispositivo móvil | 114 | 378 | 114 | 0% | -70% |
En términos de bytes de imagen, la corrección no presenta ningún cambio en comparación con el comportamiento predeterminado. Esto es genial, ya que esa era una de las fortalezas del enfoque actual.
Esta solución tiene algunas advertencias. WordPress determina qué imágenes se cargan 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 en él. La solución usa una heurística sobre las imágenes ubicación relativa 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 se encuentra en la mitad superior de la página o cerca de ella, y no se realizará una carga diferida.
Las condiciones a nivel de la página, como la cantidad de palabras en el encabezado o la cantidad de texto de un 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, 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 está calibrada para proporcionar un buen rendimiento en el caso general y que podría ser necesario realizar ajustes para que estos resultados se puedan aplicar en todas las situaciones del mundo real.
Implementación
Ahora que se identificó una mejor manera de realizar cargas diferidas de imágenes, el ahorro de imágenes y el rendimiento de LCP más rápido, ¿cómo pueden los sitios comenzar a usarla? El cambio de mayor prioridad consiste en enviar un parche a WordPress Core para implementar la solución experimental. La guía de la entrada de blog sobre la carga diferida a nivel del navegador para CMS también se actualizará para aclarar los efectos negativos de la carga diferida 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 valer la pena marcar 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 LCP de carga diferida es 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 se trata de una carga diferida.
Esto también destaca una ventaja aguda 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 que se debe experimentar con la carga nativa de las primeras imágenes con anticipación, similar a la solución, a pesar del atributo loading.
Conclusión
Si tu sitio utiliza la carga diferida de imágenes a nivel del navegador, verifica cómo se implementa y ejecuta pruebas A/B para comprender mejor los costos de rendimiento. Para aprovecharlo, carga las imágenes en la mitad superior de la página con más urgencia. Si tienes un sitio de WordPress, con suerte, pronto habrá un parche en WordPress Core. Si usas otro CMS, asegúrate de que esté al tanto de los posibles problemas de rendimiento que se describen aquí.
Probar APIs de plataformas web relativamente nuevas puede conllevar riesgos y recompensas; por una razón, se llaman funciones de vanguardia. Si bien estamos empezando a tener una idea de lo complicado de la carga diferida de imágenes a nivel del navegador, también vemos las ventajas de cómo utilizarla para lograr un mejor rendimiento.
Foto de Frankie Lopez en Unsplash