Effets des performances d'un chargement différé trop important

Conseils basés sur les données pour le chargement différé des images 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 qu'elle soit nécessaire, afin de préserver les données et de réduire la contention réseau pour les éléments critiques. Il est devenu une norme Web en 2019 et, aujourd'hui, loading="lazy" pour les images est pris en charge par la plupart des principaux navigateurs.

Ce guide résume la façon dont les données de transparence Web accessibles au public et les tests A/B ad hoc ont été analysés pour comprendre les caractéristiques d'adoption et de performances du chargement différé des images au niveau du navigateur. Les résultats ont montré que le chargement différé peut être un outil incroyablement efficace pour réduire les octets d'image inutiles, mais qu'une utilisation excessive peut avoir un impact négatif sur les performances. Concrètement, cette analyse montre que le chargement plus rapide des images dans la fenêtre d'affichage initiale, tout en chargeant le reste de manière différée, peut nous offrir le meilleur des deux mondes : moins d'octets chargés et des Core Web Vitals améliorés.

Adoption

Selon les données les plus récentes de HTTP Archive, le chargement différé des images intégré est utilisé par 29 % des sites Web, et son adoption augmente rapidement.

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 au niveau du navigateur utilisent WordPress, 2 % utilisent un autre CMS et les 14 % restants n'utilisent pas de CMS connu. Ces résultats montrent clairement que WordPress est en tête en termes d'adoption.

Le taux d'adoption est également un facteur important. 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 sur un corpus d'environ 6 millions (1 % du total). Depuis, l'adoption du chargement différé dans WordPress seul a augmenté pour atteindre plus d'un million de sites Web (14 % du total).

Performances corrélatives

En examinant de plus près HTTP Archive, on peut comparer les performances des pages avec et sans chargement différé des images au niveau du navigateur à l'aide de la métrique Largest Contentful Paint (LCP). Les données LCP proviennent d'expériences utilisateur réelles issues du rapport sur l'expérience utilisateur de Chrome, et non de tests synthétiques en laboratoire. Le graphique suivant utilise un diagramme en boîte pour visualiser les distributions du LCP au 75e centile de chaque page : les lignes représentent les 10e et 90e centiles, et les boîtes représentent les 25e et 75e centiles.

La page médiane sans chargement différé présente un LCP au 75e centile de 2 922 millisecondes, contre 3 546 millisecondes pour la page médiane avec chargement différé. En général, les sites Web qui utilisent le chargement différé ont tendance à obtenir de moins bonnes performances LCP.

Il est important de souligner qu'il s'agit de résultats corrélatifs et qu'ils n'indiquent pas nécessairement que le chargement différé est la cause du ralentissement des performances. En théorie, si les sites WordPress ont tendance à être un peu plus lents, et étant donné qu'ils représentent une grande partie de la cohorte de chargement différé, cela pourrait expliquer la différence. Pour éliminer cette variabilité, vous pouvez vous concentrer spécifiquement sur les sites WordPress.

Malheureusement, la même tendance se dégage lorsque l'on examine les 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 millisecondes, contre 3 768 millisecondes pour la page médiane avec chargement différé.

Cela ne prouve toujours pas que le chargement différé entraîne un ralentissement des pages, mais son utilisation coïncide avec des performances plus lentes. Pour tenter de répondre à la question de la causalité, un test A/B en laboratoire a été mis en place.

Performances causales

L'objectif du test A/B était de confirmer ou d'infirmer l'hypothèse selon laquelle le chargement différé des images intégré, tel qu'implémenté dans le cœur de WordPress, entraînait un ralentissement du LCP et une diminution du nombre d'octets d'image. La méthodologie utilisée consistait à tester un site Web WordPress de démonstration avec le thème twentytwentyone. Les types de pages d'archive et de page unique ont été testés, ce qui correspond aux pages d'accueil et d'article, sur ordinateur et sur des appareils mobiles émulés à l'aide de WebPageTest. Chaque combinaison de pages avec et sans chargement différé a été testée, et chaque test a été exécuté neuf fois pour obtenir la valeur LCP médiane et le nombre d'octets d'image.

Ces résultats comparent le LCP médian en millisecondes pour les tests sur les pages d'archive et les pages uniques pour ordinateur et mobile. Lorsque le chargement différé a été désactivé sur les pages d'archive, le LCP s'est considérablement amélioré. En revanche, sur les pages uniques, la différence était moins marquée.

La désactivation du chargement différé semble accélérer légèrement les pages uniques. Toutefois, la différence de LCP est inférieure à un écart-type pour les tests sur ordinateur et sur mobile. Cela peut donc être attribué à la variance, et le changement peut être considéré comme neutre dans l'ensemble. En comparaison, la différence pour les pages d'archive est plus proche de deux à trois écarts types.

Ces résultats comparent le nombre médian d'octets d'image (en Ko) pour chaque test. Comme prévu, le chargement différé a un effet positif très net sur la réduction du nombre d'octets d'image. Si un utilisateur réel faisait défiler toute la page, toutes les images se chargeraient de toute façon lorsqu'elles entreraient dans la fenêtre d'affichage. Toutefois, ces résultats montrent l'amélioration des performances du chargement de page initial.

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 d'image, au détriment d'un LCP retardé.

Tester une correction

L'aspect le plus important de l'implémentation actuelle du chargement différé de WordPress pour ce test est qu'il charge de manière différée les images dans la fenêtre d'affichage (au-dessus de la ligne de flottaison). L'article de blog du CMS reconnaît qu'il s'agit d'un modèle à éviter, mais les données expérimentales de l'époque indiquaient que l'effet sur le LCP était minime et qu'il valait la peine de simplifier l'implémentation dans le noyau WordPress.

À partir de ces nouvelles données, un correctif expérimental a été créé pour éviter le chargement différé des images au-dessus de la ligne de flottaison. Il a été testé dans les mêmes conditions que le premier test A/B.

Ces résultats sont bien plus prometteurs. Le chargement différé des images situées sous la ligne de flottaison entraîne une inversion complète de la régression du LCP, voire une légère amélioration par rapport à la désactivation complète du chargement différé. Comment cela pourrait-il être plus rapide que de ne pas utiliser le chargement différé ? Une explication est qu'en ne chargeant pas les images au-dessous de la ligne de flottaison, il y a moins de contention réseau avec l'image LCP, ce qui lui permet de se charger plus rapidement.

En termes d'octets d'image, le correctif n'apporte absolument aucun changement par rapport au comportement par défaut. C'est une bonne chose, car c'était l'un des points forts de l'approche actuelle.

Ce correctif comporte quelques mises en garde. WordPress détermine les images à charger en différé côté serveur, ce qui signifie qu'il ne sait rien de la taille de la fenêtre d'affichage de l'utilisateur ni si les images s'y chargent initialement. Le correctif utilise donc des heuristiques sur l'emplacement relatif des images dans le balisage pour deviner si elles se chargent 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 considérée comme étant au-dessus de la ligne de flottaison, ou proche de celle-ci, et ne sera pas chargée en différé.

Les conditions au niveau de la page, telles que le nombre de mots dans l'en-tête ou la quantité de texte de paragraphe au début du contenu principal, peuvent déterminer si l'image se trouve dans la fenêtre d'affichage. Il existe également des conditions au niveau de l'utilisateur qui peuvent affecter 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 le correctif n'est calibré que pour fournir de bonnes performances dans le cas général, et qu'un réglage précis peut être nécessaire pour que ces résultats soient applicables à tous les scénarios réels.

Implémentation

Maintenant que nous avons identifié une meilleure façon de charger les images en différé, d'économiser de l'espace et d'accélérer le LCP, comment les sites peuvent-ils commencer à l'utiliser ? La modification la plus prioritaire consiste à envoyer un correctif au noyau WordPress pour implémenter la correction expérimentale. Les conseils de l'article de blog Browser-level lazy-loading for CMSs (Chargement différé au niveau du navigateur pour les CMS) seront également mis à jour pour clarifier les effets négatifs du chargement différé au-dessus de la ligne de flottaison et la manière dont les CMS peuvent utiliser des heuristiques pour l'éviter.

Étant donné que ces bonnes pratiques s'appliquent à tous les développeurs Web, il peut également être utile de signaler les anti-modèles de chargement différé dans des outils tels que Lighthouse. Consultez la demande de fonctionnalité sur GitHub si vous souhaitez suivre l'avancement de cet audit. En attendant, pour trouver les instances d'éléments LCP chargés en différé, les développeurs peuvent 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 précédent é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 inconvénient de la technique de chargement différé et le potentiel d'amélioration des API au niveau de la plate-forme. Par exemple, un problème ouvert dans Chromium consiste à tester le chargement natif des premières images de manière hâtive, comme dans le correctif, malgré l'attribut loading.

Conclusion

Si votre site utilise le chargement différé des images au niveau du navigateur, vérifiez comment il est implémenté et effectuez des tests A/B pour mieux comprendre ses coûts de performances. Il pourrait être utile de charger plus rapidement les images au-dessus de la ligne de flottaison. Si vous avez un site WordPress, un correctif devrait bientôt être intégré au noyau WordPress. Si vous utilisez un autre CMS, assurez-vous qu'il est au courant des problèmes de performances potentiels décrits ici.

Essayer des API de plate-forme Web relativement nouvelles peut comporter des risques et des avantages. Ce n'est pas pour rien qu'on les appelle des fonctionnalités de pointe. Bien que nous commencions à comprendre la complexité du chargement différé des images au niveau du navigateur, nous voyons également les avantages de son utilisation pour améliorer les performances.