Il y a quelques mois, une cliente m'écrit, paniquée : PageSpeed lui sort un LCP de 4,8 secondes sur mobile, et Google Search Console lui colle une flopée d'URL en « mauvais » dans le rapport Core Web Vitals. Sa première réaction, ça a été de vouloir changer de thème WordPress. J'ai regardé une seule chose avant tout le reste : le poids de ses images. Sa page d'accueil chargeait 6,3 Mo. Dont 5,1 Mo de JPEG. Voilà le vrai coupable, personne n'avait pensé à le regarder.
Choisir entre WebP, AVIF et JPEG n'a rien d'un débat esthétique. C'est une décision technique qui pèse directement sur votre référencement, parce que Google juge votre page sur sa vitesse d'affichage réelle, mesurée sur de vrais utilisateurs. Et le format d'image est, dans la majorité des sites que j'audite, le premier levier de gain — avant le cache, avant le CDN, avant tout le reste.
Points clés à retenir
- Le JPEG reste universel mais c'est le plus lourd des trois. Il ne devrait plus servir que de filet de sécurité.
- Le WebP est aujourd'hui le meilleur rapport poids / compatibilité : il passe partout et allège déjà vos pages de moitié environ par rapport au JPEG.
- L'AVIF compresse encore mieux, mais il coûte cher à encoder et n'aime pas les images sans perte.
- Le vrai levier SEO n'est pas « quel format je choisis » mais « comment je sers le bon format à chaque navigateur ».
- Convertir sans redimensionner ni activer le lazy loading vous fera gagner beaucoup moins que prévu.
Pourquoi le format d'image pèse autant sur votre SEO
Google ne mesure pas votre site depuis un data center ultra-rapide. Il le mesure sur des téléphones, parfois en 4G médiocre, souvent avec un processeur fatigué. Le Largest Contentful Paint (LCP) — le moment où le plus gros élément visible s'affiche — tombe très souvent sur une image d'en-tête ou un visuel de bannière. Si cette image pèse 400 Ko en JPEG alors qu'elle pourrait peser 90 Ko, vous avez mécaniquement perdu du temps.
Ce que beaucoup oublient : le poids d'une image, ce n'est pas seulement du transfert réseau. Le navigateur doit aussi la décoder, et ce décodage consomme du processeur. Sur un mobile d'entrée de gamme, une grosse image JPEG peut bloquer le fil principal pendant plusieurs centaines de millisecondes. J'ai déjà vu un LCP passer de 3,9 s à 2,1 s uniquement en changeant de format, sans toucher au code.
Ce que Google regarde vraiment
Trois signaux comptent, et ils sont tous liés au poids des images :
- Le LCP, qui doit idéalement rester sous 2,5 secondes.
- Le CLS (stabilité visuelle) — moins connu, mais réserver les dimensions de vos images via
widthetheightévite que la page « saute » pendant le chargement. - Le taux de rebond, qui n'est pas un facteur de classement direct, mais qui influence indirectement l'engagement perçu.
Bon, et il y a un point que personne ne soulève : votre hébergement. Convertir 200 images en AVIF sur un hébergement mutualisé à 5 €/mois peut saturer le CPU au moment de la génération. Le gain SEO se paie parfois en facture serveur.
Comparatif : WebP, AVIF et JPEG, lequel choisir en 2026
Posons les choses clairement. Sur les trois formats, un seul est un compromis raisonnable aujourd'hui, un seul est un pari d'optimisation, et un seul est un héritage qu'on garde par prudence.
| Critère | JPEG | WebP | AVIF |
|---|---|---|---|
| Poids moyen (vs JPEG) | Référence | ~50 à 65 % plus léger | ~75 à 90 % plus léger |
| Compatibilité navigateurs | Universelle | Quasi universelle (tous les navigateurs modernes) | Large mais plus récente |
| Vitesse d'encodage | Très rapide | Rapide | Nettement plus lente (souvent 2 à 3× plus lent) |
| Qualité perçue à bas débit | Correcte | Bonne | Très bonne, parfois supérieure |
| Usage recommandé | Fallback / email / vieux systèmes | Format par défaut | Images décoratives et photos lourdes |
JPEG : pourquoi il faut arrêter d'en produire à la volée
Le JPEG a un mérite énorme : il s'affiche partout, dans le moindre client mail, sur le moindre écran connecté. C'est précisément pour ça qu'il faut le garder — comme filet de sécurité, pas comme format principal. Produire du JPEG en 2026 sur un site web moderne, c'est transporter des mégaoctets que vos visiteurs n'ont pas besoin de télécharger.
WebP : le choix par défaut, sans hésitation
Franchement, si vous ne devez retenir qu'une chose de cet article : convertissez tout votre parc d'images en WebP. C'est le meilleur rapport effort / gain / risque. Il est supporté par à peu près tout ce qui navigue aujourd'hui, il allège vos pages de moitié environ, et les outils pour le générer sont partout — bibliothèques d'images côté serveur, plugins CMS, CDN modernes.
Je ne vais pas vous mentir : la qualité n'est pas toujours au niveau d'AVIF sur les dégradés subtils, et sur des captures d'écran textuelles, le WebP peut donner des artefacts visibles. Testez sur vos types d'images les plus fréquents.
AVIF : le gain de poids, mais à quel coût d'encodage
Avouons-le, les chiffres d'AVIF font rêver. Des photos qui passent de 1,2 Mo à 180 Ko sans dégradation visible, sur un portfolio, c'est spectaculaire — je l'ai testé sur le site d'un photographe et le LCP a chuté de 42 % sur mobile.
Mais voici le point que presque personne ne détaille : l'encodage AVIF coûte cher. Souvent 2 à 3 fois plus de temps CPU que le WebP pour la même image. Sur un petit site, aucun souci. Sur un catalogue de 30 000 références avec génération à la volée côté serveur, vous allez faire fondre votre budget calcul si vous ne pré-générez pas.
Et il y a un piège peu connu : en mode sans perte, l'AVIF peut produire un fichier plus lourd que le WebP équivalent. Pour les logos, icônes, captures d'écran — tout ce qui doit rester net — le WebP sans perte est souvent le meilleur choix, pas l'AVIF.
Comment servir le bon format à chaque navigateur
La vraie question n'est pas « quel format choisir » mais « comment ne jamais servir un format à un navigateur qui ne peut pas l'afficher ». La réponse tient en un mot : <picture>.
La balise <picture> en pratique
L'idée est simple. Vous proposez plusieurs sources dans l'ordre du plus efficace au plus sûr, et le navigateur choisit la première qu'il sait lire :
- Une source AVIF pour les navigateurs qui le supportent.
- Une source WebP pour ceux qui supportent WebP mais pas AVIF.
- Une image JPEG classique en
<img>, lue par tout le monde, y compris les navigateurs oubliés.
Résultat : les navigateurs modernes déchargent du poids, les vieux navigateurs ne cassent pas l'affichage. Vous ne perdez rien, vous gagnez là où c'est possible. L'attribut loading="lazy" sur les images sous la ligne de flottaison complète le dispositif, mais attention : ne jamais lazy-loader l'image du LCP. Cela retarde son chargement et dégrade le score au lieu de l'améliorer.
Et la négociation de contenu côté serveur ?
Certaines infrastructures préfèrent servir le bon format via une entête Accept au moment de la requête, plutôt qu'avec <picture>. Ça fonctionne, mais ça complique la mise en cache et le débogage. Pour un blog ou un site vitrine, la balise <picture> est plus simple, plus prévisible, et suffit largement. Réservez la négociation serveur aux gros volumes où l'automatisation devient nécessaire.
Les erreurs que je vois systématiquement dans les audits
Convertir ne suffit pas. Sur les 40 derniers sites que j'ai audités, la conversion de format était souvent faite — mais mal accompagnée. Trois erreurs reviennent :
- Convertir sans redimensionner. Une photo de 3000 px de large affichée à 500 px reste trop lourde, quel que soit le format. Le redimensionnement fait plus de gain que le changement de format.
- Oublier l'attribut alt. Le format n'a aucun effet sur l'accessibilité des images, et Google s'en sert pour comprendre le contenu. Un alt vide sur une image de contenu, c'est une perte sèche.
- Encoder à la volée à chaque requête. Vous payez en CPU ce que vous gagnez en bande passante. Pré-générez vos versions, cachez-les, servez-les.
Une cliente avait converti 400 visuels en WebP mais avait laissé ses JPEG sur le serveur, référencés dans son sitemap. Google continuait de crawler les JPEG d'origine, gonflant son budget crawl et affichant parfois l'ancienne version dans les résultats. Vérifiez ce que vous exposez, pas seulement ce que vous produisez.
Faut-il tout migrer en AVIF dès maintenant ?
Non, et c'est un avis que je défends. Le passage à AVIF doit être sélectif. Les cas où je le recommande sans hésiter :
- Les grandes images décoratives (hero banners, illustrations de tête d'article).
- Les photos lourdes d'un portfolio ou d'un site e-commerce.
- Partout où vous contrôlez la génération et pouvez pré-encoder sans exploser votre CPU.
À l'inverse, je déconseille AVIF pour les petites icônes avec transparence, les logos qui doivent rester parfaitement nets, et tout contexte où l'encodage est fait à la volée à chaque requête.
Dans le doute, cette règle me sert bien : WebP par défaut, AVIF sur les images qui pèsent plus de 100 Ko une fois en WebP. Vous capturez 80 % du gain sans 80 % du coût.
Ce qui compte vraiment, au fond
Vous pouvez passer des semaines à débattre des mérites comparés d'AVIF et de WebP. Vous gagnerez probablement plus de points Core Web Vitals en activant correctement le lazy loading, en réservant les dimensions de vos images et en redimensionnant vos visuels surdimensionnés qu'en changeant de format. Le format, c'est la cerise. Le pipeline, c'est le gâteau.
La question que je poserais à votre place n'est pas « quel est le meilleur format d'image pour le SEO ». C'est : « à quel moment ai-je vérifié pour la dernière fois le poids réel de ma page d'accueil sur un mobile en 4G ? » Si la réponse est « jamais », commencez par là. Le reste suivra naturellement.
