Optimisation des images web : comment réduire le poids en Ko et améliorer le SEO de votre site

Pourquoi les images décident de vos Core Web Vitals

Trois métriques composent les Core Web Vitals, et les images sont impliquées dans les trois. Largest Contentful Paint mesure le temps d’affichage du plus grand élément visible : sur un article, l’image d’en-tête ; sur une fiche produit, la photo principale. Cumulative Layout Shift mesure les mouvements inattendus, et la cause classique est une image sans dimensions déclarées qui pousse le texte vers le bas en arrivant. Interaction to Next Paint mesure la réactivité et, même s’il s’agit surtout d’une affaire de JavaScript, décoder une pile d’images surdimensionnées mobilise exactement le même thread principal.

Ce que Google récompense vraiment

Il faut être précis, car ce terrain attire beaucoup d’exagération. L’expérience de page n’est pas un facteur de classement puissant, et une page rapide ne dépassera pas une page plus pertinente. Ce que fait la vitesse, c’est départager des résultats de pertinence comparable et — bien plus déterminant — décider de la proportion de visiteurs qui restent après avoir cliqué. Trois secondes d’attente avant l’apparition de l’image principale produisent un abandon mesurable, et l’abandon est un signal qui n’a besoin d’aucune subtilité algorithmique pour vous nuire.

Des données de terrain, pas votre portable

Les Core Web Vitals utilisés par la Recherche proviennent du Chrome User Experience Report : des mesures réelles d’utilisateurs réels de Chrome. Lighthouse, exécuté en laboratoire sur votre machine, est un outil de diagnostic, pas la note qui compte. Un site peut obtenir 98 sur Lighthouse et échouer en données de terrain parce que les visiteurs réels utilisent des Android de milieu de gamme sur des réseaux mobiles saturés. Optimisez pour ce visiteur-là et le score de laboratoire suit tout seul.

Les quatre leviers, par ordre de rentabilité

Presque tout le poids des images vient de quatre décisions. Les voici dans l’ordre qui rapporte le plus de kilo-octets par minute d’effort — ce n’est pas l’ordre habituel des guides.

1. Cessez d’envoyer des pixels que personne ne voit

C’est le levier majeur, et il est presque toujours présent. Une photo sortie d’un téléphone fait 4000 × 3000 pixels. Affichée dans une colonne de contenu de 800 pixels de large, même en tenant compte d’un écran retina 2×, elle a besoin de 1600 pixels de large. Les 2400 autres sont téléchargés, décodés puis jetés : environ 84 % des données de pixels gaspillées avant même de parler de compression. Aucun format ni réglage de qualité ne rattrape cela ; le redimensionnement, si, et c’est le changement le plus efficace disponible.

2. Adoptez un format moderne

WebP produit généralement des fichiers 25 à 35 % plus légers qu’un JPEG de qualité visuelle équivalente, et il est pris en charge par tous les navigateurs en usage. AVIF va plus loin — souvent 40 à 50 % de moins que JPEG — avec une prise en charge désormais large mais pas universelle, ce qui en fait une amélioration progressive plutôt qu’un remplacement total. Ni l’un ni l’autre n’oblige à abandonner JPEG : servis via un élément picture, les navigateurs modernes prennent le fichier le plus léger et les anciens se rabattent sur l’autre.

3. Réglez la qualité image par image, pas site par site

Les réglages de qualité ne sont pas linéaires en valeur perçue. Pour la plupart des photos, une qualité JPEG de 75 à 82 ou WebP de 75 à 80 est visuellement indiscernable de l’original à la taille d’affichage normale, tandis que la qualité 95 coûte deux à trois fois plus d’octets pour une différence que personne ne voit. Les exceptions sont les images à grands aplats, bords francs ou texte, qui montrent des artefacts bien plus tôt : captures, logos et schémas exigent une qualité supérieure ou un format sans perte.

4. Chargez-les dans le bon ordre

Les gains restants relèvent de l’ordonnancement, pas du poids. L’image d’en-tête doit être découverte et récupérée immédiatement ; tout ce qui se trouve sous la ligne de flottaison doit attendre. Inverser cela — appliquer le chargement différé à l’image du LCP est une erreur vraiment courante — peut coûter une seconde de LCP sur une page pourtant parfaitement optimisée.

Les formats : la version courte

• AVIF — les fichiers les plus légers pour la photo, excellent à faible débit, plus lent à encoder. À utiliser comme première source d’un élément picture.
• WebP — le choix par défaut raisonnable en 2026. Support universel, nettement plus léger que JPEG, et il gère aussi la transparence et l’animation.
• JPEG — le repli qui fonctionne toujours. Correct pour la photo ; jamais pour des captures, des logos ou quoi que ce soit contenant du texte.
• PNG — sans perte, pour les aplats, les bords francs et la transparence. Correct pour les logos et les captures d’interface, gaspilleur pour la photo.
• SVG — vectoriel, donc indépendant de la résolution et généralement minuscule. La bonne réponse pour les logos, icônes et schémas simples ; supprimez les métadonnées de l’éditeur avant publication, elles doublent souvent le fichier.

Le balisage qui termine le travail

Des fichiers optimisés doivent encore être demandés correctement. Cinq attributs font l’essentiel du travail, et aucun n’exige d’étape de build.

• Renseignez toujours width et height. Le navigateur réserve le bon espace avant l’arrivée de l’image, ce qui supprime le décalage de mise en page. Le CSS aspect-ratio la garde responsive ; les attributs restent obligatoires.
• loading="lazy" sur tout ce qui est sous la ligne de flottaison. Natif, un attribut, aucune bibliothèque. Cela diffère les requêtes d’images que le visiteur n’atteindra peut-être jamais.
• Ne différez jamais l’image du LCP. Donnez-lui plutôt fetchpriority="high" et assurez-vous qu’elle figure dans le HTML initial plutôt qu’injectée par un script.
• Utilisez srcset et sizes pour les images responsives. Un téléphone ne devrait pas télécharger le fichier prévu pour le bureau. Trois ou quatre largeurs couvrent presque toutes les mises en page.
• Rédigez de vrais textes alternatifs. C’est d’abord une exigence d’accessibilité, ensuite un signal SEO : décrivez ce que l’image communique, pas une liste de mots-clés. Les images décoratives prennent un alt vide pour que les lecteurs d’écran les ignorent.

Les noms de fichiers et le contexte comptent aussi

Pour la recherche d’images, le nom du fichier, le texte alternatif, la légende et le paragraphe environnant sont ce qui identifie l’image. « table-chene-140cm.webp » dit quelque chose à un robot ; « IMG_20260714_113255.webp » ne dit rien. Cela ne coûte ni octets ni temps, et c’est la partie du SEO d’images la plus souvent complètement oubliée.

Des budgets à adopter

• Image d’en-tête / LCP : moins de 200 Ko. C’est elle qui décide de votre LCP. Traitez ce chiffre comme une limite stricte.
• Images dans l’article : moins de 100 Ko chacune. À 1200–1600 pixels de large en WebP, c’est largement atteignable pour la plupart des photos.
• Vignettes et avatars : moins de 30 Ko. Si une vignette de 150 pixels pèse 400 Ko, c’est une image pleine taille mise à l’échelle par le navigateur.
• Toutes les images d’une page : moins de 1 Mo au total. Au-delà, les visiteurs mobiles en connexion lente commencent à partir avant que la page soit utilisable.

Mesurer le changement

1. 1 Notez l’état actuel : PageSpeed Insights sur l’URL, en relevant le score de laboratoire et les données de terrain si la page a assez de trafic pour en avoir.
2. 2 Ouvrez les outils de développement, filtrez le panneau Réseau sur les images et triez par taille. Les trois plus gros fichiers constituent votre liste de travail.
3. 3 Corrigez ces trois-là : redimensionnez aux dimensions d’affichage, convertissez en WebP, compressez et vérifiez le rendu à taille réelle.
4. 4 Remesurez en laboratoire immédiatement, puis attendez 28 jours que les données de terrain reflètent le changement : CrUX rapporte une fenêtre glissante de 28 jours, rien ne bouge du jour au lendemain.
5. 5 Ajoutez les budgets ci-dessus à votre check-list de publication, pour que le gain ne se dégrade pas au prochain lot d’images.

Pourquoi un flux de travail dans le navigateur convient bien

L’optimisation d’images est un travail répétitif, par lots, qui n’a pas besoin de serveur : redimensionner et réencoder, c’est exactement ce à quoi servent la Canvas API et les Web Workers. Le faire en local, c’est aucune attente d’envoi sur un dossier de cinquante photos, aucune file d’attente, aucune limite de taille et aucune copie de visuels produits non publiés dans le stockage temporaire d’un tiers. C’est aussi la possibilité d’exécuter tout le processus dans un train sans réseau, ce qui sert plus souvent qu’il n’y paraît.