Enseignements à tirer de l'adoption de l'attribut de chargement standardisé
L'objectif de ce post est de convaincre les développeurs et contributeurs de la plate-forme CMS (c'est-à-dire les personnes qui développent les noyaux CMS) que le moment est venu d'implémenter la compatibilité avec la fonctionnalité de chargement différé des images au niveau du navigateur. Je vais également vous donner des recommandations pour assurer une expérience utilisateur de haute qualité et permettre la personnalisation par d'autres développeurs lors de l'implémentation du chargement paresseux. Ces consignes proviennent de notre expérience d'ajout de la prise en charge à WordPress, ainsi que de notre aide à Joomla, Drupal et TYPO3 pour implémenter cette fonctionnalité.
Que vous soyez développeur de plate-forme CMS ou utilisateur de CMS (c'est-à-dire une personne qui crée des sites Web avec un CMS), vous pouvez utiliser cet article pour en savoir plus sur les avantages du chargement paresseux 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 CMS à implémenter le chargement paresseux.
Contexte
Au cours de l'année écoulée, le chargement différé des images et des iFrames à l'aide de l'attribut loading est devenu une partie de la norme HTML WHATWG et a été de plus en plus adopté par divers navigateurs.
Toutefois, ces étapes ne constituent que la base d'un Web plus rapide et plus économe en ressources.
C'est désormais à l'écosystème Web distribué d'utiliser l'attribut loading.
Les systèmes de gestion de contenu alimentent environ 60% des sites Web. Ces plates-formes jouent donc un rôle essentiel dans l'adoption des fonctionnalités modernes des navigateurs 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 leurs approches et les points à retenir pour adopter cette fonctionnalité sur d'autres plates-formes CMS. Le chargement différé des médias est une fonctionnalité clé de performances Web dont les sites doivent bénéficier à grande échelle. C'est pourquoi il est recommandé de l'adopter au niveau du cœur du CMS.
Pourquoi implémenter le chargement différé dès maintenant ?
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 axes d'amélioration potentiels. Toutefois, le consensus général entre les CMS est 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. Une fonctionnalité ne peut être envisagée pour l'adoption dans le cœur de la plate-forme qu'une fois qu'elle a été normalisée.
Prise en charge des navigateurs
La prise en charge de la fonctionnalité par les navigateurs est un problème similaire: la majorité des utilisateurs de CMS devrait pouvoir en profiter. Si la fonctionnalité n'est pas encore compatible avec un pourcentage considérable de navigateurs, elle doit s'assurer qu'elle n'a au moins aucun effet négatif pour ces utilisateurs.
Seuils de distance par rapport à la fenêtre d'affichage
Un problème courant avec les implémentations du chargement paresseux 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 à un stade ultérieur. Contrairement aux solutions JavaScript précédentes, les navigateurs abordent cette approche de manière conservatrice et peuvent en outre affiner leur approche en fonction de données d'expérience utilisateur réelles, ce qui minimise l'impact. Par conséquent, le chargement paresseux au niveau du navigateur devrait pouvoir être adopté en toute sécurité par les plates-formes CMS.
Recommandations concernant l'expérience utilisateur
Exiger des attributs de dimension sur les éléments
Pour éviter les déplacements de mise en page, il est depuis longtemps recommandé que les contenus intégrés tels que les images ou les iFrames incluent 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. Cette recommandation est pertinente, que l'élément soit chargé de manière différée 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 le viewport, le chargement paresseux est légèrement plus applicable.
Les CMS doivent de préférence fournir des attributs de dimension pour toutes les images et les iFrames. Si ce n'est pas possible pour tous ces éléments, nous vous recommandons de ne pas utiliser les images à chargement différé qui ne fournissent pas ces deux attributs.
Éviter le chargement paresseux des éléments au-dessus de la ligne de flottaison
Pour le moment, il est recommandé aux CMS de n'ajouter des attributs loading="lazy" qu'aux images et aux iFrames situées en dessous de la ligne de flottaison, afin d'éviter un retard dans la métrique Largest Contentful Paint, qui peut être important dans certains cas comme nous l'avons découvert en juillet 2021. Toutefois, il faut reconnaître qu'il est complexe d'évaluer la position d'un élément par rapport au viewport avant le processus de rendu. Cela s'applique en particulier si le CMS utilise une approche automatisée pour ajouter des attributs loading, mais même en cas d'intervention manuelle, plusieurs facteurs tels que les différentes tailles et formats d'affichage doivent être pris en compte. Nous vous recommandons toutefois de ne pas utiliser le chargement différé pour les images hero, les autres images ou les iFrames susceptibles d'apparaître au-dessus de la ligne de flottaison.
Éviter un remplacement JavaScript
Bien que JavaScript puisse être utilisé pour fournir un chargement paresseux aux navigateurs qui ne prennent pas (encore) en charge l'attribut loading, ces mécanismes reposent toujours sur la suppression initiale de l'attribut src d'une image ou d'une iframe, ce qui entraîne un retard pour les navigateurs qui prennent en charge l'attribut. De plus, le déploiement d'une telle solution basée sur JavaScript dans les interfaces avant d'un CMS à grande échelle augmente la surface des problèmes potentiels. C'est en partie pour cette raison qu'aucun CMS majeur n'a adopté le chargement paresseux dans son cœur avant la fonctionnalité de navigateur standardisée.
Recommandations techniques
Activer le chargement différé par défaut
La recommandation générale pour les CMS implémentant le chargement différé au niveau du navigateur est de l'activer par défaut. Autrement dit, loading="lazy" doit être ajouté aux images et aux iFrames, de préférence uniquement pour les éléments qui incluent des attributs de dimension.
Si la fonctionnalité est activée par défaut, vous économiserez davantage de ressources réseau que si vous deviez l'activer manuellement, par exemple par 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 pour un CMS en raison de l'absence de prise en charge côté client et de différentes tailles de fenêtre d'affichage, il est recommandé d'utiliser au moins des heuristiques approximatives pour éviter le chargement différé d'éléments tels que les images hero qui apparaîtront probablement au-dessus de la ligne de flottaison.
Autoriser les modifications par élément
Bien que loading="lazy" doive être ajouté aux images et aux iFrames par défaut, il est essentiel de permettre d'omettre l'attribut sur certaines images, par exemple pour optimiser pour le LCP. Si l'audience du CMS est en moyenne considérée comme plus technophile, il peut s'agir d'un contrôle d'interface utilisateur exposé pour chaque image et iframe permettant de désactiver le chargement paresseux 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 une balise ou un contexte HTML entier ou pour un élément HTML spécifique dans le contenu.
Mettre à niveau 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 du backend, en l'enregistrant de manière persistante dans la base de données.
- Ajoutez l'attribut instantanément lorsque vous affichez le contenu de la base de données dans l'interface utilisateur.
Il est recommandé au CMS d'ajouter l'attribut instantanément lors du rendu afin de bénéficier des avantages du chargement paresseux 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 de ressources réseau. De plus, l'ajout de l'attribut à la volée permettra facilement de procéder à des modifications ultérieures, si les fonctionnalités du chargement paresseux au niveau du navigateur sont encore développées.
L'ajout de l'attribut à la volée doit toutefois tenir compte d'un attribut loading potentiellement existant sur un élément et laisser cet attribut prévaloir. De cette manière, le CMS ou une extension pour celui-ci peut également implémenter l'approche basée sur l'éditeur sans créer de conflit avec les attributs en double.
Optimiser les performances côté serveur
Lorsque vous ajoutez l'attribut loading au contenu instantanément à l'aide d'un middleware côté serveur, la vitesse est un facteur à prendre en compte. Selon le CMS, l'attribut peut être ajouté via l'exploration DOM ou des expressions régulières, ces dernières étant recommandées pour les performances.
L'utilisation d'expressions régulières doit être limitée au minimum, par exemple une seule expression régulière qui collecte toutes les balises img et iframe du contenu, y compris leurs attributs, puis ajoute l'attribut loading à chaque chaîne de balise, le cas échéant. WordPress, par exemple, va jusqu'à utiliser une seule expression régulière générale pour effectuer diverses opérations instantanées sur certains éléments, dont l'ajout de loading="lazy" n'est qu'un exemple, à l'aide d'une seule expression régulière pour faciliter plusieurs fonctionnalités. Cette forme d'optimisation est également une autre raison pour laquelle il est recommandé d'adopter le chargement paresseux dans le noyau d'un CMS plutôt qu'une extension. En effet, il permet d'optimiser les performances côté serveur.
Étapes suivantes
Vérifiez si une demande de fonctionnalité existe déjà pour ajouter la fonctionnalité à votre CMS, ou en ouvrez une si ce n'est pas le cas. Utilisez des références à ce post si nécessaire pour étayer votre proposition.
Envoyez-moi un tweet (felixarntz@) pour toute question ou remarque, ou pour faire figurer votre CMS sur cette page si la prise en charge du chargement paresseux au niveau du navigateur a été ajoutée. Si vous rencontrez d'autres difficultés, je serais également ravi d'en savoir plus pour vous aider à trouver une solution.
Si vous êtes développeur de plate-forme CMS, étudiez 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 la forme d'un correctif ou d'une demande de tirage.
Photo d'illustration par Colin Watts sur Unsplash.