Apprendre à adopter l'attribut de chargement standardisé
Avec ce post, je souhaite convaincre les développeurs et les contributeurs de plates-formes CMS (c'est-à-dire les développeurs de cœurs de CMS) que le moment est venu de prendre en charge la fonctionnalité de chargement différé des images au niveau du navigateur. Je partagerai également des recommandations sur la façon de garantir des expériences utilisateur de haute qualité et d'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 avec l'ajout de la prise en charge de WordPress, et nous avons aidé Joomla, Drupal et TYPO3 à implémenter cette fonctionnalité.
Que vous soyez un développeur de plate-forme CMS ou utilisateur d'un CMS (c'est-à-dire que vous créez 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 obtenir des suggestions sur la façon d'encourager votre plate-forme de 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 été intégrés à la norme HTML WHATWG et sont de plus en plus adoptés par divers navigateurs.
Cependant, ces jalons ne font que jeter les bases d'un Web plus rapide et plus économe en ressources.
L'attribut loading est désormais disponible dans l'écosystème Web distribué.
Environ 60% des sites Web sont gérés par les systèmes de gestion de contenu. Ces plates-formes jouent donc un rôle essentiel dans l'adoption de fonctionnalités de navigateur modernes sur le Web. Certains CMS Open Source populaires, tels que WordPress, Joomla et TYPO3, ont déjà implémenté la prise en charge de l'attribut loading sur les images. Examinons leur approche et les points à retenir concernant l'adoption de cette fonctionnalité sur d'autres plates-formes CMS. Le chargement différé est une fonctionnalité essentielle pour les performances Web dont les sites devraient bénéficier à grande échelle. C'est pourquoi nous vous recommandons 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 la généralisation des tests et peut révéler des axes d'amélioration potentiels. Toutefois, l'ensemble des CMS s'accordent à dire que, tant qu'une fonctionnalité de navigateur n'est pas standardisée, elle doit de préférence être mise en œuvre sous la forme d'une extension ou d'un plug-in pour la plate-forme concernée. Une fonctionnalité n'est envisagée pour l'adoption dans le noyau de la plate-forme qu'une fois standardisée.
Prise en charge des navigateurs
La compatibilité de la fonctionnalité avec le navigateur est un problème similaire: la majorité des utilisateurs du CMS devraient pouvoir bénéficier de cette fonctionnalité. Si la fonctionnalité n'est pas encore prise en charge dans un grand nombre de navigateurs, celle-ci doit au moins s'assurer qu'elle n'a aucun effet négatif sur ceux-ci.
Seuils de distance par rapport à la fenêtre d'affichage
L'un des problèmes les plus courants avec les 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 devient visible dans la fenêtre d'affichage de l'utilisateur, car le cycle de chargement commence à une étape ultérieure. Contrairement aux solutions précédentes basées sur JavaScript, les navigateurs adoptent une approche prudente et peuvent, en outre, affiner leur approche en fonction de données d'expérience utilisateur réelles, ce qui réduit l'impact. Le chargement différé au niveau du navigateur doit donc pouvoir être adopté par les plates-formes CMS.
Recommandations concernant l'expérience utilisateur
Exiger des attributs de dimension sur les éléments
Pour éviter les changements de mise en page, il est recommandé depuis longtemps d'inclure le contenu intégré tel que les images ou les iFrames avec les attributs de dimension width et height afin que le navigateur puisse déduire le format de ces éléments avant de les charger. Cette recommandation est pertinente, que le chargement d'un élément soit différé ou non. Toutefois, comme il y a 0,1% de probabilité 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é.
De préférence, les CMS doivent fournir des attributs de dimensions sur toutes les images et tous les cadres iFrame. Si cela n'est pas possible pour chacun de ces éléments, nous vous recommandons d'ignorer les images à chargement différé, qui ne fournissent pas ces deux attributs.
Éviter le chargement différé des éléments situés au-dessus de la ligne de flottaison
Pour le moment, il est recommandé aux CMS de n'ajouter que les attributs loading="lazy" aux images et aux iFrames situé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 importante comme indiqué en juillet 2021. Cependant, il est important de reconnaître qu'il est complexe d'évaluer la position d'un élément par rapport à la fenêtre d'affichage avant le processus d'affichage. Cela s'applique en particulier si le CMS utilise une approche automatisée pour ajouter des attributs loading, mais même sur la base d'une intervention manuelle, plusieurs facteurs, tels que les différentes tailles de fenêtre d'affichage et formats, doivent être pris en compte. Toutefois, nous vous recommandons vivement d'éviter le chargement différé des images héros et 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 proposer un chargement différé aux navigateurs qui ne sont pas (encore) compatibles avec 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 retarde les navigateurs compatibles avec cet attribut. De plus, le déploiement d'une telle solution basée sur JavaScript dans l'interface d'un CMS à grande échelle augmente la surface des 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 l'adoption de la fonctionnalité de navigateur standardisée.
Recommandations techniques
Activer le chargement différé par défaut
Il est généralement recommandé 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 par défaut de cette fonctionnalité entraîne des économies de ressources réseau plus importantes 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 à mettre en œuvre pour un CMS en raison du manque de visibilité côté client et des différentes tailles de fenêtre d'affichage, il est recommandé d'utiliser des méthodes heuristiques approximatives pour omettre des éléments tels que les images héros susceptibles d'apparaître au-dessus de la ligne de flottaison pour éviter le chargement différé.
Autoriser les modifications par élément
Bien que l'attribut loading="lazy" doive être ajouté par défaut aux images et aux iFrames, il est essentiel d'autoriser l'omission de cet 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 iFrame permettant de désactiver le chargement différé pour cet élément.
Une API peut également être exposée à des développeurs tiers afin qu'ils puissent effectuer des modifications similaires via 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.
Adapter 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:
- Vous pouvez soit ajouter 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 du rendu du contenu de la base de données dans l'interface.
Nous recommandons au CMS d'ajouter l'attribut à la volée lors du rendu afin de bénéficier également des avantages du chargement différé pour tout le 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éduira considérablement l'impact du CMS sur l'enregistrement des ressources réseau. De plus, l'ajout de l'attribut à la volée permet d'effectuer facilement des modifications si les fonctionnalités de chargement différé au niveau du navigateur sont davantage étendues.
Toutefois, l'ajout de l'attribut à la volée doit prendre en compte un attribut loading potentiellement existant sur un élément et laisser cet attribut être prioritaire. De cette façon, le CMS ou une extension associée peuvent également mettre en œuvre l'approche pilotée par l'éditeur sans créer de conflit avec des attributs en double.
Optimiser les performances côté serveur
Lorsque vous ajoutez l'attribut loading à un 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 DOM ou des expressions régulières. Cette dernière est recommandée pour améliorer les performances.
Vous devez utiliser des expressions régulières au minimum, par exemple une expression régulière unique qui collecte toutes les balises img et iframe du contenu, y compris leurs attributs, puis ajoute l'attribut loading à chaque chaîne de balise si nécessaire. 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 fait qu'une seule, à l'aide d'une seule expression régulière pour faciliter plusieurs fonctionnalités. De plus, 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 de fonctionnalité pour l'ajouter à votre CMS, ou ouvrez une nouvelle demande si vous n'en avez pas. Utilisez les références à cet article si nécessaire pour appuyer votre proposition.
Envoyez-moi un tweet (felixarntz@) pour toute question ou commentaire, ou pour que votre CMS figure sur cette page si la prise en charge du chargement différé au niveau du navigateur a été ajoutée. Si vous rencontrez d'autres défis, je suis également curieux d'en savoir plus à leur sujet afin de trouver une solution.
Si vous êtes développeur de plates-formes CMS, découvrez comment d'autres CMS ont implémenté le chargement différé:
Vous pouvez utiliser les enseignements de vos recherches et les recommandations techniques de cet article pour commencer à contribuer au code de votre CMS, par exemple sous forme de correctif ou de demande d'extraction.
Photo principale par Colin Watts sur Unsplash.