Effets sur les performances d'un chargement différé trop important

Conseils basés sur les données pour les images à chargement différé en tenant compte des métriques Core Web Vitals.

Felix Arntz

Rick Viscomi

Le chargement différé est une technique qui consiste à différer le téléchargement d'une ressource jusqu'à ce que cela soit nécessaire. Cela permet de préserver les données et de réduire les conflits sur le réseau pour les éléments critiques. Elle est devenue une norme Web en 2019 et, aujourd'hui, loading="lazy" pour les images est compatible avec la plupart des principaux navigateurs. Ça a l'air génial, mais y a-t-il trop de chargement différé ?

Ce post résume comment nous avons analysé les données de transparence Web accessibles au public et les tests A/B ad hoc pour comprendre les caractéristiques d'adoption et de performances du chargement différé des images natives. Nous avons constaté que le chargement différé était un outil incroyablement efficace pour réduire les octets d'images inutiles, mais qu'une utilisation excessive pouvait avoir un impact négatif sur les performances. Concrètement, notre analyse montre qu'un chargement plus hâtive des images dans la fenêtre d'affichage initiale (alors que le chargement du reste est beaucoup plus long) peut nous offrir le meilleur des deux mondes: moins d'octets chargés et amélioration des Core Web Vitals.

Adoption

Selon les données les plus récentes de l'archive HTTP, 17% des sites Web utilisent le chargement différé des images natives, et son adoption augmente rapidement. Cette implantation dans l'écosystème est remarquable pour une API relativement récente.

L'interrogation des données brutes du projet HTTP Archive nous permet de mieux comprendre quels types de sites Web favorisent l'adoption: 84% des sites qui utilisent le chargement différé des images natives utilisent WordPress, 2% utilisent un autre CMS et les 14% restants n'utilisent pas de CMS connu. Ces résultats montrent clairement à quel point WordPress fait la différence en termes d'adoption.

Le taux d'adoption est également à noter. Il y a un an, en juillet 2020, les sites WordPress utilisant le chargement différé représentaient des dizaines de milliers de sites Web dans notre corpus d'environ six millions de sites (1% du total). Depuis, l'adoption du chargement différé dans WordPress est passée à plus d'un million de sites Web (14% du nombre total).

Performances corrélées

En examinant de plus près les archives HTTP, nous pouvons comparer les performances des pages avec et sans chargement différé d'image natif à l'aide de la métrique Largest Contentful Paint (LCP). Les données LCP proviennent d'expériences utilisateur réelles tirées du rapport d'expérience utilisateur Chrome, et non des tests synthétiques réalisés en atelier. Le graphique ci-dessous utilise un diagramme en forme de boîte à moustaches pour visualiser la distribution du LCP au 75e centile de chaque page : les lignes représentent les 10e et 90e centiles, et les cases représentent les 25e et 75e centiles.

La page médiane sans chargement différé présente un LCP de 75e centile de 2 922 ms, contre 3 546 ms pour la page médiane avec chargement différé. De manière générale, les sites Web qui utilisent le chargement différé ont tendance à enregistrer de moins bonnes performances LCP.

Il est important de souligner que ces résultats sont corrélatifs et qu'ils ne désignent pas nécessairement le chargement différé comme étant la cause de la lenteur des performances. Par exemple, si les sites WordPress ont tendance à être un peu plus lents et compte tenu de leur part dans la cohorte du chargement différé, cela peut expliquer la différence. Essayons donc d'éliminer cette variabilité en ne examinant que les sites WordPress.

Malheureusement, le même schéma apparaît lorsque nous affichons le détail des pages WordPress. Celles qui utilisent le chargement différé ont tendance à avoir des performances LCP plus lentes. La page WordPress médiane sans chargement différé présente un LCP au 75e centile de 3 495 ms, contre 3 768 ms pour la page médiane avec chargement différé.

Cela ne prouve toujours pas que le chargement différé entraîne le ralentissement des pages, mais son utilisation coïncide avec un ralentissement des performances. Pour essayer de répondre à la question de causalité, nous avons mis en place un test A/B basé sur un atelier.

Performance causale

L'objectif du test A/B était de prouver ou de réfuter l'hypothèse selon laquelle le chargement différé des images natives, tel qu'il était implémenté dans WordPress Core, entraînait un ralentissement des performances LCP et une diminution du nombre d'octets d'image. Nous avons utilisé la méthodologie que nous avons utilisée pour tester un site Web de démonstration WordPress utilisant le thème twentytwentyone. Nous avons testé les types de page unique et d'archive (comme les pages d'accueil et les pages d'article) sur les ordinateurs et les appareils mobiles émulés à l'aide de WebPageTest. Nous avons testé chaque combinaison de pages avec et sans le chargement différé activé, et nous avons exécuté chaque test neuf fois pour obtenir la valeur LCP médiane et le nombre d'octets d'image.

Les résultats ci-dessus comparent le LCP médian en millisecondes pour les tests sur les archives et sur les pages individuelles pour ordinateur et mobile. Lorsque nous avons désactivé le chargement différé sur les pages d'archive, nous avons constaté une amélioration significative du LCP. En revanche, sur certaines pages, la différence était plus neutre.

Il convient de noter que la désactivation du chargement différé semble en fait accélérer légèrement les pages individuelles. Cependant, la différence du LCP est inférieure à un écart-type pour les tests sur ordinateur et sur mobile. Nous attribuons donc cela à la variance et nous considérons que le changement est globalement neutre. En revanche, pour les pages d'archives, la différence est plus proche de deux à trois écarts-types.

Les résultats ci-dessus comparent le nombre médian d'octets des images (en Ko) pour chaque test. Comme prévu, le chargement différé a un effet très positif sur la réduction du nombre d'octets de l'image. Si un utilisateur réel devait faire défiler toute la page vers le bas, toutes les images se chargeraient quand même dans la fenêtre d'affichage, mais ces résultats montrent les performances améliorées du chargement initial de la page.

Pour résumer les résultats du test A/B, la technique de chargement différé utilisée par WordPress permet très clairement de réduire le nombre d'octets de l'image, mais au prix d'un LCP retardé.

Tester un correctif

Avant d'expliquer comment le correctif a été implémenté, examinons le fonctionnement du chargement différé dans WordPress aujourd'hui. L'aspect le plus important de l'implémentation actuelle est qu'elle charge les images de manière différée dans la partie au-dessus de la ligne de flottaison (dans la fenêtre d'affichage). L'article de blog du CMS reconnaît ce comportement à éviter, mais les données expérimentales de l'époque indiquaient que l'effet sur le LCP était minimal et mériterait de simplifier l'implémentation dans le noyau WordPress.

Compte tenu de ces nouvelles données, nous avons créé une correction expérimentale qui évite les images au chargement différé dans la partie au-dessus de la ligne de flottaison. Nous l'avons testée dans les mêmes conditions que lors du premier test A/B.

Ces résultats sont bien plus prometteurs. Le chargement différé des images en dessous de la ligne de flottaison entraîne une annulation complète de la régression du LCP, voire une amélioration légère par rapport à la désactivation complète du LCP. Comment peut-il être plus rapide que pas du tout ? Une explication est qu'en ne chargeant pas les images en dessous de la ligne de flottaison, vous réduisez les conflits réseau avec l'image LCP, ce qui lui permet de se charger plus rapidement.

En termes d'octets d'image, la correction ne change absolument pas par rapport au comportement par défaut. C'est génial, car c'est l'un des points forts de l'approche actuelle.

Ce correctif comporte des mises en garde. WordPress détermine les images à charger en différé côté serveur. Cela signifie qu'il ne connaît rien de la taille de la fenêtre d'affichage de l'utilisateur ni si les images y seront initialement chargées. Le correctif utilise donc des méthodes heuristiques de position relative des images dans le balisage pour déterminer si elles se trouveront dans la fenêtre d'affichage. Plus précisément, si l'image est la première image mise en avant sur la page ou la première image du contenu principal, elle est supposée être au-dessus de la ligne de flottaison (ou proche d'elle), et elle ne sera pas chargée. Les conditions au niveau de la page, telles que le nombre de mots dans le titre ou la quantité de texte du paragraphe au début du contenu principal, peuvent avoir une incidence sur la présence de l'image dans la fenêtre d'affichage. Certaines conditions au niveau de l'utilisateur peuvent également avoir une incidence sur la précision des heuristiques, en particulier la taille de la fenêtre d'affichage et l'utilisation de liens d'ancrage qui modifient la position de défilement de la page. Pour ces raisons, il est important de reconnaître que la correction n'est calibrée que pour fournir de bonnes performances de manière générale et que des ajustements peuvent être nécessaires pour que ces résultats soient applicables à tous les scénarios réels.

Déploiement

Maintenant que nous avons identifié un meilleur moyen de charger les images de manière différée, des économies d'images et des performances LCP plus rapides, comment pouvons-nous faire en sorte que les sites commencent à l'utiliser ? Le changement de priorité le plus élevé consiste à envoyer un correctif à WordPress Core pour implémenter le correctif expérimental. Nous mettrons également à jour les conseils de l'article de blog sur le chargement différé au niveau du navigateur pour les CMS afin de clarifier les effets négatifs du chargement différé au-dessus de la ligne de flottaison et de comprendre comment les CMS peuvent utiliser des méthodes heuristiques pour les éviter.

Étant donné que ces bonnes pratiques sont applicables à tous les développeurs Web, il peut également être utile de signaler les antimodèles de chargement différé dans des outils tels que Lighthouse. Reportez-vous à la demande de fonctionnalité sur GitHub si vous souhaitez suivre la progression de cet audit. En attendant, une chose que les développeurs pouvaient faire pour trouver des instances d'éléments LCP chargés en différé consiste à ajouter une journalisation plus détaillée à leurs données de champ.

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});

L'extrait de code JavaScript ci-dessus évalue l'élément LCP le plus récent et consigne un avertissement s'il a été chargé de manière différée.

Cela met également en évidence un aspect de la technique de chargement différé et le potentiel d'amélioration de l'API au niveau de la plate-forme. Par exemple, il existe un problème ouvert dans Chromium qui permet de tester le chargement hâtif des premières images de manière native, comme pour le correctif, malgré l'attribut loading.

Conclusion

Si votre site utilise le chargement différé des images natives, vérifiez son implémentation et effectuez des tests A/B pour mieux comprendre ses coûts de performances. Il peut être judicieux de charger les images plus hâtivement dans la partie au-dessus de la ligne de flottaison. Si vous disposez d'un site WordPress, nous espérons qu'un correctif sera bientôt disponible dans WordPress Core. Si vous utilisez un autre CMS, assurez-vous qu'il est informé des problèmes de performances potentiels décrits ici.

L'essai d'API de plate-forme Web relativement nouvelle peut présenter à la fois des risques et des avantages. On parle de fonctionnalités de pointe pour cette raison. Bien que nous commencions à avoir une idée des difficultés liées au chargement différé des images natives, nous voyons également comment l'utiliser pour améliorer les performances.

Photo par Frankie Lopez, publiée sur Unsplash