En l'état actuel, les images sont les plus grands assets du Web en termes de taille de transfert totale et de nombre de requêtes par page. La taille moyenne de transfert de la page Web est d'environ 2 Mo en juin 2022. Les images en représentaient près de la moitié. Il n'est pas exagéré de dire que l'optimisation des demandes d'images peut être la seule optimisation des performances possible.
Par la suite, vous découvrirez comment les images responsives ont évolué pour aider à résoudre les problèmes liés à la diffusion d'une seule image pour toutes les éventualités. Dans cette section, vous découvrirez les principales métriques de performances qui concernent les images et comment les améliorer.
Reporter les requêtes d'images
Bien que vous soyez sur le point d'apprendre plusieurs façons de vous assurer que vos requêtes d'images sont aussi petites et efficaces que possible, les requêtes d'images les plus rapides seront toujours celles qui ne sont jamais effectuées. Pour commencer, je voudrais vous indiquer quel peut être le changement le plus efficace que vous puissiez apporter à la façon dont vous fournissez des composants Image aux utilisateurs: l'attribut loading="lazy".
<img src="image.jpg" loading="lazy" alt="…">
Cet attribut garantit que les requêtes d'images ne sont pas effectuées tant qu'elles ne sont pas à proximité de la fenêtre d'affichage de l'utilisateur, en les différant du chargement initial de la page (la période pendant laquelle le navigateur est le plus chargé) et en supprimant ces requêtes du chemin de rendu critique.
En pratique, l'utilisation de cet attribut peut avoir un impact positif considérable sur les performances: une image qui ne se trouve jamais dans la fenêtre d'affichage de l'utilisateur ne sera jamais demandée, et aucune bande passante ne sera gaspillée sur des images que l'utilisateur ne verra jamais.
Il y a un piège: le report de ces requêtes signifie de ne pas tirer parti des processus hyper-optimisés des navigateurs pour demander des images le plus tôt possible. Si loading="lazy" est utilisé sur les éléments img en haut de la mise en page (et donc plus susceptibles de se trouver dans la fenêtre d'affichage de l'utilisateur lors du premier chargement de la page), ces images peuvent sembler beaucoup plus lentes à l'utilisateur final.
Priorité de récupération
L'attribut loading est un exemple d'une initiative plus large de normes Web visant à donner aux développeurs plus de contrôle sur la façon dont les navigateurs Web hiérarchisent les requêtes.
Vous connaissez probablement les approches de base des navigateurs pour récupérer la priorité. Par exemple, une requête pour un fichier CSS externe dans l'élément <head> d'un document est considérée comme suffisamment essentielle pour bloquer l'affichage, tandis qu'une requête pour un fichier JavaScript externe juste au-dessus de </body> est différée jusqu'à la fin de l'affichage. Si la valeur d'un attribut loading sur un <img> est "différée", la requête d'image associée est différée jusqu'à ce que le navigateur détermine qu'elle sera présentée à un utilisateur. Sinon, cette image aura la même priorité que toute autre image de la page.
L'attribut fetchpriority est destiné à donner aux développeurs un contrôle plus précis sur la priorité des éléments, ce qui vous permet de signaler les ressources comme ayant une priorité "élevée" ou "faible" par rapport aux ressources du même type. Les cas d'utilisation de fetchpriority sont semblables à l'attribut loading, bien qu'ils soient beaucoup plus larges. Par exemple, vous pouvez utiliser fetchpriority="low" sur une image uniquement révélée à la suite d'une interaction de l'utilisateur (que l'image se trouve dans la fenêtre d'affichage de l'utilisateur ou non) afin de donner la priorité aux images visibles ailleurs sur la page, ou fetchpriority="high" pour donner la priorité à une image dont vous savez qu'elle sera immédiatement visible dans la fenêtre d'affichage dès que la page sera affichée.
Notez que fetchpriority diffère de loading dans la mesure où il ne modifie pas fondamentalement le comportement du navigateur. Il n'indique pas au navigateur de charger certains éléments avant d'autres, mais lui fournit un contexte essentiel pour les décisions qu'il prend concernant les demandes d'éléments.
Mesurer l'impact des images
Lors de l'optimisation des composants Image, les performances perçues sont souvent plus importantes et plus difficiles à mesurer que la taille de transfert totale seule.
Les signaux Web fournissent des métriques et des conseils mesurables et exploitables pour améliorer l'expérience utilisateur sur le Web. Ils mettent en évidence des problèmes tels que le temps de réponse lent d'un serveur Web, les problèmes d'affichage et les retards d'interactivité. Les Signaux Web essentiels constituent un sous-ensemble de ces objectifs. Ils sont axés sur l'expérience directe de l'utilisateur sur une page individuelle. Il s'agit d'un ensemble de mesures techniques qui, ensemble, déterminent la vitesse à laquelle l'utilisateur ressent une expérience.
Cumulative Layout Shift
La métrique CLS (Cumulative Layout Shift) mesure la stabilité visuelle. Il s'agit d'une métrique permettant de déterminer dans quelle mesure la mise en page du contenu se décale à mesure que les éléments sont chargés et que la page est affichée. Toute personne qui a passé beaucoup de temps à utiliser le Web a perdu sa place dans une longue série de texte en raison d'une page "saut", car une police Web ou une source d'image retardée s'affiche soudainement, ou un élément interactif a brusquement déplacé un élément interactif de votre pointeur. Un CLS élevé est au mieux une nuisance et, au pire, cause d'erreur de l'utilisateur : un bouton "Annuler" se substituant à un espace précédemment occupé par un bouton "Confirmer" au moment où l'utilisateur clique, par exemple.
Avec des temps de chargement élevés et la quantité d'espace qu'elles peuvent occuper dans une mise en page, il est évident que les images sont une cause fréquente de scores CLS élevés.
Grâce aux modifications relativement récentes apportées aux navigateurs récents, il est plus facile que vous ne le pensez d'éviter des scores CLS élevés en raison des images.
Si vous travaillez sur l'interface depuis quelques années maintenant, vous connaissez bien les attributs width et height sur <img> : avant l'adoption généralisée du CSS, ces attributs étaient le seul moyen de contrôler la taille d'une image.
<img src="image.jpg" height="200" width="400" alt="…">
Ces attributs ne sont plus utilisés, car nous avons décidé de séparer nos préoccupations de style de notre balisage, d'autant que le Responsive Web Design rendait nécessaire la spécification d'un dimensionnement en fonction d'un pourcentage via CSS. Au début du Responsive Web Design, il était courant de supprimer les attributs width et height inutilisés, car les valeurs que nous avions spécifiées dans notre CSS (max-width: 100% et height: auto) les remplaceraient.
<img src="image.jpg" alt="…">
img {
max-width: 100%;
height: auto;
}
Après avoir supprimé les attributs height et width comme dans l'exemple précédent, la seule méthode dont dispose le navigateur pour déterminer la hauteur de l'image consiste à demander la source, à l'analyser et à l'afficher dans son format intrinsèque, en fonction de la largeur de l'espace qu'elle occupe dans la mise en page une fois les feuilles de style appliquées. Une grande partie de ce processus a lieu après l'affichage de la page, la nouvelle hauteur calculée entraînant des décalages de mise en page supplémentaires.
Depuis 2019, le comportement du navigateur a été mis à jour pour gérer les attributs width et height différemment. Plutôt que d'utiliser les valeurs de ces attributs pour déterminer la taille fixe en pixels d'un élément img dans la mise en page, vous pouvez considérer que ces attributs représentent le format de l'image, bien que la syntaxe soit la même. Les navigateurs récents divisent ces valeurs entre elles afin de déterminer le format intrinsèque d'un élément img avant l'affichage de la page, ce qui leur permet de réserver l'espace occupé par l'image pendant le rendu de la mise en page.
En règle générale, vous devez toujours utiliser les attributs height et width sur <img>, avec des valeurs correspondant à la taille intrinsèque de la source de votre image (vous devez donc vous assurer que vous avez spécifié height: auto avec max-width: 100% pour remplacer la hauteur de l'attribut HTML).
<img src="image.jpg" height="200" width="400" alt="…">
img {
max-width: 100%;
height: auto;
}
En utilisant les attributs width et height sur vos éléments <img>, vous éviterez un score CLS élevé dû aux images.
Notez que cette approche n'a aucun inconvénient, car elle repose sur un comportement de navigateur établi de longue date. Tout navigateur compatible avec le code CSS de base fonctionnera comme d'habitude, avec les attributs height et width de votre balisage, remplacés par vos styles.
Bien que les attributs width et height évitent habilement les problèmes CLS en réservant l'espace de mise en page nécessaire pour vos images, présenter aux utilisateurs un espace vide ou un espace réservé de faible qualité en attendant le transfert et l'affichage d'une image n'est pas non plus idéal. Bien qu'il existe des moyens d'atténuer l'impact mesurable et perceptible des images qui se chargent lentement, le seul moyen de présenter plus rapidement une image entièrement affichée à un utilisateur est de réduire la taille de transfert.
Largest Contentful Paint
Le LCP (Largest Contentful Paint) mesure le temps nécessaire pour afficher le plus grand élément "contentful" visible dans la fenêtre d'affichage de l'utilisateur (l'élément de contenu qui occupe la plus grande partie de la page visible). À première vue, cette métrique peut sembler trop spécifique, mais cet élément sert de proxy pratique au point où la majeure partie de la page a été affichée du point de vue de l'utilisateur. Le LCP est une mesure essentielle des performances (perçues).
Des métriques telles que DOMContentLoaded ou l'événement window.onload peuvent être utiles pour déterminer quand techniquement le processus de chargement de la page actuelle est terminé, mais elles ne correspondent pas nécessairement à l'expérience utilisateur sur la page. Un léger retard dans l'affichage d'un élément en dehors de la fenêtre d'affichage de l'utilisateur serait pris en compte dans l'une de ces métriques, mais passerait probablement complètement inaperçue par un utilisateur réel.
Un LCP long signifie que la première impression de l'utilisateur d'une page (le contenu le plus important dans la fenêtre d'affichage actuelle) est que la page est lente ou complète.
La perception qu'a le LCP d'un utilisateur a un impact direct sur son expérience. D'après un test réalisé par Vodafone l'année dernière, une amélioration de 31% du LCP entraînait non seulement une augmentation de 8% des ventes (un résultat fort en soi), mais aussi une amélioration de 15 % du nombre de visiteurs devenus des clients potentiels ("taux de visiteurs/prospects") et de 11% du nombre d'utilisateurs ayant visité leur panier.
Sur plus de 70% des pages Web, l'élément le plus grand de la fenêtre d'affichage initiale implique une image, qu'il s'agisse d'un élément <img> autonome ou d'un élément avec une image de fond. En d'autres termes, 70% des scores LCP des pages sont basés sur les performances des images. Il ne faut pas beaucoup d'imagination pour en comprendre la raison: de grandes images et des logos qui attirent l'attention sont très susceptibles d'être trouvés "au-dessus du pli".
Vous pouvez prendre certaines mesures pour éviter les retards LCP: tout d'abord, ne spécifiez jamais loading="lazy" sur une image au-dessus de la ligne de flottaison. En effet, retarder la requête jusqu'à l'affichage de la page peut avoir un impact négatif important sur votre score LCP.
Deuxièmement, l'utilisation de fetchpriority="high" peut indiquer au navigateur que le transfert de cette image doit être traité de façon prioritaire par rapport aux images situées ailleurs sur la page.
En gardant ces règles à l'esprit, la meilleure chose à faire pour améliorer le score LCP d'une page est de réduire le temps nécessaire au transfert et à l'affichage de ces images. Pour ce faire, vos sources d'images doivent être aussi petites et efficaces que possible (sans sacrifier leur qualité, bien sûr) et vous assurer que les utilisateurs n'obtiennent que les composants Image les plus pertinents pour leur contexte de navigation.
Conclusion
Les composants Image représentent la consommation la plus importante de la bande passante de vos utilisateurs : la bande passante consommée par le transfert de tous les autres éléments nécessaires à l'affichage d'une page. Les images présentent des problèmes importants en termes de performances perçues, à la fois pendant et après l'affichage de la mise en page environnante. En bref, les composants Image endommageront.
Aussi intimidant que cela puisse être, même si "le Web serait mieux avec moins d'images" serait certes vrai en termes de performances uniquement, cela ferait également un grave malveillance aux utilisateurs. Les images jouent un rôle essentiel sur le Web, et vous ne devez pas faire de compromis sur la qualité d'un contenu pertinent seulement pour des raisons de performances.
Dans la suite de ce cours, vous découvrirez les technologies sur lesquelles reposent nos composants Image, ainsi que des techniques permettant d'atténuer leur impact sur les performances, sans compromettre la qualité.