Votre boutique est-elle lente ? Comment vérifier et quoi faire

« Ma boutique semble lente » n’est pas un diagnostic, c’est un symptôme, et se fier à une impression est le meilleur moyen pour un marchand de perdre un week-end à installer un module de cache qui ne corrige rien. Le premier travail n’est pas de corriger quoi que ce soit. C’est de déterminer, chiffres à l’appui, si votre boutique est réellement lente, où se situe la lenteur (le serveur ? le poids de la page ? la base de données ? un seul module défaillant ?) et quelle est son ampleur réelle. Mesurez correctement, et la correction s’impose souvent d’elle-même. Mesurez mal, et vous optimiserez les images d’une boutique dont le vrai problème est un Time to First Byte de 1,8 seconde qu’aucune astuce sur les images ne pourra résoudre.

Ce guide correspond à l’étape de diagnostic : comment vérifier correctement la vitesse d’une boutique PrestaShop, comment lire ce que les outils vous indiquent, et comment transformer cette lecture en liste de tâches priorisée. Les corrections approfondies, optimisation de la base de données, cache pleine page, Redis, hébergement, ont chacune leur guide dédié, et nous vous renvoyons vers le bon à chaque branche plutôt que d’en proposer ici une version superficielle.

Tout ce qui suit s’applique à PrestaShop 1.6, 1.7, 8.x et 9.x, l’interrupteur du profiler se trouve dans le même fichier sur ces versions. Sur PS8/9, vous disposez aussi de la barre de débogage Symfony avec le nombre de requêtes par requête HTTP, comme indiqué plus bas.

Pourquoi votre propre impression de vitesse est le test le moins fiable

Vous parcourez votre boutique depuis un bureau, avec une connexion filaire ou stable, souvent connecté au back-office, ce qui signifie que le profiler de débogage de PrestaShop et un cache chaud jouent en votre faveur, et que vous consultez des pages que vous avez déjà chargées aujourd’hui. Votre client, lui, utilise un téléphone Android de milieu de gamme, sur données mobiles, et arrive à froid sur une page de catégorie envoyée par Google. Ce sont deux boutiques différentes. Le marchand qui dit « chez moi, ça va » et les statistiques qui montrent un pic d’abandon au paiement sur mobile disent tous deux la vérité, ils ne mesurent simplement pas la même machine.

Donc avant tout outil : si vous testez en étant connecté à l’administration, vous ne voyez pas ce que voient vos clients. Ouvrez le front-office dans une fenêtre privée/incognito, ou mieux encore, limitez votre navigateur à « Slow 4G » dans Chrome DevTools. Cela suffit souvent à recadrer la discussion pour la plupart des marchands.

Les quatre vérifications utiles (et ce que chacune vous dit vraiment)

Vous n’avez pas besoin de dix outils. Vous avez besoin de quatre mesures qui, ensemble, vous indiquent si le problème vient du serveur, de la page ou des données, parce que ce sont trois chantiers de correction différents.

PageSpeed Insights, lisez les données terrain, pas seulement la note

Saisissez l’URL de votre boutique sur pagespeed.web.dev et vous obtiendrez un score mobile et un score ordinateur. Le score mobile est celui qui compte : Google indexe en priorité le mobile, et la majorité du trafic boutique se fait sur mobile. Mais le score (le grand cercle coloré) est une simulation de laboratoire. Remontez jusqu’à la section qui peut indiquer « Découvrez ce que vivent vos utilisateurs réels ». Ce sont les données de terrain CrUX issues de vrais visiteurs Chrome, et c’est l’image la plus fidèle. Une boutique peut obtenir 55 dans la simulation de laboratoire tout en réussissant les Core Web Vitals sur le terrain, ou l’inverse. Lisez les deux.

À titre de repère approximatif pour le score de laboratoire :

• 90–100, vous êtes en bonne position ; consacrez vos efforts ailleurs.
• 50–89. L’écart coûte réellement de l’argent ; un passage structuré en vaut la peine.
• En dessous de 50. Cela vous coûte déjà du trafic et des conversions ; traitez-le comme urgent.

Un score PageSpeed dans les 90 est atteignable sur une vraie boutique PrestaShop avec une pile de modules lourde, ce n’est pas un objectif théorique réservé aux installations de démonstration vides. Nous avons documenté précisément comment y parvenir sur une boutique PrestaShop en production dans PageSpeed 99/100 sur une vraie boutique avec 130 modules, qui sert de démonstration complémentaire à ce guide de diagnostic.

Les trois Core Web Vitals, et ce que chaque échec indique

Google évalue la vitesse réelle à l’aide de trois métriques. La valeur n’est pas le nombre en lui-même, c’est que la métrique qui échoue vous indique quel chantier ouvrir.

• Largest Contentful Paint (LCP), le temps nécessaire pour que le contenu principal soit visible. Objectif : moins de 2,5 s. Sur une page catégorie ou produit PrestaShop, il s’agit presque toujours de l’image principale ou de la première image produit, ou d’un serveur lent qui livre le HTML tardivement. Un LCP en échec pointe vers les images ou le TTFB.
• Interaction to Next Paint (INP), la rapidité avec laquelle la page réagit quand un client appuie. Objectif : moins de 200 ms. Un INP en échec pointe vers un JavaScript lourd ou dupliqué, généralement trop de modules front-office injectant chacun leurs propres scripts.
• Cumulative Layout Shift (CLS), l’ampleur des déplacements de mise en page pendant le chargement. Objectif : moins de 0,1. Un CLS en échec pointe vers des images servies sans attributs width/height, des polices web remplacées tardivement, ou un slider/bandeau cookies qui pousse le contenu vers le bas après le rendu.

La cascade et le TTFB, la séparation la plus utile

Ouvrez GTmetrix (ou l’onglet Network des DevTools de votre navigateur) et regardez un chiffre avant tout le reste : Time to First Byte (TTFB), l’écart entre la demande de page par le navigateur et l’arrivée du premier octet de la réponse. C’est la bifurcation la plus nette de tout le diagnostic :

• TTFB régulièrement au-dessus de ~500–600 ms sur une page à cache froid → le goulot d’étranglement est côté serveur : génération PHP, base de données ou hébergement lui-même. Aucune compression d’image ni optimisation front-end ne corrigera cela. C’est la branche qui mène aux corrections de cache, de base de données et d’hébergement.
• TTFB bas, mais page toujours lourde → le serveur fait son travail ; le poids se trouve dans le front-end, images, polices, bundles CSS/JS téléchargés après l’arrivée du HTML.

Cette seule mesure évite plus d’efforts perdus que toutes les autres. Les marchands qui la sautent passent des jours à minifier du CSS sur une boutique dont le problème était un TTFB de 1,8 s limité par la base de données.

Le profiler de débogage PrestaShop, la lecture base de données/module que presque personne ne fait

C’est la vérification propre à PrestaShop que la plupart des marchands n’utilisent jamais, alors qu’elle est la plus diagnostique. Sur une copie de préproduction, ouvrez config/defines.inc.php et définissez _PS_DEBUG_PROFILING_ sur true, c’est l’interrupteur qui active la barre de profiler du front-office et l’affichage du nombre de requêtes. La ligne exacte à chercher :

// config/defines.inc.php – staging only, switch back to false when done
define('_PS_DEBUG_PROFILING_', true);

Sur PrestaShop 8 et 9, vous disposez d’un second affichage, plus simple : avec la boutique en mode développement, la barre de débogage Symfony apparaît en bas de chaque page back-office et front-office et affiche le nombre de requêtes SQL ainsi que le temps total de cette requête, aucune modification de fichier n’est nécessaire au-delà de l’activation du débogage. Dans les deux cas, le chiffre qui compte est le même.

Vous n’avez besoin d’activer _PS_MODE_DEV_ (mode complet de débogage/erreurs) que si vous voulez aussi afficher les erreurs de développement ; ce n’est pas nécessaire simplement pour voir le nombre de requêtes, et il est plus risqué de le laisser activé. Chargez ensuite une page catégorie et une page produit. PrestaShop affiche une barre de profiler indiquant le temps de chargement et, surtout, le nombre de requêtes SQL de cette page. Une page saine compte des dizaines de requêtes ; si une seule page produit déclenche plusieurs centaines, voire quelques milliers de requêtes, vous avez trouvé votre lenteur, et il s’agit presque toujours d’un module précis qui boucle sur des requêtes ou d’une table non indexée, pas de « PrestaShop qui est lent ». Désactivez les deux interrupteurs avant de terminer ; ne les laissez jamais activés en production.

Des mesures à une liste de tâches priorisée

Un diagnostic n’est utile que s’il produit un ordre d’exécution. Faites correspondre vos mesures à la correction, en commençant par le meilleur rapport coût/impact, puis suivez le lien vers le guide qui couvre cette correction en profondeur, plutôt qu’un simple paragraphe ici :

Les deux vérifications gratuites à faire avant de dépenser quoi que ce soit

Une commande gratuite vous donne une première séparation entre DNS/temps de connexion, attente serveur et transfert total. Elle ne remplace pas Lighthouse, mais elle vous indique s’il faut commencer par l’hébergement/PHP/base de données ou par la charge front-end.

url="https://example.com/"
curl -o /dev/null -s -w 'dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s total=%{time_total}s
' ";$url

Gardez les chiffres avant/après au même endroit, sinon les optimisations deviennent des suppositions.

Deux corrections ne coûtent rien, sont fournies avec PrestaShop et doivent être confirmées avant tout achat ou mise à niveau, parce qu’elles modifient toutes les autres mesures que vous prenez.

Vérifiez que CCC est activé. Allez dans Paramètres avancés → Performance et activez le cache Smarty ainsi que « Combiner, compresser et mettre en cache » (CCC) pour CSS et JavaScript ; si votre configuration Apache/.htaccess le permet, activez aussi les directives d’optimisation Apache / cache navigateur pour les ressources statiques (cette option ne s’applique pas aux serveurs uniquement nginx). De nombreuses boutiques tournent pendant des années avec ces options désactivées. Activez-les, videz le cache et relancez PageSpeed. Vos chiffres front-end peuvent s’améliorer d’eux-mêmes. (Une réserve : CCC peut parfois entrer en conflit avec les ressources d’un module mal construit ; testez ensuite la boutique.)

Auditez votre nombre de modules. Chaque module front-office ajoute du CSS, du JavaScript et du PHP à chaque chargement de page. Ouvrez Apparence → Positions pour voir combien de modules sont accrochés au front-office, puis désinstallez, pas seulement désactivez, tout ce que vous n’utilisez pas activement. Une boutique qui transporte plus de 100 modules se battra contre son propre matériel. Les mécanismes qui expliquent quels modules font mal et pourquoi sont détaillés dans ce qui ralentit réellement PrestaShop.

Où un module mérite sa place, et où il ne la mérite pas

Une fois que votre diagnostic pointe clairement vers le temps de réponse serveur, TTFB élevé, chaque page régénérée pour chaque visiteur, c’est exactement le cas d’usage pour lequel un cache pleine page est conçu. Au lieu que PHP et la base de données reconstruisent la même page catégorie des milliers de fois par jour, un cache pleine page sert du HTML prêt à l’emploi et le serveur respire. Notre module Performance Revolution est notre réponse à cette mesure précise : il met en cache des pages entières afin que le TTFB baisse sans que vous ayez à réécrire un thème ou changer d’hébergeur. Qu’est-ce que cela signifie pour vous ? Les pages que vos clients et Google consultent à froid répondent vite, l’installation et la configuration se font depuis le back-office plutôt que via une facture de développeur, et, comme c’est le goulot d’étranglement côté serveur que vous avez mesuré, l’amélioration se voit pour chaque visiteur, pas seulement pour ceux qui ont la chance de tomber sur un cache chaud.

La limite honnête : un cache pleine page corrige une réponse serveur lente. Il ne réduit pas une image principale de 5 Mo et ne corrige pas une mise en page qui saute. Ce sont des problèmes front-end signalés par votre cascade, et ils relèvent de l’optimisation des images, pas du cache. Faites correspondre la correction à la mesure. Si votre lecture du backend de cache indique plutôt Redis, notre module Redis Cache Manager & Monitor couvre cette branche, et le guide Redis dédié explique quand c’est le bon choix.

Mesurez, corrigez, mesurez encore, sur des semaines, pas sur des jours

Enregistrez votre référence avant de toucher à quoi que ce soit : score PageSpeed mobile, les trois Core Web Vitals depuis Search Console, le TTFB et votre taux de conversion panier-commande. Changez une chose, puis mesurez à nouveau, mais laissez le temps aux données de terrain. Le rapport Core Web Vitals de Search Console fonctionne sur une fenêtre glissante de 28 jours, donc une correction publiée aujourd’hui n’apparaîtra pas complètement sur le terrain avant plusieurs semaines. Juger une optimisation sur trois jours de données, c’est ainsi que des marchands annulent une modification qui fonctionnait réellement. Associez les chiffres de vitesse au comportement : Google Analytics GA4 montre les temps de chargement des pages, et Microsoft Clarity montre si les pages lentes correspondent à des clics rageurs et à des sorties rapides, la dimension humaine d’un mauvais LCP.

Pourquoi cela vaut l’après-midi

Le travail sur la vitesse n’est pas spectaculaire, mais il a une qualité que le marketing a rarement : il aide chaque visiteur, à chaque fois, sans campagne à gérer. Le chiffre souvent cité selon lequel chaque seconde supplémentaire de chargement coûte des conversions varie selon les études et les boutiques, prenez-le comme une indication, pas comme une promesse, et mesurez votre propre avant/après plutôt que de croire un chiffre de blog. Ce qui est fiable, c’est la méthode : ne devinez pas, vérifiez ; lisez le TTFB pour séparer serveur et page ; laissez la métrique en échec désigner le bon chantier ; faites d’abord les deux corrections gratuites ; et seulement ensuite, dépensez de l’argent sur le goulot d’étranglement que vous avez réellement mesuré. Une boutique correctement diagnostiquée devient rapide avec une fraction de l’effort nécessaire à une boutique optimisée à l’instinct.

Questions fréquentes

Mon score PageSpeed est bon, mais la boutique semble toujours lente. Qu’est-ce que je rate ?

Vous lisez probablement le score de laboratoire tout en ressentant la réalité terrain, ou l’inverse. Le grand cercle coloré est un chargement simulé unique ; ce que vos clients vivent réellement se trouve dans les données de terrain CrUX plus haut dans le rapport, et dans le rapport Core Web Vitals de Search Console. Vérifiez aussi si vous testez en étant connecté au back-office, un cache chaud et la session admin flattent vos chiffres. Testez dans une fenêtre incognito avec le réseau limité à « Slow 4G » et l’écart s’explique généralement de lui-même.

Un TTFB élevé est-il toujours un problème d’hébergement ?

Non, et le supposer est l’erreur la plus coûteuse ici. Un TTFB élevé indique seulement que la lenteur est côté serveur. Il ne dit pas si la cause est la base de données, un module lourd ou le matériel. Lancez le profiler : si une page déclenche des centaines ou des milliers de requêtes SQL, c’est la base de données ou un module qui boucle, et un serveur plus puissant exécutera simplement les mêmes requêtes lentes un peu plus vite. Séparez les deux avant de dépenser, ce qui ralentit réellement PrestaShop explique comment les distinguer.

Un cache pleine page corrigera-t-il un mauvais score PageSpeed ?

Il corrige une réponse serveur lente, TTFB élevé sur des pages régénérées pour chaque visiteur, et rien d’autre. Il ne réduira pas une image principale de 5 Mo, ne corrigera pas une mise en page qui saute (CLS), et ne démêlera pas du JavaScript bloquant le rendu ; ce sont des problèmes front-end signalés par votre cascade. Faites correspondre la correction à la mesure : un cache pour la branche TTFB, l’optimisation des images pour la branche LCP/CLS.

Combien de temps faut-il attendre avant de croire qu’une modification a fonctionné ?

Les outils de laboratoire réagissent instantanément, mais le rapport Core Web Vitals de Search Console fonctionne sur une fenêtre glissante de 28 jours, donc une correction publiée aujourd’hui n’apparaîtra pas complètement sur le terrain avant plusieurs semaines. Juger une optimisation sur trois jours de données de terrain, c’est ainsi que des marchands annulent une modification qui fonctionnait réellement. Relancez tout de suite le test de laboratoire pour vérifier que rien n’a cassé, puis laissez aux données de terrain leur mois avant de conclure.

Est-il sûr d’activer le profiler sur ma boutique en production ?

Faites-le sur une copie de préproduction. _PS_DEBUG_PROFILING_ expose des informations internes et la barre à toute personne qui ouvre la page, et _PS_MODE_DEV_ peut divulguer des détails d’erreurs, ni l’un ni l’autre n’a sa place en production. Activez, prenez vos mesures, puis repassez les deux à false. Sur PS8/9, la barre Symfony en mode développement vous donne le même nombre de requêtes avec la même réserve : préproduction uniquement.

Lectures connexes

• Performance Revolution, le module de cache pleine page + CSS critique pour la branche TTFB élevé, avec les métriques avant/après dans un seul panneau
• Ce qui ralentit réellement PrestaShop, base de données contre modules contre hébergement, une fois que votre mesure TTFB indique « côté serveur »
• Optimisation des performances : des requêtes de base de données au cache pleine page, la correction approfondie pour un nombre élevé de requêtes SQL
• Nettoyage progressif de la base de données, pour un TTFB qui augmente à mesure que la boutique vieillit