Images et vitesse : formats, tailles, lazy loading

Pourquoi les images décident du temps de chargement

Google écrit que les images contribuent souvent le plus au poids total d’une page, ce qui peut rendre les pages lentes et coûteuses à charger. Deux des Core Web Vitals dépendent directement des images. Le Largest Contentful Paint (LCP) mesure le chargement : Google conseille que le plus grand élément apparaisse dans les 2,5 premières secondes après le début du chargement de la page. Sur beaucoup de pages, cet élément est une image, par exemple une grande photo en haut. Le Cumulative Layout Shift (CLS) mesure la stabilité visuelle et devrait rester inférieur à 0,1. Les images qui arrivent sans espace réservé poussent le texte vers le bas et augmentent cette valeur.

Le bon format

• Photos : le JPEG fonctionne partout. Le WebP et l’AVIF sont souvent nettement plus légers à qualité comparable.
• Graphiques aux bords nets ou avec transparence : PNG, ou WebP et AVIF, qui peuvent aussi être transparents.
• Logos et icônes : SVG, car il reste net à toutes les tailles et est en général très léger.
• La recherche Google prend en charge les images dans l’attribut src aux formats BMP, GIF, JPEG, PNG, WebP, SVG et AVIF.

Si tu proposes du WebP ou de l’AVIF, tu peux garder un JPEG de secours dans un élément picture. Le navigateur choisit la première source qu’il comprend.

La bonne taille

Une image de 2 400 pixels de large affichée sur 600 pixels gaspille la plupart de ses octets. Exporte les images à peu près à la largeur où elles sont affichées, et pour les écrans à haute résolution à environ deux fois cette largeur. Compresse-les ensuite. Dans beaucoup de logiciels d’image, un réglage de qualité vers le milieu de l’échelle suffit pour des photos sur le web. Vérifie le résultat en taille réelle avant de remplacer l’original.

srcset et sizes

Un seul fichier ne convient jamais à tous les écrans. Avec srcset, tu proposes plusieurs fichiers de la même image et tu indiques la largeur de chacun. Avec sizes, tu dis au navigateur à quelle largeur l’image sera affichée. Le navigateur choisit alors le plus petit fichier suffisamment net.

<img src="/img/sofa-800.jpg"
     srcset="/img/sofa-400.jpg 400w, /img/sofa-800.jpg 800w, /img/sofa-1600.jpg 1600w"
     sizes="(max-width: 700px) 100vw, 700px"
     width="800" height="533"
     alt="…">

Dans cet exemple, l’image occupe toute la largeur sur les écrans étroits et fait 700 pixels de large sur les écrans plus larges. Google recommande de toujours garder une solution de secours dans l’attribut src. Écris un vrai texte alternatif à la place des trois points.

width et height contre les décalages de mise en page

Sans width et height, le navigateur ne sait pas combien de place une image demande tant que le fichier n’est pas arrivé. Le texte en dessous saute alors vers le bas. Le guide de web.dev sur les décalages de mise en page conseille d’inclure toujours les attributs width et height sur les images et les éléments vidéo, avec la taille en pixels du fichier ou au moins le bon rapport d’aspect. Les navigateurs modernes déduisent de ces valeurs le rapport d’aspect par défaut de l’image et réservent la place. Dans le CSS, width: 100% et height: auto gardent l’image flexible. Si tu ne peux pas définir les attributs, le guide cite la propriété CSS aspect-ratio comme alternative.

Lazy loading

Avec loading="lazy", le navigateur ne charge une image que lorsqu’elle approche de la zone visible. Cela économise des données pour les images plus bas dans la page. Google dit à propos du lazy loading : ne l’ajoute pas à un contenu qui sera probablement visible immédiatement quand un utilisateur ouvre une page. Le lazy loading intégré au navigateur est disponible pour les images et les iframes.

L’image LCP

La plus grande image en haut, souvent une image d’en-tête ou la photo principale du produit, est le fichier le plus important de la page. Le guide de web.dev sur le LCP dit : ne charge jamais ton image LCP en différé. fetchpriority="high" indique au navigateur de la charger tôt. Selon le guide, une priorité élevée sur plus d’une ou deux images n’aide plus. Les images dont une bibliothèque de scripts cache l’adresse dans data-src, ou qui ne sont qu’un arrière-plan CSS, sont trouvées tard par le navigateur. Pour une image d’arrière-plan, le guide cite un préchargement avec link rel="preload" dans le HTML. L’AVIF ou le WebP et un fichier plus petit raccourcissent aussi le temps de chargement.

Pour voir les performances de tes pages, Google renvoie au rapport Core Web Vitals de la Search Console. Pour une seule page, les outils de performance de ton navigateur montrent quel élément est l’élément LCP et quels éléments décalent la mise en page. Mesure avant et après une modification, pour savoir si elle a aidé.

Une courte liste de contrôle

• La plus grande image en haut est-elle chargée normalement, et non en différé ?
• Chaque img a-t-elle width et height, ou l’espace réservé avec aspect-ratio ?
• Chaque fichier a-t-il à peu près la largeur d’affichage, et est-il compressé ?
• Les grandes photos existent-elles en plusieurs largeurs avec srcset et sizes ?
• Reste-t-il des fichiers JPEG ou PNG qui pourraient être en WebP ou AVIF ?

Travailler avec Do4U

La Vérification d'image lit une page et chacune de ses images. Pour chaque fichier, elle indique le format, le poids et les pixels, et depuis le HTML width et height, loading, fetchpriority, srcset et sizes, les sources picture et les images d’arrière-plan dans les attributs style. Do4U devine à partir du HTML l’image LCP probable. Il ne la mesure pas, car le véritable élément LCP est déterminé par le navigateur. Tu obtiens un tableau des images avec les constats, le poids total et un court résumé. Les images insérées par JavaScript et les images d’arrière-plan provenant de fichiers CSS externes ne sont pas incluses. Aucune IA n’est utilisée, et la vérification est gratuite, avec une limite quotidienne.

Do4U trouve des indices, tu vérifies et tu décides. Confirme l’élément LCP avec les outils de performance de ton navigateur avant de modifier la page.