Une fiche produit WooCommerce se charge généralement de façon acceptable. La page boutique, les listes de catégories et les résultats de recherche, souvent non, et les commerçants en sont régulièrement surpris parce que les produits pris isolément semblent aller bien. La différence est arithmétique. Une fiche produit affiche une image principale. Une page de catégorie affichant vingt-quatre produits en affiche au moins vingt-quatre, et fréquemment le double une fois comptés les effets de survol et les aperçus de galerie.
Cette multiplication explique pourquoi les pages de catalogue sont habituellement l’élément le plus lent d’une boutique, et pourquoi ce sont aussi les pages qui comptent le plus commercialement. Elles se tiennent entre un visiteur qui arrive et un visiteur qui trouve quelque chose à acheter.
Le schéma derrière la plupart des catalogues lents : le thème demande une taille de vignette que WordPress n’a jamais générée, alors le navigateur télécharge le fichier téléversé en taille réelle et le réduit dans la page. Vingt-quatre produits, chacun expédiant une photographie de deux mégaoctets pour l’afficher à trois cents pixels, cela fait une page de catégorie de cinquante mégaoctets qui obtient un mauvais score quel que soit le cache ajouté.
Pourquoi les pages de catalogue se comportent différemment
Trois choses se cumulent sur une page de liste et pas sur une fiche produit.
Le volume. Chaque produit de la grille génère au moins une requête d’image. Les réglages WooCommerce par défaut affichent souvent seize ou vingt-quatre produits par page, et les boutiques plus grandes montent ce chiffre pour réduire la pagination.
Les images de survol et de galerie. Beaucoup de thèmes préchargent une seconde image par produit pour l’échange au survol. Cela double silencieusement le nombre d’images de la page, et comme cette seconde image n’est jamais visible avant interaction, elle ne contribue en rien au rendu initial tout en coûtant la même bande passante.
L’instabilité de mise en page. Les grilles qui ne réservent pas d’espace pour les images se déplacent à mesure que chacune arrive. Sur une fiche produit, un seul décalage se supporte. Sur une grille de vingt-quatre, le mouvement cumulé produit un mauvais score de Cumulative Layout Shift, et se ressent comme une page qui saute pendant qu’on essaie de cliquer.
La conséquence est que les pages de catalogue échouent aux Core Web Vitals pour des raisons qu’une fiche produit n’a pas, et qu’optimiser le gabarit produit ne leur apporte rien.
Le décalage de taille qui cause l’essentiel
WordPress génère un jeu de tailles d’images au téléversement. WooCommerce enregistre les siennes par-dessus. Les thèmes en enregistrent encore d’autres. Ce que le navigateur reçoit réellement dépend de laquelle de ces tailles le gabarit demande, et de l’existence de cette taille.
Le mode de défaillance est silencieux. Si un thème demande une taille enregistrée après le téléversement de vos produits, WordPress ne l’a jamais générée, donc il retombe sur l’original en taille réelle. La page a toujours l’air correcte, car le navigateur réduit l’image pour l’adapter. Elle déplace simplement plusieurs mégaoctets pour afficher une vignette.
Vous pouvez le repérer sans aucun outil. Ouvrez une page de catégorie, ouvrez le panneau réseau, et triez les requêtes d’images par taille. Si les tailles transférées sont proches du poids des fichiers d’origine plutôt qu’une fraction de celui-ci, la mauvaise taille est servie. Comparez les dimensions intrinsèques d’une image chargée à l’espace qu’elle occupe à l’écran. Une photographie arrivant à deux mille pixels de large pour remplir une tuile de trois cents pixels, c’est tout le problème en une seule observation.
Le correctif consiste soit à régénérer les vignettes pour que les tailles demandées existent, soit à servir la bonne taille à la diffusion pour que la question ne se pose jamais.
Le chargement différé, et où il déraille
WordPress charge les images en différé par défaut, ce qui aide les pages de catalogue plus que presque tout autre type de page, car l’essentiel d’une longue grille se trouve sous la ligne de flottaison.
Deux erreurs annulent ce bénéfice.
Différer la première rangée. Les images visibles à l’arrivée doivent se charger immédiatement. Si la plus grande est différée, le navigateur la découvre tard, et comme elle est généralement l’élément Largest Contentful Paint, la mesure en souffre directement. La plupart des thèmes se trompent ici en appliquant le chargement différé uniformément à chaque tuile produit.
Des extensions de chargement différé qui combattent l’implémentation native. Exécuter une extension qui ajoute son propre chargement différé par-dessus celui du navigateur produit des images qui ne se chargent jamais, se chargent deux fois, ou clignotent. Si vous avez une extension de performance installée, vérifiez si elle duplique ce que le navigateur fait déjà.
La diffusion : la partie qui passe à l’échelle
Régénérer les vignettes répare le catalogue d’aujourd’hui. Cela ne répare pas celui du mois prochain, quand un nouveau fournisseur envoie des photographies dans un autre rapport d’aspect, ou quand vous changez de thème et que les tailles nécessaires changent encore.
Transformer les images à la diffusion évite ce tapis roulant. L’original reste tel qu’il a été téléversé, et la taille servie est décidée par l’URL plutôt que par ce qui a été généré il y a des mois. Changez la grille, changez le paramètre. Il n’y a pas de régénération et aucun risque qu’une taille manquante retombe sur l’original complet.
Cela convient particulièrement aux catalogues, car la même photographie de produit apparaît typiquement en trois tailles : une tuile de grille, une image de fiche produit, et une vue zoom ou lightbox. Sous un modèle de facturation par image, cela fait trois facturations par produit. Sous le modèle de Cloudflare, ce sont trois variantes distinctes quel que soit le nombre de produits, et les requêtes répétées dans le mois ne coûtent rien.
Notre comparaison entre Cloudflare Image Transformations et les extensions d’images WordPress traite des différences de modèles de facturation et de ce qui convient à quelle forme de médiathèque.
Quoi changer, dans l’ordre
Traitez ces points en séquence. Chacun est mesurable isolément, et les faire dans le désordre rend difficile de savoir ce qui a aidé.
Commencez par déterminer si vous avez le décalage de taille, car si c’est le cas, rien d’autre ne compte tant qu’il n’est pas corrigé. Vérifiez la taille transférée des images de grille par rapport à l’espace qu’elles occupent.
Réduisez ensuite le nombre d’images que la page demande. Désactivez les images de survol si le thème les précharge et que vous pouvez vous passer de l’effet. Demandez-vous si vingt-quatre produits par page servent quelqu’un, ou si seize avec un chargement plus rapide convertissent mieux.
Corrigez ensuite la limite du chargement différé pour que la première rangée visible se charge immédiatement et que tout ce qui est en dessous ne le fasse pas.
Traitez ensuite la diffusion, afin que les tailles servies correspondent aux tailles affichées et restent correctes quand le catalogue change.
Ce n’est qu’après tout cela que le cache aide vraiment. Mettre en cache une page lente la rend uniformément lente plutôt que rapide, et c’est l’étape vers laquelle on se précipite en premier parce qu’elle est la plus facile à installer.
Pour le tableau plus large au-delà des images, la performance WooCommerce traite des requêtes de base de données, de la surcharge des extensions et des fragments non mis en cache qui ralentissent aussi les boutiques.
Faire mesurer correctement
Les commerçants savent généralement que la boutique semble lente sans savoir laquelle d’une douzaine de causes possibles en est responsable. Deviner coûte cher, car les correctifs évidents sont ceux qui ont déjà été essayés.
Mecanik réalise des audits de performance WordPress qui mesurent spécifiquement les pages de catalogue plutôt que de tester une page d’accueil et de considérer le travail fait, et prend en charge la mise en œuvre via des prestations de développement WordPress quand le correctif dépasse la configuration. Si ce sont vos pages de catégories qui perdent les visiteurs, c’est là que la mesure doit commencer.
Articles en relation: Performance WooCommerce : pourquoi votre boutique est lente , Migration de site web sans perte de trafic en 2026 , Cloudflare Image Transformations vs extensions WordPress , Développement e-commerce : Shopify vs solution sur mesure ., GEO pour l’e-commerce : vos données produit dans l’IA
Questions fréquentes
Pourquoi les pages de catégories WooCommerce sont-elles plus lentes que les fiches produits ? Une fiche produit charge une image principale. Une page de catégorie en charge une par produit, souvent doublée par les images de survol, donc vingt-quatre produits peuvent signifier quarante-huit requêtes d’images. Le même traitement d’images, anodin sur une fiche, se cumule mal sur une grille.
Comment savoir si WooCommerce sert la mauvaise taille d’image ? Ouvrez une page de catégorie et le panneau réseau du navigateur, puis comparez la taille transférée des images de grille aux fichiers téléversés d’origine. Si elles sont similaires plutôt qu’une fraction, le thème demande une taille que WordPress n’a jamais générée et l’original complet est réduit dans le navigateur.
Faut-il régénérer les vignettes ou transformer les images à la diffusion ? La régénération corrige le catalogue actuel mais doit être répétée à chaque changement de tailles ou de thème. La transformation à la diffusion décide de la taille depuis l’URL, elle reste donc correcte lors des changements de thème et des nouveaux téléversements, sans régénération.
Le chargement différé aide-t-il ou nuit-il aux pages de catalogue WooCommerce ? Il aide, car l’essentiel d’une longue grille est sous la ligne de flottaison, mais la première rangée visible doit se charger immédiatement. Différer la plus grande image visible retarde directement la mesure du Largest Contentful Paint, et c’est un réglage par défaut fréquent des thèmes.
Combien de produits par page pour la performance ? Moins d’images signifie une page plus rapide, mais plus de pagination signifie plus de clics pour parcourir. Seize à vingt-quatre est habituel. Le nombre compte bien moins que le fait que chaque image soit correctement dimensionnée, car une grille bien dimensionnée de vingt-quatre bat une grille surdimensionnée de douze.
Commentaires