À l'heure actuelle, les images constituent le plus grand atout du Web en termes de taille totale de transfert. et le nombre de requêtes par page. La taille de transfert totale d'une page Web médiane est d'environ 2 Mo en juin 2022. Les images représentent presque la moitié de cette quantité à elle seule. Je n'exagère pas à dire que l'optimisation des demandes d'images est sans doute l'optimisation des performances la plus efficace.
Par la suite, vous découvrirez comment les images responsives ont évolué pour résoudre les problèmes que génère le fait d'essayer de diffuser une seule image pour toutes les situations. Dans cette section, vous découvrirez des métriques de performances clés en lien avec les images et comment les améliorer.
Reporter les demandes d'images
Même si vous allez découvrir plusieurs façons de réduire au maximum la taille de vos requêtes d'images et leur efficacité, la requête d'image la plus rapide
sera toujours celle qui n'est jamais faite. Dès le départ, je voudrais vous parler du changement qui pourrait avoir le plus d'impact sur la façon dont vous
fournissez des composants Image à vos 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 se rapprochent pas de la fenêtre d'affichage de l'utilisateur, ce qui les différencie de la première le chargement d'une page, c'est-à-dire l'heure à laquelle le navigateur est le plus sollicité, et en supprimant ces requêtes du chemin critique du rendu.
Aussi simple soit-il en pratique, l'utilisation de cet attribut peut avoir un impact positif considérable sur les performances: une image qui n'est jamais comprise dans la fenêtre d'affichage de l'utilisateur n'est jamais demandée, et aucune bande passante n'est gaspillée pour des images que l'utilisateur ne verra jamais.
Il existe toutefois un inconvénient: reporter ces requêtes signifie ne pas profiter des avantages des processus hyper optimisés pour demander
le plus tôt possible. Si loading="lazy" est utilisé sur les éléments img dans la partie supérieure de la mise en page, il est donc plus probable
figurer dans la fenêtre d'affichage de l'utilisateur lors du premier chargement de la page. Ces images peuvent sembler beaucoup plus lentes pour l'utilisateur final.
Extraire la priorité
L'attribut loading est un exemple d'initiative visant à améliorer l'application des normes Web, destinée à donner aux développeurs plus de contrôle sur la façon dont les navigateurs Web
prioriser les demandes.
Vous connaissez probablement approches de base pour extraire la priorité:
Par exemple, une demande de fichier CSS externe dans l'élément <head> d'un document est considérée comme suffisamment essentielle pour bloquer l'affichage, alors qu'une demande de
fichier JavaScript externe situé juste au-dessus de </body> sera différé jusqu'à la fin du rendu. Si la valeur d'un attribut loading sur une <img> est "lazy",
la demande 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 le même
par rapport à toute autre image de la page.
L'attribut fetchpriority est destiné à fournir
Les développeurs peuvent contrôler précisément la priorité des éléments, ce qui leur permet de signaler les ressources
avec "high" et "faible" par rapport aux ressources du même type. Les cas d'utilisation de fetchpriority sont similaires à ceux de loading.
, bien que beaucoup plus large. Par exemple, vous pouvez utiliser fetchpriority="low" sur une image qui n'est révélée qu'après une interaction de l'utilisateur.
(qu'elle 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"
donner la priorité à une image qui sera immédiatement visible dans la fenêtre d'affichage dès que la page s'affiche.
Notez que fetchpriority diffère de loading en ce sens qu'il ne modifie pas fondamentalement le comportement du navigateur. Il n'indique pas au navigateur
pour charger certains éléments avant d'autres, ce qui permet de disposer d'un contexte vital pour les décisions qu'il prend en ce qui concerne 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 le transfert total. à sa taille.
Les signaux Web fournissent des métriques concrètes et mesurables, ainsi que des conseils pour améliorer l'expérience utilisateur expérience du Web, soulignant des problèmes tels que comme un temps de réponse lent d'un serveur Web, des problèmes d'affichage et des retards d'interactivité. Les métriques Core Web Vitals sont un sous-ensemble de ces objectifs, sur l'expérience directe de l'utilisateur sur une page individuelle : un ensemble de mesures techniques qui, ensemble, déterminent la vitesse à laquelle une expérience ressente pour un utilisateur.
Cumulative Layout Shift
Le CLS (Cumulative Layout Shift) est une mesure de la stabilité visuelle. Il s'agit d'une métrique qui permet de déterminer la mise en page du contenu d'une page change à mesure que les éléments sont chargés et que la page s'affiche. Toute personne ayant dépensé un montant important Les internautes ont perdu leur place dans une longue série de textes en raison du "saut" d'une page. comme une police Web ou une source d'images retardées ou si un élément interactif s'est brusquement éloigné de votre pointeur. Un CLS élevé est au mieux une nuisance, erreur utilisateur au pire : un "annuler" pour passer à un espace précédemment occupé par un bouton de confirmation bouton de la souris, par exemple.
En raison des temps de chargement élevés et de l'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 êtes familiarisé avec les attributs width et height sur <img>:
Avant l'adoption généralisée du CSS, il s'agissait du 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 afin que nos préoccupations liées aux styles soient séparées de notre balisage, surtout en ce qui concerne les
la conception Web a rendu nécessaire la spécification d'un dimensionnement basé sur un pourcentage via CSS. Aux débuts de la conception
de sites Web réactifs, « supprimer
les attributs width et height non utilisés ; était un conseil courant, comme les valeurs que nous spécifiions dans notre CSS (max-width: 100% et
height: auto, les remplacerait.
<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 dans cette situation est de demander la source, de l'analyser et de l'afficher dans son format intrinsèque, en fonction du
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 que la page a été
affichée, la hauteur nouvellement 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. Au lieu d'utiliser les valeurs
pour déterminer la taille fixe en pixels d'un élément img dans la mise en page, ces attributs peuvent représenter
le format de l'image, bien que la syntaxe soit la même ; Les navigateurs récents vont diviser ces valeurs entre elles afin de
déterminer le img format intrinsèqued'un élément avant le rendu de la page, ce qui lui permet de réserver l'espace que l'image occupera lors du 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 votre source d'image. Ainsi,
à condition d'avoir spécifié height: auto à côté de 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.
Il est important de noter que cette approche n'a aucun inconvénient, car elle s'appuie sur un comportement de navigateur établi de longue date : n'importe quel navigateur
qui prend en charge les CSS de base continuera de fonctionner comme auparavant : les attributs height et width de votre balisage seront remplacés par vos styles.
Les attributs width et height évitent habilement les problèmes de CLS en réservant l'espace de mise en page nécessaire pour vos images.
les utilisateurs avec un écart vide ou un espace réservé de faible qualité alors que
ils attendent qu'une image soit transférée
et s'affichent, ce qui n'est pas idéal non plus. Même s'il existe des choses que vous pouvez faire pour atténuer les effets mesurables et perceptibles
des images dont le chargement est lent, le seul moyen de présenter plus rapidement une image entièrement affichée à l'utilisateur consiste à 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 : qui occupe la plus grande partie de la page visible. À première vue, cela peut sembler une métrique trop spécifique, mais sert de proxy pratique au point où la majeure partie de la page s'est affichée, du point de vue de l'utilisateur. Le LCP est mesure des performances (perçues).
Des métriques comme DOMContentLoaded ou l'événement window.onload peuvent être utiles pour déterminer quand le processus de chargement de la page actuelle
terminés sur le plan technique, mais ils 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 sont pris en compte dans l'une ou l'autre de ces métriques, mais ne sont probablement pas du tout détectées par un utilisateur réel.
Un LCP long signifie que la première impression d'une page par l'utilisateur (le contenu le plus important dans la fenêtre d'affichage actuelle) est que la page est lente.
ou complètement décomposées.
La perception des utilisateurs telle qu'elle est déterminée par le LCP a un impact direct sur l'expérience utilisateur. Une expérience réalisée par Vodafone l'année dernière a constaté qu'une amélioration de 31% du LCP entraînait non seulement une augmentation de 8% des ventes, un excellent résultat en lui-même, mais aussi une augmentation de 15 % du nombre total d'utilisateurs. du nombre de visiteurs qui sont devenus des clients potentiels ("taux de visiteurs à prospects") et de 11% du nombre d'utilisateurs ayant consulté leur panier ("taux de visites du panier").
Sur plus de 70% des pages Web, l'élément le plus grand de l'URL
La fenêtre d'affichage implique une image, soit en tant qu'élément <img> autonome, soit en tant qu'élément avec une image de fond. Autrement dit,
70% des pages Les scores LCP sont basés sur les performances des images. Pas besoin d'imagination pour comprendre pourquoi: grand et accrocheur
les images et les logos se trouvent très probablement dans la partie au-dessus de la ligne de flottaison.
Vous pouvez prendre quelques mesures pour éviter les retards LCP: tout d'abord, ne spécifiez jamais loading="lazy" dans la "partie au-dessus de la ligne de flottaison". d'image,
car retarder la requête jusqu'à l'affichage de la page aura probablement un impact négatif massif sur votre score LCP.
Deuxièmement, l'utilisation de fetchpriority="high" peut indiquer au navigateur que le transfert de cette image doit être prioritaire par rapport aux images ailleurs sur la page.
En gardant bien à l'esprit ces règles, la meilleure chose à faire pour améliorer le score LCP d'une page est de réduire le temps passé nécessaires pour transférer et afficher ces images. Pour ce faire, vos sources d'images doivent être aussi petites et efficaces possible (sans compromettre leur qualité, bien sûr) et de s'assurer que les utilisateurs ne reçoivent que les composants Image les plus efficaces. sensible à leur contexte de navigation.
Conclusion
Les composants Image constituent le plus important bande passante : la bande passante est supprimée du transfert de tous les autres éléments nécessaires. pour afficher une page. Les images engendrent des problèmes importants en termes de performances perçues, à la fois pendant et après la page environnante s'affiche. En bref, les composants Image dommagent.
Cela peut être intimidant, alors que "le Web serait préférable avec moins d'images". serait certainement vrai en termes de performances seules, cela ferait également un énorme désservice à ses utilisateurs. Les images sont vitales sur le Web, et vous ne devez pas faire de compromis sur la qualité du contenu pertinent pour l'amélioration des 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 sur les performances, sans faire de compromis sur la qualité.