Points à retenir concernant l'adoption de l'attribut de chargement standardisé
Mon objectif dans cet article est de persuader les développeurs et les contributeurs de la plate-forme CMS (c'est-à-dire les personnes qui développent les cœurs de CMS) que le moment est venu d'implémenter la fonctionnalité de chargement différé des images au niveau du navigateur. Je partagerai également des recommandations pour garantir une expérience utilisateur de haute qualité et activer la personnalisation par d'autres développeurs tout en implémentant le chargement différé. Ces consignes sont le fruit de notre expérience en matière de prise en charge de WordPress, et d'aide à Joomla, Drupal et TYPO3 pour implémenter la fonctionnalité.
Que vous soyez développeur de plate-forme CMS ou utilisateur CMS (c'est-à-dire une personne qui crée des sites Web avec un CMS), vous pouvez consulter cet article pour en savoir plus sur les avantages du chargement différé au niveau du navigateur dans votre CMS. Consultez la section Étapes suivantes pour savoir comment encourager votre plate-forme CMS à implémenter le chargement différé.
Contexte
Au cours de l'année écoulée, les images à chargement différé et les iFrames utilisant l'attribut loading ont intégré la norme HTML du WHATWG et ont été de plus en plus adoptés par différents navigateurs.
Cependant, ces étapes clés ne font que jeter les bases d'un Web plus rapide et plus économe en ressources.
L'écosystème Web distribué permet désormais d'utiliser l'attribut loading.
Les systèmes de gestion de contenu occupent environ 60% des sites Web. Ces plates-formes jouent donc un rôle essentiel dans l'adoption des fonctionnalités de navigateur modernes sur le Web. Quelques CMS Open Source populaires, tels que WordPress, Joomla et TYPO3, ont déjà implémenté l'attribut loading sur les images. Examinons leurs approches et les points à retenir pour adopter cette fonctionnalité sur d'autres plates-formes CMS. Le chargement différé est une fonctionnalité clé des performances Web dont les sites devraient bénéficier à grande échelle. C'est pourquoi il est recommandé de l'adopter au niveau de base du CMS.
L'intérêt d'implémenter le chargement différé
Standardisation
L'adoption de fonctionnalités de navigateur non standardisées dans les CMS facilite les tests à grande échelle et peut mettre en évidence des domaines potentiels d'amélioration. Cependant, ils s'accordent généralement sur le fait que, tant qu'une fonctionnalité de navigateur n'est pas standardisée, elle doit de préférence être implémentée sous la forme d'une extension ou d'un plug-in pour la plate-forme concernée. L'adoption d'une fonctionnalité dans le noyau de la plate-forme ne peut être envisagée qu'une seule fois.
Prise en charge des navigateurs
La compatibilité de la fonctionnalité avec les navigateurs est une préoccupation similaire: la majorité des utilisateurs du CMS devraient pouvoir en bénéficier. Si la fonctionnalité n'est pas encore compatible dans un grand nombre de navigateurs, elle doit s'assurer qu'elle n'a au moins aucun effet négatif pour ceux-ci.
Seuils de distance par rapport à la fenêtre d'affichage
L'une des préoccupations courantes des implémentations de chargement différé est qu'elles augmentent en principe la probabilité qu'une image ne soit pas chargée une fois qu'elle est visible dans la fenêtre d'affichage de l'utilisateur, car le cycle de chargement commence à un stade ultérieur. Contrairement aux solutions JavaScript précédentes, les navigateurs abordent cette approche avec prudence et peuvent en outre affiner leur approche en fonction de données d'expérience utilisateur réelles, ce qui en réduit l'impact. Le chargement différé au niveau du navigateur devrait donc pouvoir être adopté sans risque par les plates-formes CMS.
Recommandations concernant l'expérience utilisateur
Exiger des attributs de dimensions pour les éléments
Afin d'éviter les décalages de mise en page, il est recommandé depuis longtemps que le contenu intégré, comme les images ou les iFrames, inclue toujours les attributs de dimension width et height, afin que le navigateur puisse déduire le format de ces éléments avant de les charger réellement. Cette recommandation est pertinente, que l'élément soit à chargement différé ou non. Toutefois, en raison de la probabilité plus élevée de 0,1% qu'une image ne soit pas entièrement chargée une fois dans la fenêtre d'affichage, elle devient légèrement plus applicable avec le chargement différé.
Il est préférable que les CMS fournissent des attributs de dimensions pour toutes les images et tous les iFrames. Si cela n'est pas possible pour tous ces éléments, il est recommandé d'ignorer les images de chargement différé qui ne fournissent pas ces deux attributs.
Éviter le chargement différé des éléments au-dessus de la ligne de flottaison
Pour le moment, il est recommandé aux CMS d'ajouter uniquement des attributs loading="lazy" aux images et aux iFrames placés en dessous de la ligne de flottaison, afin d'éviter tout retard dans la métrique Largest Contentful Paint, qui peut dans certains cas être significative comme découvert en juillet 2021. Cependant, il faut reconnaître qu'il est complexe d'évaluer la position d'un élément par rapport à la fenêtre d'affichage avant le processus de rendu. Cela s'applique en particulier si le CMS utilise une approche automatisée pour ajouter des attributs loading. Toutefois, même en cas d'intervention manuelle, plusieurs facteurs tels que les différentes tailles et formats de la fenêtre d'affichage doivent être pris en compte. Toutefois, nous vous recommandons vivement d'éviter le chargement différé des images héros, ainsi que des autres images ou cadres iFrame susceptibles de s'afficher au-dessus de la ligne de flottaison.
Éviter une création de remplacement JavaScript
Bien que JavaScript puisse être utilisé pour fournir un chargement différé aux navigateurs qui n'acceptent pas (encore) l'attribut loading, ces mécanismes reposent toujours sur la suppression initiale de l'attribut src d'une image ou d'un iFrame, ce qui entraîne un retard pour les navigateurs qui acceptent l'attribut. En outre, le déploiement d'une telle solution basée sur JavaScript dans les interfaces d'un CMS à grande échelle augmente la surface d'exposition aux problèmes potentiels. C'est en partie pour cette raison qu'aucun grand CMS n'avait adopté le chargement différé dans son cœur avant la fonctionnalité de navigateur standardisée.
Recommandations techniques
Activer le chargement différé par défaut
Nous recommandons généralement aux CMS qui implémentent le chargement différé au niveau du navigateur de l'activer par défaut. Par exemple, loading="lazy" doit être ajouté aux images et aux cadres iFrame, de préférence uniquement pour les éléments qui incluent des attributs de dimension.
L'activation de cette fonctionnalité par défaut permet de réaliser des économies plus importantes en termes de ressources réseau que si elle devait être activée manuellement, par exemple pour chaque image.
Dans la mesure du possible, loading="lazy" ne doit être ajouté qu'aux éléments qui apparaissent probablement en dessous de la ligne de flottaison.
Bien que cette exigence puisse être complexe à implémenter dans un CMS en raison d'un manque de prise en compte côté client et de différentes tailles de fenêtre d'affichage, nous vous recommandons au moins d'utiliser des méthodes heuristiques approximatives pour éviter le chargement différé des éléments tels que les images héros susceptibles de se trouver au-dessus de la ligne de flottaison.
Autoriser les modifications par élément
Bien que loading="lazy" doive être ajouté par défaut aux images et aux iFrames, il est essentiel de permettre l'omission de l'attribut sur certaines images, par exemple pour optimiser le LCP. Si l'audience du CMS est en moyenne considérée comme plus technophile, il peut s'agir d'une commande d'interface utilisateur exposée pour chaque image et chaque iFrame, ce qui permet de désactiver le chargement différé pour cet élément.
Une API peut également être présentée aux développeurs tiers afin qu'ils puissent effectuer des modifications similaires dans le code.
WordPress, par exemple, permet d'ignorer l'attribut loading pour l'intégralité d'une balise HTML ou d'un contexte, ou pour un élément HTML spécifique dans le contenu.
Améliorer le contenu existant
De manière générale, il existe deux approches pour ajouter l'attribut loading aux éléments HTML dans un CMS:
- Ajoutez l'attribut depuis l'éditeur de contenu dans le backend, en l'enregistrant de manière persistante dans la base de données.
- Ajoutez l'attribut à la volée lors de l'affichage du contenu de la base de données dans l'interface.
Nous recommandons aux CMS d'ajouter l'attribut à la volée lors de l'affichage, afin de bénéficier des avantages du chargement différé pour tout contenu existant. Si l'attribut ne pouvait être ajouté que via l'éditeur, seuls les contenus nouveaux ou récemment modifiés en bénéficieraient, ce qui réduirait considérablement l'impact du CMS sur l'économie des ressources réseau. De plus, l'ajout de l'attribut à la volée permettra facilement d'effectuer de futures modifications, au cas où les fonctionnalités du chargement différé au niveau du navigateur étaient davantage développées.
L'ajout de l'attribut à la volée devrait cependant répondre à un attribut loading potentiellement existant sur un élément et permettre à un tel attribut de prendre la priorité. De cette façon, le CMS ou son extension peut également implémenter l'approche pilotée par l'éditeur sans générer de conflit avec des attributs en double.
Optimiser les performances côté serveur
Lorsque vous ajoutez l'attribut loading au contenu à la volée à l'aide d'un middleware côté serveur, par exemple, la vitesse est prise en compte. Selon le CMS, l'attribut peut être ajouté via un balayage de DOM ou des expressions régulières. Ce dernier est recommandé pour améliorer les performances.
L'utilisation d'expressions régulières doit être limitée au minimum, par exemple une expression régulière unique qui collecte toutes les balises img et iframe dans le contenu, y compris leurs attributs, puis ajoute l'attribut loading à chaque chaîne de balise, le cas échéant. WordPress, par exemple, va jusqu'à avoir une seule expression régulière générale pour effectuer diverses opérations à la volée sur certains éléments, dont l'ajout de loading="lazy" n'en est qu'un exemple, à l'aide d'une seule expression régulière pour faciliter plusieurs fonctionnalités. En outre, cette forme d'optimisation est une autre raison pour laquelle l'adoption du chargement différé dans le cœur d'un CMS est recommandée plutôt qu'une extension. Elle permet une meilleure optimisation des performances côté serveur.
Étapes suivantes
Vérifiez s'il existe déjà une demande d'ajout de fonctionnalité dans votre CMS ou créez-en une s'il n'y en a pas encore. Utilisez des références à cette publication si nécessaire pour appuyer votre proposition.
Envoyez-moi un tweet (felixarntz@) si vous avez des questions ou des commentaires, ou pour que votre CMS figure sur cette page si le chargement différé au niveau du navigateur est disponible. Si vous rencontrez d'autres défis, je suis également curieux d'en savoir plus à leur sujet pour, espérons-le, trouver une solution.
Si vous êtes un développeur de plate-forme CMS, découvrez comment d'autres CMS ont implémenté le chargement différé:
Vous pouvez utiliser les enseignements tirés de vos recherches et les recommandations techniques de cet article pour commencer à contribuer au code de votre CMS, par exemple sous la forme d'un correctif ou d'une demande d'extraction.
Photo principale prise par Colin Watts sur Unsplash.