Comment optimiser son site web ? Commencez par les images
En 2017, je vous disais que l’optimisation des images était le moyen le plus facile de réduire le temps de chargement de vos pages. C’est toujours vrai. Voici la version mise à jour : ce que Google mesure aujourd’hui, ce que les chiffres disent et ce qu’il faut faire.
Un site lent fait fuir les visiteurs avant même qu’ils aient lu la première ligne.
Et dans la grande majorité des cas, la cause se trouve au même endroit : les images.
La bonne nouvelle, c’est que c’est aussi la partie la plus facile à réparer.
L’écart qui m’a fait écrire cet article
En 2017, j’ai mesuré deux pages avec les mêmes outils. La première pesait 8,8 Mo, faisait 295 requêtes et mettait 26,42 secondes à se charger sur Pingdom. Sur mobile, PageSpeed Insights lui donnait 22 sur 100. La deuxième, une page de mon propre site, pesait 290,9 Ko pour 27 requêtes et se chargeait en 1,31 seconde.
| Mesure (Pingdom, 2017) | Page lente | Page optimisée |
|---|---|---|
| Temps de chargement | 26,42 s | 1,31 s |
| Poids de la page | 8,8 Mo | 290,9 Ko |
| Requêtes | 295 | 27 |
| Note de performance | 87/100 | 95 (A) |
Comparaison indicative : ce sont deux pages différentes, testées de deux endroits différents (Amsterdam, puis Dallas). Le poids passe de 8,8 Mo à 290,9 Ko, soit environ 97 % de moins ; le temps de chargement baisse d’environ 95 %. Source : mes captures Pingdom, août 2017.
Pourquoi la vitesse compte, version 2026
En 2017, on parlait surtout de « temps de chargement ». Aujourd’hui, Google mesure l’expérience avec trois indicateurs, les Core Web Vitals, évalués sur les visites réelles (au 75e centile) :
| Indicateur | Ce qu’il mesure | Seuil « bon » |
|---|---|---|
| LCP (Largest Contentful Paint) | Le temps d’affichage du plus gros élément visible, souvent une image | 2,5 secondes ou moins |
| INP (Interaction to Next Paint) | La réactivité de la page quand on clique ou on touche | 200 millisecondes ou moins |
| CLS (Cumulative Layout Shift) | La stabilité visuelle : est-ce que le contenu saute pendant le chargement | 0,1 ou moins |
Seuils de web.dev. L’INP a remplacé le FID en mars 2024.
Google précise que ses systèmes de classement utilisent les Core Web Vitals, qu’il n’existe pas de « signal unique » et qu’un bon score ne garantit pas d’être en tête : la pertinence du contenu passe d’abord. Une page rapide aide surtout quand plusieurs pages répondent aussi bien à la recherche. C’est donc ni une baguette magique, ni un détail : c’est un avantage réel pour vos visiteurs, et un coup de pouce pour votre référencement.
Les images pèsent-elles encore autant ?
En 2017, j’écrivais qu’une page ne devrait jamais dépasser 1 Mo et que les images en représentaient 40 à 60 %. Les données ont évolué. Selon le Web Almanac 2025 de HTTP Archive, la page d’accueil médiane pèse 2,56 Mo sur mobile et 2,86 Mo sur ordinateur, dont environ 911 Ko et 1,06 Mo d’images. Les images restent le poste le plus lourd, à environ 36 % du poids (mon calcul à partir de ces chiffres).
Un seuil de 1 Mo reste un bon objectif, mais la page typique en est bien loin. Ce n’est pas une raison de s’en contenter : la page à 290,9 Ko de mon exemple montre qu’on peut faire beaucoup mieux, et l’Almanac note que les pages lourdes pénalisent les téléphones d’entrée de gamme et les forfaits de données limités.
Les six conseils de Google pour les images
Le Blog du Modérateur a résumé en mai 2022 une vidéo où Alan Kent, de Google, donne six conseils. Les voici, avec ce qui a changé depuis mon texte de 2017.
Si le navigateur ne connaît pas les dimensions d’une image avant de la charger, il ne laisse pas assez d’espace et le contenu saute quand l’image arrive. Indiquez toujours la largeur et la hauteur de chaque image.
Une image de 2 400 px affichée à 500 px force le téléchargement d’un fichier inutilement gros, surtout sur mobile. Redimensionnez avant d’envoyer l’image, et utilisez des images réactives (l’attribut srcset) pour que le navigateur choisisse la taille adaptée à l’écran. C’est exactement ce que je disais en 2017 : WordPress redimensionne, mais ne compense pas un fichier d’origine trop lourd.
Mon texte de 2017 disait que WebP n’était pris en charge que par Opera et Chrome. C’est terminé : selon Can I use, environ 96 à 97 % des navigateurs en usage lisent le WebP, et environ 94 à 95 % l’AVIF (chiffres de 2026 relayés par des guides). Gardez un JPG en solution de repli avec l’élément <picture> si vous voulez couvrir les vieux appareils.
Règle simple : photo, WebP ou AVIF (JPG en repli) ; logo, capture d’écran ou image avec transparence, PNG, WebP ou SVG ; GIF seulement pour une animation.
| Format | Pour quoi | À savoir |
|---|---|---|
| JPG | Photos | Compression avec perte ; la qualité choisie détermine le poids |
| PNG | Logos, icônes, captures | Sans perte : parfait, mais lourd pour une photo |
| WebP | Photos et images à transparence | Avec ou sans perte ; polyvalent |
| AVIF | Photos, dégradés | Le plus récent des formats courants (2019) ; compression très efficace |
Description des formats : Web Almanac 2025, chapitre Page Weight. Selon le comparatif d’un éditeur d’outils (Zipic), WebP serait 25 à 35 % plus léger qu’un JPG et l’AVIF environ 50 % plus léger ; ces écarts dépendent de l’image et des réglages.
Testez plusieurs niveaux de qualité sur quelques images et comparez avant et après. Google recommande Squoosh pour le faire facilement. En 2017, je conseillais de ne pas dépasser 50 % de perte sur un JPG ; retenez plutôt que le bon niveau se juge à l’œil, image par image.
Un en-tête de cache indique combien de temps le navigateur peut conserver une image. Si vos images changent rarement, une longue durée de cache accélère les visites suivantes. Une extension de cache ou votre hébergeur peut s’en charger.
Google recommande de charger d’abord l’image principale en haut de page, puis les images visibles à l’ouverture, puis celles qui sont plus bas. Deux attributs vous aident : loading="lazy" pour différer les images hors écran, et fetchpriority="high" pour l’image principale. L’image principale ne doit jamais être chargée en différé, sinon vous ralentissez le LCP.
Et si vous êtes sur WordPress ?
WordPress a fait du chemin depuis 2017. Depuis la version 5.5 (2020), il ajoute par défaut loading="lazy" aux images. Depuis la 6.3 (2023), il ajoute aussi automatiquement fetchpriority="high" à l’image qu’il juge être la plus grande de la fenêtre, ce qui améliore le LCP de 5 à 10 % en général selon l’équipe de WordPress. Il évite aussi de différer certaines images du haut de page (travail commencé dans la 5.9).
Cela ne remplace pas la préparation des images : WordPress n’impose pas l’optimisation, et une photo de 3 000 pixels envoyée telle quelle reste lourde. Attention aussi aux thèmes et aux extensions qui remplacent ces réglages : vérifiez qu’aucun ne diffère l’image principale.
Votre plan en 20 minutes
1. Testez votre page d’accueil et une page importante sur PageSpeed Insights, en mode mobile. Notez le LCP, l’INP et le CLS.
2. Repérez les fichiers les plus lourds. La liste des requêtes de Pingdom, triée par taille, les montre tout de suite.
3. Redimensionnez ces images à la taille réellement affichée, convertissez-les en WebP ou en AVIF, puis comparez la qualité dans Squoosh.
4. Remplacez les fichiers, gardez les dimensions dans le code et vérifiez que l’image principale n’est pas en chargement différé.
5. Retestez, puis surveillez le rapport Core Web Vitals de Google Search Console : il reflète les visites réelles sur 28 jours.
Sachez que PageSpeed Insights affiche deux types de données : des mesures de laboratoire, utiles pour déboguer, et des données de visiteurs réels tirées du Chrome User Experience Report. Ce sont les secondes qui reflètent l’expérience véritable, et une page récente ou peu visitée peut ne pas en avoir.
Une image bien préparée,
c’est des secondes gagnées à chaque visite.
Article original (2017)
Blog du Modérateur : Accélérer le chargement des images d’un site, 6 conseils de Google (10 mai 2022)
web.dev : Web Vitals (seuils LCP, INP et CLS)
Google Search Central : Understanding page experience in Google Search results
Google : About PageSpeed Insights
HTTP Archive, Web Almanac 2025 : Page Weight
Can I use : WebP
Can I use : AVIF
Zipic : AVIF vs WebP vs JPEG (comparatif d’un éditeur d’outils)
Make WordPress Core : Lazy-loading images in 5.5
Make WordPress Core : Image performance enhancements in WordPress 6.3
web.dev : Browser-level image lazy loading
