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 diffère le téléchargement d'une ressource jusqu'à ce que cela soit nécessaire, afin 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.

Ce guide résume comment les données de transparence Web et les tests A/B ad hoc accessibles au public 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 conclusions de cette étude incluent 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 nuire aux performances. Concrètement, cette analyse montre que le chargement plus hâtif des images dans la fenêtre d'affichage initiale (alors que le chargement du reste est généreusement en différé) peut nous offrir le meilleur des deux mondes: moins d'octets chargés et Core Web Vitals amélioré.

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 d'archive HTTP 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 comment WordPress est à l'avant-garde de l'adoption.

Le taux d'adoption est également 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 dans un corpus d'environ 6 millions de sites (soit 1% du total). Depuis, plus d'un million de sites Web ont adopté le chargement différé dans WordPress, soit 14% du total.

Performances corrélées

En explorant plus en détail l'archive HTTP, vous pouvez comparer les performances des pages avec ou sans chargement différé d'image au niveau du navigateur à l'aide de la métrique Largest Contentful Paint (LCP). Les données LCP proviennent des expériences utilisateur réelles issues du rapport d'expérience utilisateur Chrome, et non des tests synthétiques réalisés en laboratoire. Le graphique suivant utilise un diagramme en boîte avec moustaches pour visualiser les distributions du LCP du 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é affiche un LCP du 75e centile de 2 922 millisecondes, contre 3 546 millisecondes pour la page médiane avec chargement différé. Dans l'ensemble, les sites Web qui utilisent le chargement différé ont tendance à enregistrer 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 des performances plus lentes. Hypothétiquement, si les sites WordPress ont tendance à être un peu plus lents et compte tenu de leur part dans 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, le même schéma apparaît lorsque vous affichez le détail des pages WordPress. Celles qui utilisent le chargement différé ont tendance à présenter des performances LCP plus lentes. Le LCP médian de la page WordPress sans chargement différé est de 3 495 millisecondes au 75e centile, 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 un ralentissement des performances. Pour essayer de répondre à la question de causalité, un test A/B basé sur un laboratoire a été mis en place.

Performances causale

L'objectif du test A/B était de prouver ou d'infirmer l'hypothèse selon laquelle le chargement différé des images intégré, tel qu'il est implémenté dans WordPress Core, ralentit les performances LCP et réduit le nombre d'octets d'image. La méthodologie utilisée consistait à tester un site Web WordPress de démonstration utilisant le thème twentytwentyone. Nous avons testé les types "archive" et "page unique", comme les pages d'accueil et d'article, sur des ordinateurs et 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 de l'image.

Ces résultats comparent le LCP médian en millisecondes pour les tests sur des pages uniques et des archives pour les ordinateurs et les mobiles. Lorsque le chargement différé était désactivé sur les pages d'archive, le LCP s'est considérablement amélioré. Sur les pages individuelles, en revanche, il faisait moins de différence.

La désactivation du chargement différé semble accélérer légèrement les pages individuelles. 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 considérer que la variation est globalement neutre. En comparaison, l'écart 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 clair sur la réduction du nombre d'octets de l'image. Si un utilisateur réel faisait défiler la page entière, toutes les images se chargent quand même lorsqu'elles traversent la fenêtre d'affichage. Toutefois, ces résultats montrent l'amélioration des performances de 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 de réduire très clairement les octets de l'image, au prix d'un LCP retardé.

Tester un correctif

L'aspect le plus important de l'implémentation actuelle du chargement différé par WordPress pour ce test est le chargement différé des images dans la fenêtre d'affichage (au-dessus de la ligne de flottaison). L'article de blog sur le CMS admet que ce comportement est à éviter. Toutefois, les données expérimentales indiquaient à l'époque que l'effet sur le LCP était minime et qu'il était important de simplifier l'implémentation dans WordPress Core.

Compte tenu de ces nouvelles données, nous avons créé un correctif expérimental qui évite le chargement différé des images situées au-dessus de la ligne de flottaison. Ce correctif a été testé dans les mêmes conditions que le premier test A/B.

Ces résultats sont beaucoup plus prometteurs. Le chargement différé des images situées en dessous de la ligne de flottaison permet d'annuler complètement la régression du LCP, voire d'apporter une légère amélioration par rapport à la désactivation complète du chargement différé. Comment peut-il être plus rapide que le chargement différé ? L'une des explications est que le fait de ne pas charger d'images en dessous de la ligne de flottaison réduit les conflits réseau avec l'image LCP, ce qui lui permet de se charger plus rapidement.

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

Ce correctif s'accompagne de 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 sont chargées initialement dans celle-ci. Le correctif utilise donc des méthodes heuristiques de l'emplacement relatif des images dans le balisage pour déterminer 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 dans le contenu principal, elle est considérée comme étant au-dessus de la ligne de flottaison ou à proximité, et le chargement différé n'est pas effectué.

Les conditions appliquées au niveau de la page, comme le nombre de mots dans l'en-tête ou la quantité de texte du paragraphe au début du contenu principal, peuvent avoir un impact sur la présence de l'image dans la fenêtre d'affichage. D'autres conditions au niveau de l'utilisateur peuvent affecter la précision de l'heuristique, 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.

C'est pourquoi il est important de reconnaître que la correction n'est calibrée que pour fournir de bonnes performances dans le cas général, et qu'un ajustement peut être nécessaire pour rendre ces résultats applicables à tous les scénarios du monde réel.

Implémentation (:#implementation)

Maintenant qu'un meilleur moyen de charger des images en différé a été identifié, toutes les économies d'images et des performances LCP plus rapides, comment les sites peuvent-ils commencer à l'utiliser ? La modification la plus prioritaire consiste à envoyer un correctif à WordPress Core pour implémenter la correction expérimentale. Les conseils de l'article de blog Chargement différé au niveau du navigateur pour les CMS seront également mis à jour pour clarifier les effets négatifs du chargement différé dans la partie au-dessus de la ligne de flottaison et expliquer comment les CMS peuvent utiliser des méthodes heuristiques pour éviter ce problème.

Étant donné que ces bonnes pratiques s'appliquent à tous les développeurs Web, il peut également être intéressant de signaler les antimodè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, les développeurs pouvaient ajouter une journalisation plus détaillée à leurs données de champ pour détecter les instances d'éléments LCP chargés en différé.

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 JavaScript précédent évaluera l'élément LCP le plus récent et enregistrera un avertissement s'il était chargé de manière différée.

Cela met également en évidence les caractéristiques techniques du chargement différé et la possibilité d'améliorer l'API au niveau de la plate-forme. Par exemple, un problème ouvert dans Chromium permet de tester le chargement hâtif des premières images de manière native, comme pour la correction, malgré l'attribut loading.

Conclusion

Si votre site utilise le chargement différé des images au niveau du navigateur, vérifiez sa mise en œuvre et effectuez des tests A/B afin de mieux comprendre les coûts liés aux performances. Il peut être judicieux de charger plus rapidement les images dans la partie au-dessus de la ligne de flottaison. Si vous avez un site WordPress, nous espérons qu'il y aura bientôt un correctif dans la version principale de WordPress. Si vous utilisez un autre système de gestion de contenu, assurez-vous qu'il est au courant des problèmes de performances potentiels décrits ici.

L'essai d'API de plates-formes Web relativement récentes peut présenter des risques et des avantages. On parle alors de fonctionnalités de pointe. Même si nous commençons à avoir une idée de l'ennui du chargement différé des images au niveau du navigateur, nous voyons également les avantages de son utilisation pour améliorer les performances.

Photo de Frankie Lopez, publiée sur Unsplash