Enseignements pour l'adoption de l'attribut de chargement standardisé
L'objectif de cet article est de convaincre les développeurs et les contributeurs de plates-formes CMS (c'est-à-dire les personnes qui développent les noyaux de CMS) que le moment est venu d'implémenter la prise en charge de la fonctionnalité de chargement différé des images au niveau du navigateur. Je partagerai également des recommandations sur la façon de garantir une expérience 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 issues de notre expérience d'ajout de la compatibilité à WordPress, ainsi que de l'aide que nous avons apportée à Joomla, Drupal et TYPO3 pour implémenter la fonctionnalité.
Que vous soyez un développeur de plate-forme CMS ou un utilisateur de CMS (c'est-à-dire une personne qui crée des sites Web avec un CMS), cet article vous permettra d'en savoir plus sur les avantages du chargement différé au niveau du navigateur dans votre CMS. Consultez la section Étapes suivantes pour découvrir comment encourager votre plate-forme CMS à implémenter le chargement différé.
Arrière-plan
Au cours de l'année écoulée, le chargement différé des images et des iFrames à l'aide de l'attribut loading a été intégré à la norme HTML WHATWG et adopté par de plus en plus de navigateurs.
Toutefois, ces étapes ne font que jeter les bases d'un Web plus rapide et plus économe en ressources.
Il appartient 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 des navigateurs récents sur le Web. Quelques 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 contenus multimédias 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 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 domaines 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 respective. Une fonctionnalité ne peut être envisagée pour une adoption dans le cœur de la plate-forme qu'une fois qu'elle a été standardisée.
Prise en charge des navigateurs
La compatibilité de la fonctionnalité avec les navigateurs est un problème similaire : la majorité des utilisateurs de CMS doivent pouvoir en bénéficier. Si un pourcentage considérable de navigateurs n'est pas encore compatible avec la fonctionnalité, celle-ci doit au moins s'assurer qu'elle n'a pas d'effet négatif sur ces navigateurs.
Seuils de distance par rapport à la fenêtre d'affichage
Une préoccupation courante concernant 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 à un stade ultérieur. Contrairement aux solutions précédentes basées sur JavaScript, les navigateurs abordent ce problème de manière prudente et peuvent en outre affiner leur approche en fonction des données réelles sur l'expérience utilisateur, ce qui minimise l'impact. Le chargement différé au niveau du navigateur devrait donc être adopté en toute sécurité par les plates-formes de 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 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é 0,1 % plus élevée 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é en place.
Les CMS doivent de préférence fournir des attributs de dimension sur toutes les images et les iFrames. Si cela n'est pas possible pour chaque élément, il est recommandé d'ignorer le chargement différé des images qui ne fournissent pas ces deux attributs.
Évitez le chargement différé 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és 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 cela a été 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 d'affichage. 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 de fenêtre d'affichage et les formats doivent être pris en compte. Toutefois, il est fortement recommandé de ne pas charger en différé les images héros et les autres images ou iFrames susceptibles d'apparaître 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 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 entraîne un retard pour les navigateurs qui sont compatibles avec l'attribut. De plus, le déploiement d'une telle solution basée sur JavaScript dans les interfaces d'un CMS à grande échelle augmente la surface des problèmes potentiels. C'est en partie pourquoi aucun CMS majeur 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
La recommandation générale pour les CMS qui implémentent le chargement différé au niveau du navigateur est de l'activer par défaut. En d'autres termes, 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.
L'activation de la fonctionnalité par défaut permet d'économiser davantage 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 susceptibles d'apparaître 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 au moins des heuristiques approximatives pour omettre les éléments tels que les images héros qui apparaîtront probablement au-dessus de la ligne de flottaison du chargement différé.
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 pouvoir omettre 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 iframe permettant de désactiver le chargement différé pour cet élément.
Vous pouvez également exposer une API aux développeurs tiers pour qu'ils puissent apporter des modifications similaires via du code.
Par exemple, WordPress permet d'ignorer l'attribut loading pour une balise HTML ou un contexte entier ou pour un élément HTML spécifique dans le contenu.
Adapter le contenu existant
Globalement, il existe deux approches pour ajouter l'attribut loading aux éléments HTML d'un CMS :
- Ajoutez l'attribut à partir de 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.
Il est recommandé aux CMS d'ajouter l'attribut à la volée lors de l'affichage, afin d'apporter les avantages du chargement différé à 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 d'apporter facilement des modifications ultérieures si les fonctionnalités de chargement différé au niveau du navigateur sont étendues.
L'ajout de l'attribut à la volée doit toutefois tenir compte d'un attribut loading potentiellement existant sur un élément et lui donner la priorité. De cette façon, le CMS ou une extension de celui-ci peut également implémenter l'approche basée sur l'éditeur sans provoquer 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 un facteur à prendre en compte. Selon le CMS, l'attribut peut être ajouté via un parcours DOM ou des expressions régulières, cette dernière méthode étant recommandée pour les performances.
L'utilisation d'expressions régulières doit être réduite 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 à la volée sur certains éléments, dont l'ajout de loading="lazy", en utilisant une seule expression régulière pour faciliter plusieurs fonctionnalités. Cette forme d'optimisation est une autre raison pour laquelle il est recommandé d'adopter le chargement différé dans le cœur d'un CMS plutôt que dans une extension : elle permet une meilleure optimisation des performances côté serveur.
Étapes suivantes
Vérifiez s'il existe une demande de fonctionnalité pour ajouter la prise en charge de la fonctionnalité dans votre CMS, ou ouvrez-en une si ce n'est pas encore 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 tout commentaire, ou pour que votre CMS soit listé 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 problèmes, n'hésitez pas à m'en faire part pour que je puisse vous aider à trouver une solution.
Si vous êtes un développeur de plate-forme CMS, étudiez la façon dont 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 d'extraction.