Sur l’un des sites que nous maintenons, l’extension d’optimisation d’images faisait son travail depuis des mois. Elle avait produit plus de 130 000 images au format WebP, deux fois plus légères que les originales. Pourtant, les visiteurs recevaient toujours les fichiers lourds.
Aucune erreur, aucune alerte, aucun ralentissement visible. Le site fonctionnait normalement. Il manquait une seule chose : l’instruction qui dit au serveur d’envoyer le WebP plutôt que l’original. Ce piège peut toucher tout site WordPress qui optimise ses images, et il se repère en une minute.
Générer un WebP ne suffit pas
Une extension d’optimisation comme Imagify fait deux choses distinctes :
- elle recompresse l’image d’origine, qui garde son format (JPEG ou PNG) ;
- elle crée à côté une copie au format WebP, sous le même nom suivi de « .webp ».
Cette copie ne sert à rien tant que personne ne l’envoie. Il existe deux façons de le faire :
- par la page : l’extension modifie le code des pages pour proposer les deux formats, et le navigateur choisit ;
- par le serveur : une règle placée dans le fichier de configuration du serveur (le fichier .htaccess) envoie le WebP à la place de l’original quand le navigateur indique qu’il sait le lire.
La seconde méthode ne touche pas au code des pages. C’est aussi la plus fragile.
Une règle qui tombe sans bruit
Ce fichier est partagé. WordPress le réécrit à chaque enregistrement des permaliens, et plusieurs extensions y ajoutent leurs propres règles : cache, sécurité, images. Quand deux d’entre elles écrivent en même temps, l’une peut écraser l’autre.
Sur ce site, le bloc de règles WebP était coupé au milieu d’une ligne, et les règles de WordPress commençaient juste après. Une écriture simultanée est la cause la plus probable. Le site tournait parfaitement. Seules les images étaient servies dans leur version lourde.
Sur ce seul site, 6,3 Go d’images avaient leur équivalent WebP de 3,1 Go prêt sur le disque. Le travail de compression était fait et payé. Il ne manquait que quelques lignes de configuration.
Le vérifier en une minute
Ouvrez une page de votre site dans Chrome, Firefox ou Edge, puis les outils de développement du navigateur (touche F12) et leur onglet Réseau. Filtrez sur les images et rechargez la page : la colonne Type doit afficher « webp » pour les photos.
Si elle affiche « jpeg » ou « png », la règle ne fonctionne pas. Demandez alors à la personne qui gère votre site de vérifier que les fichiers WebP existent sur le serveur : s’ils sont là, l’extension a fait son travail et c’est la configuration du serveur qu’il faut corriger.
Pourquoi un audit SEO ne verra pas la différence
Une fois la règle rétablie, le fichier d’origine n’a pas changé de taille : c’est le serveur qui choisit quoi envoyer selon ce que le visiteur annonce. Or tous les outils n’annoncent pas la même chose.
| Qui consulte la page | Ce qu’il reçoit |
|---|---|
| Chrome, Firefox, Safari, Edge | WebP |
| Googlebot | WebP |
| PageSpeed Insights, Lighthouse | WebP |
| Screaming Frog et la plupart des crawlers SEO, réglages par défaut | l’image d’origine |
Vos visiteurs et Google profitent donc du gain. Mais un crawler SEO réglé par défaut ressortira exactement la même liste d’images lourdes qu’avant la correction. Si une agence SEO relance son analyse, prévenez-la : sinon, elle conclura que rien n’a bougé.
Trois autres raisons pour lesquelles une image reste lourde
Les tailles oubliées. Imagify ne traite que les tailles d’image déclarées par le thème actuel. Les vignettes créées par un ancien thème restent sur le disque, et parfois dans les pages, sans jamais être compressées. Sur le même site, elles représentaient plus de 70 000 fichiers.
Les dossiers hors médiathèque. Les fichiers envoyés par un formulaire ou par une extension tierce ne sont pas toujours traités, même quand le dossier a été déclaré dans les réglages. Sur le même site, un dossier déclaré depuis longtemps comptait plus de 1 400 fichiers sur 2 268 jamais soumis à l’optimisation.
Le nettoyage de nuit. Imagify repasse chaque nuit sur les fichiers modifiés et peut supprimer des WebP qu’il n’a pas produits lui-même. Un traitement fait à la main peut ainsi paraître réussi le soir et être défait le lendemain matin. Nous l’avons mesuré : douze pages qui pesaient 3,3 Mo le soir en pesaient 6,2 le lendemain matin. Contrôlez toujours le résultat après un cycle complet.
Ce que nous en retenons
Une optimisation se vérifie sur ce que reçoit le visiteur. L’extension affichait des statistiques flatteuses et des milliers d’images « optimisées ». Seule une requête réelle montre ce qui part vraiment.
Ce qui casse sans symptôme doit être surveillé. Une règle de serveur qui disparaît ne déclenche aucune alerte. Il faut aller la vérifier, de temps en temps et après chaque changement d’extension.
Le gain est réel. Les images représentent souvent la plus grosse part du poids d’une page. Diviser leur poids par deux accélère l’affichage sur mobile et améliore la note d’éco-conception, sans toucher au contenu.
Et pour votre site ?
Si vous voulez savoir ce que vos pages envoient réellement, notre audit WordPress mesure le poids et les ressources de chaque page. Notre maintenance suit le site dans la durée. Pour voir comment nous avons allégé notre propre site, lisez comment e-labo.biz est passé en EcoIndex A ou B.