WebP dans PrestaShop est activé, mais les images restent lourdes. Comment le vérifier ?

La conversion WebP activée ne détermine pas à elle seule quelle image le navigateur télécharge. Vérifiez la requête réelle dans l’onglet Network : l’URL sélectionnée, l’en-tête Content-Type, les dimensions et la taille de la réponse. Ce n’est qu’alors que vous pourrez établir si le problème vient de l’absence de la bonne variante, d’une règle serveur, du cache ou d’une image trop volumineuse.

Ce guide s’adresse aux propriétaires de boutiques PrestaShop qui disposent déjà de WebP, mais constatent encore des images lourdes ou un faible score de performance. Il contient un test réel et contrôlé sur trois illustrations, ainsi qu’une méthode pour distinguer la conversion du fichier de sa livraison au client.

1. Commencez par l’image visible sur une page précise

Choisissez une image sur une fiche produit ou une liste de produits. Ne commencez pas par un fichier pris au hasard dans le répertoire du serveur : le thème peut utiliser une autre miniature, une variante pour écran à plus forte densité de pixels ou une URL provenant d’un CDN. Le WebP de l’original ne remplace pas automatiquement toutes les tailles nécessaires.

Ouvrez les outils de développement, allez dans Network, désactivez le cache pendant le test et rechargez la page. Sélectionnez le filtre des images. Pour les images chargées en lazy loading, faites défiler jusqu’à l’emplacement analysé. Notez l’URL, le type de réponse, la taille et l’information indiquant si les données ont réellement été téléchargées depuis le réseau. Ces options sont décrites dans la documentation Network de Chrome DevTools.

Ne comparez pas un téléchargement complet de JPEG avec une ligne WebP marquée comme memory cache. Un tel résultat décrit d’autres conditions. De même, un faible transfert avec une réponse 304 ne signifie pas que le fichier image lui-même ne pèse soudainement que quelques octets.

2. Une URL en .jpg peut renvoyer du WebP

Dans les sources de WebP Pro 2.1.3, la livraison de l’image peut fonctionner via des règles Apache : une requête JPG ou PNG est réécrite vers une variante WebP existante si le navigateur déclare la prendre en charge. L’adresse visible dans le HTML peut donc toujours se terminer par .jpg, tandis que la réponse a pour type image/webp.

C’est pourquoi le simple aperçu du code source de la page ne suffit pas pour conclure que « WebP ne fonctionne pas ». Vérifiez le format de la réponse reçue. À l’inverse, la présence de .webp dans les paramètres ou l’existence du fichier sur le disque ne prouvent pas qu’une règle appropriée est bien exécutée sur le serveur qui héberge la boutique.

3. Vérifiez srcset, picture et la variante sélectionnée

Avec des images responsives, le navigateur choisit la ressource en fonction des conditions de la page et de l’appareil. Vérifiez l’élément img, les éventuels srcset et sizes, et dans le cas de picture, également les éléments source. La propriété currentSrc aide à identifier l’adresse réellement sélectionnée, au lieu de se fier à la première entrée du code.

L’élément picture permet de fournir des sources alternatives, par exemple selon le format ou une condition media ; les règles de sélection sont présentées dans la documentation de l’élément picture. Tous les thèmes n’utilisent pas ce mécanisme, et toutes les boutiques n’ont pas besoin de modifier le HTML si la négociation de format côté serveur fonctionne correctement.

Répétez le test sur téléphone. Une image de 2000 px de large utilisée dans une petite miniature reste une charge inutile, même après conversion. Le choix de la taille et le choix du format sont deux réglages distincts.

4. Notre propre mesure : trois illustrations en JPEG et WebP

Pour ce test contrôlé, nous avons utilisé trois illustrations de blog existantes au format 700 × 400 px. Chaque JPEG a été converti en WebP via PHP 8.1.34 et GD 2.3.3 avec un paramètre de qualité de 80. Nous n’avons modifié ni les dimensions ni le cadrage. Chromium a téléchargé six fichiers depuis un serveur HTTP local, avec le cache désactivé et sans CDN.

La source des miniatures était une copie locale de PrestaShop 8.2.8 avec Warehouse 4.7.2. La mesure elle-même a été effectuée sur une page de comparaison distincte ; elle ne mesure donc ni le temps d’ouverture d’une fiche produit ni l’effet du déploiement du module. Nous indiquons les octets du contenu des réponses reçues, hors en-têtes de transport. Les six requêtes se sont toutes terminées en HTTP 200 avec le bon type d’image.

Le résultat montre la taille de fichiers précis. Il ne prouve pas que chaque WebP sera plus petit de la même valeur, ni que les deux encodages ont une qualité visuelle identique. Les paramètres de qualité des différents formats ne reposent pas sur une échelle commune. Examinez les images à leur taille réelle d’utilisation, en prêtant attention aux textes, aux textures fines et aux contours nets.

5. Vérifiez la file d’attente avant de relancer la conversion

Dans WebP Pro 2.1.3, l’enregistrement ou le redimensionnement d’une image peut ajouter une tâche à la file d’attente. La variante finale n’est créée qu’après son exécution. Lors du diagnostic, vérifiez si la bonne plage a été sélectionnée, si la tâche a été traitée et si elle ne s’est pas terminée par une erreur. Le simple enregistrement du planning ne lance pas automatiquement la tâche système CRON.

Un changement de qualité ne modifie pas non plus forcément immédiatement les fichiers existants. Dans le code examiné, un WebP fraîchement généré peut être ignoré hors mode d’écrasement. Si vous modifiez volontairement la qualité, planifiez la régénération de la plage nécessaire, puis vérifiez le résultat. Ne lancez pas une régénération complète de toute la boutique à chaque petite divergence.

Si vous avez besoin d’instructions sur le processus même de création des miniatures, lisez le guide sur la génération et la régénération des images. Ici, le point d’arrivée est l’image reçue par le client.

6. Vérifiez séparément le cache, le CDN et le LCP

Lors de la négociation du format, il est important que la couche intermédiaire distingue les variantes de réponse. Les règles de WebP Pro prévoient Vary: Accept si le module d’en-têtes Apache est disponible. Cela ne signifie toutefois pas une configuration automatique de n’importe quel CDN ou de Nginx. Vérifiez la réponse réelle depuis l’endroit où le navigateur la télécharge.

Après avoir modifié l’image, rafraîchissez le bon cache et répétez exactement le même test. Notez l’appareil utilisé, l’état du cache, l’URL et les dimensions. Sans ces données, la comparaison « avant/après » mélange facilement des images différentes ou des conditions différentes.

Un fichier plus petit peut réduire le temps de téléchargement, mais le LCP comprend aussi d’autres étapes, notamment l’attente du serveur, la découverte de la ressource et son affichage. Le guide Google sur l’optimisation du LCP montre pourquoi la seule compression ne résout pas tous les retards. Ne promettez pas un score PageSpeed de 100 sur la seule base du format.

Étape suivante : s’il manque la génération ou la livraison des bonnes variantes, consultez WebP Pro pour PrestaShop. Si les images sont correctes mais que la page reste lente, préparez les résultats Network et demandez un diagnostic des performances de la boutique.

Vérifié le 13.09.2026. Mécanismes du module : code WebP Pro 2.1.3. Mesure des illustrations : test HTTP contrôlé distinct ; il ne s’agit pas d’une mesure de vitesse d’une boutique en production.