Passer les images en WebP (et AVIF quand la chaîne le sait) est l'un des gains les plus honnêtes sur le LCP (le temps d'affichage du contenu principal) d'un WordPress. Encore faut-il un seul pipeline : l'hébergeur, un plugin tenu, ou un build. Empiler « WebP converter » + « Imagify » + « CDN rewrite » crée des doubles, des 404, des CLS. Cet article dit comment je le pose, ce que je refuse, et le lien avec l'allègement et les Core Web Vitals de page produit.
🖼️ Ce que WebP / AVIF changent
WebP est largement supporté, souvent 25 à 40 % plus léger qu'un JPEG soigné. AVIF encore plus, un peu plus coûteux à encoder, support très bon désormais. Le visiteur gagne. Le LCP de hero aussi, si on ne sert pas un 4000 px.
Le format ne remplace pas le redimensionnement. Un AVIF 5000 px reste un crime. Règles d'upload + tailles WordPress.
⚠️ Trois plugins = 404 et CLS
L'un réécrit les URLs, l'autre laisse le `.jpg`, le troisième sert une balise `<picture>` mal fermée. Le CLS saute. On n'en garde qu'un, on désinstalle pour de vrai.
Les originaux : on peut les garder (légal, recadrage) hors du chemin critique. On ne les sert pas au front.
- Un générateur
- Balise `<picture>` ou négociation de format côté serveur
- Pas de 4000 px en hero
- Mesure LCP avant / après
🛒 Pages produits
La galerie qui précharge huit WebP en pleine taille tue le LCP autant qu'en JPEG. Une image prioritaire, les autres en lazy loading. Voir l'article sur les Core Web Vitals des pages produits.
PrestaShop a le même sujet. WordPress n'est pas unique.
🗂️ Les images déjà en ligne
Activer un outil ne convertit que les prochains envois. Les milliers d'images déjà dans la médiathèque restent en JPEG tant qu'on ne lance pas une conversion en lot.
Je la lance hors des heures de vente, par paquets, avec une sauvegarde des fichiers avant. Sur un petit hébergement, convertir tout d'un coup peut saturer le serveur et ralentir le site pendant des heures.
✅ Vérification
L'accueil, une page intérieure et une page produit. Poids, LCP, visuel sans trou. Si un PNG logo devient flou, on l'exclut (SVG souvent mieux).
WebP / AVIF : hygiène, pas un badge. Un pipeline. C'est tout.
✅ Liste de contrôle avant la conversion
Avant de toucher aux images, j'écris quel outil les convertit, où sont stockées les copies et qui les sert. La mesure qui compte : le poids des pages principales sur mobile et le rendu des images dans les navigateurs anciens.
Sauvegarde du dossier d'images, mesure du poids des pages avant. Puis la conversion. Puis 24 à 72 h de regard sur le poids et l'affichage. Sans cette mesure, on a converti des fichiers, pas prouvé que le site va plus vite.
- Poids des pages principales relevé avant la conversion
- Copie de test avant de convertir les images
- Un changement à la fois, documenté
- Contrôle visuel sur Safari et un ancien Android, puis suivi de l'espace disque
📌 Ce que je refuse sur ce sujet
Je refuse d'empiler une extension de compression, une extension de conversion et un CDN qui font la même chose. Je refuse aussi de convertir toute la médiathèque sans avoir testé sur un échantillon.
Si vos images sont déjà légères, le gain sera faible : on passe alors à un autre chantier.
Convertir les images n'allège pas un builder. Ça allège les octets, pas la dette.
🧭 Questions fréquentes
Faut-il convertir toutes les images tout de suite ? Non. On commence par la page d'accueil et les pages qui reçoivent du trafic, puis le reste suit. Convertir tout le dossier d'un coup est rarement nécessaire.
Peut-on convertir sans copie de test ? Sur une vitrine calme, parfois. Sur une boutique, mieux vaut essayer d'abord : certaines images disparaissent dans les anciens navigateurs. Voir Tester un site WordPress en local et en préprod.
Combien de temps ? Une demi-journée pour mettre en place le plugin et le test, plus le temps de convertir la médiathèque, qui peut tourner en tâche de fond. Un devis « on active WebP en cinq minutes » ignore les anciennes images.
