Dans l’ordre de rendement :
1. servir la bonne largeur (jusqu’à −95 %),
2. le bon format (−50 à −65 %),
3. une qualité raisonnable (−20 à −40 %),
4. l’attribut sizes, qu’on oublie et qui
annule le reste, 5. le chargement différé,
6. la priorité sur l’image d’en-tête.
1. La bonne largeur, avant tout le reste
Le poids d’une image varie avec le carré de sa largeur. Diviser la largeur par deux divise le poids par quatre. Aucun autre réglage n’a ce rendement, et c’est pourtant celui qu’on traite en dernier.
La bonne largeur est la place occupée à l’écran, multipliée par la densité de l’écran. Elle n’est donc pas la même d’un visiteur à l’autre, ce qui explique pourquoi elle ne peut pas se décider au moment de l’export. L’outil de redimensionnement donne les valeurs usuelles.
2. Le format
WebP par défaut, AVIF sur les grandes images, JPEG en repli. Le gain est constant et sans effet visible : convertir en WebP divise le poids par deux, l’AVIF par trois.
3. L’attribut sizes, celui qui annule tout le reste
C’est l’erreur la plus fréquente, et la plus coûteuse, parce qu’elle est
silencieuse. Un srcset écrit sans sizes laisse le
navigateur supposer que l’image occupe toute la largeur de la fenêtre. Il
choisit alors la plus grande version disponible, même pour une vignette de
188 pixels.
Mesuré sur notre propre page d’accueil : 1,24 Mo d’images pour une
grille de vignettes, tombés à 402 Ko une fois
l’attribut posé. Le srcset était correct depuis le début ; il ne
servait à rien.
Le problème du sizes est qu’il faut l’écrire à la main, en
décrivant la mise en page en unités CSS, et le corriger chaque fois que la
mise en page change. C’est pour cette raison qu’il est faux presque partout.
4. Le chargement différé, avec une exception
loading="lazy" évite de télécharger ce que le visiteur ne verra
peut-être jamais. À poser sur tout ce qui est sous la ligne de flottaison.
L’exception compte autant que la règle : ne jamais le mettre sur l’image principale de l’en-tête. Elle est presque toujours l’élément qui décide du Largest Contentful Paint, et la différer revient à dégrader volontairement la mesure qu’on cherche à améliorer.
5. La priorité sur l’image d’en-tête
L’inverse du différé : fetchpriority="high" sur la grande image
du haut de page indique au navigateur de la demander avant le reste. Sur une
page dont l’en-tête porte une photographie, c’est le geste le plus rentable
après le choix de la largeur.
6. Ce que Google regarde vraiment
| Mesure | Ce qu’elle décrit | Le levier « image » |
|---|---|---|
| LCP | Quand le plus gros élément visible apparaît | Poids et priorité de l’image d’en-tête |
| CLS | Ce qui saute pendant le chargement | width et height déclarés |
| INP | Le délai de réaction aux clics | Indirect : moins de décodage, moins de blocage |
Le CLS mérite une note : déclarer width et height
sur chaque image ne change rien au poids, mais réserve la place avant
l’arrivée du fichier. Sans ces attributs, le texte saute quand l’image se
charge, et c’est comptabilisé comme un défaut.
Faire tout ça une fois ne suffit pas
Chacun de ces gestes est simple. Le problème est qu’ils doivent être refaits à chaque publication, par chaque personne qui ajoute une image, sur toutes les tailles. Un site optimisé se dégrade en quelques mois, non par négligence, mais parce que la charge repose sur des humains.
Les six gestes, faits automatiquement
DAMDesk sert la bonne largeur à chaque visiteur, négocie le format avec son navigateur, et pose le sizes correct, calculé sur la place réelle de l’image dans la page, par un composant de 2,8 Ko. Sur un fichier de test de 16,3 Mo, la page reçoit 119 Ko.
Questions fréquentes
Quelle est la première chose à faire pour accélérer un site lent ?
Regarder le poids des images, qui représente en général plus de la moitié du poids d’une page. Et dans les images, commencer par les dimensions : c’est là que se trouvent les gains à deux chiffres.
Le lazy loading améliore-t-il le score Core Web Vitals ?
Oui pour les images du bas de page, non pour celle du haut. Différer l’image principale dégrade directement le LCP, qui est la mesure la plus lourde des trois.
Faut-il un CDN d’images ?
Dès que le catalogue dépasse quelques dizaines de visuels et que plusieurs personnes publient, oui : c’est le seul moyen d’obtenir la bonne taille et le bon format sans que quiconque y pense. La vraie question est ce qu’il vous facture : presque tous facturent la bande passante.