Votre boutique PrestaShop est lente ? Mesurez avant d’optimiser

Dernière mise à jour : juin 2026.

Quand une boutique PrestaShop semble lente, la réaction la plus courante est aussi la plus coûteuse : installer un module de cache ou d’optimisation, activer toutes les options, et espérer. Parfois, cela aide. Souvent, cela ne change rien — et il arrive même que cela aggrave la situation, parce que le vrai goulot d’étranglement ne se trouvait pas là où le module intervient. Les problèmes de vitesse sont d’abord des problèmes de diagnostic. Le conseil honnête de toute personne qui fait ce travail au quotidien est toujours le même : mesurez avant d’optimiser. Trouvez la cause réelle, puis dépensez votre budget sur la correction qui la traite — ce qui, parfois, signifie ne rien dépenser du tout.

Pourquoi deviner coûte si cher

« Ma boutique est lente » est un symptôme, pas un diagnostic. La cause sous-jacente peut se trouver à plusieurs endroits très différents, et un outil qui corrige l’un d’eux ne fera rien pour les autres :

• Un seul module qui déclenche une requête N+1 sur chaque page produit — une requête supplémentaire par élément dans une boucle, multipliée par la taille de votre catalogue.
• Un thème lourd qui charge des centaines de kilo-octets de CSS et de JavaScript bloquant le rendu avant que quoi que ce soit ne s’affiche.
• Un TTFB lent (temps avant le premier octet) dû à un hébergement mutualisé surchargé ou à un serveur de base de données déjà au plafond de ses capacités CPU ou E/S.
• Des images non optimisées — des fichiers en pleine résolution servis sur mobile, sans formats modernes ni dimensionnement adapté.
• Pas de cache pleine page, si bien que PrestaShop reconstruit chaque page depuis zéro pour chaque visiteur.
• Une instance MySQL en manque de mémoire, qui parcourt des tables entières là où un index devrait être utilisé.

Voici le piège. Si votre problème vient d’un thème qui bloque le rendu et d’un TTFB lent, un module de cache de page peut gagner un peu de temps sur les visites répétées tout en laissant intacte la première impression — celle que Google mesure. Si votre problème vient d’une base de données surchargée, aucune optimisation des fichiers front-end ne fera bouger l’aiguille. Vous pouvez investir indéfiniment dans la mauvaise couche sans jamais sentir votre boutique plus rapide. C’est pourquoi nous considérons qu’un audit de performance est la première étape : il indique quelle couche vous coûte réellement du temps, afin que le prochain achat (s’il y en a un) vise juste.

Ce que mesure réellement un audit de performance

Un audit sérieux ne se résume pas à une note dans un test de vitesse. Il décompose la page en ses vrais composants et montre où le temps est dépensé :

Temps serveur ou temps navigateur

La première séparation oppose le TTFB au rendu front-end. Le TTFB couvre tout ce qui se passe avant que votre serveur n’envoie le premier octet — exécution PHP, requêtes de base de données, lectures de cache. Le rendu front-end couvre ensuite tout ce que le navigateur fait avec la réponse. Une page de 3 secondes avec 2,4 s de TTFB indique un problème back-end ; la même page de 3 secondes avec 0,2 s de TTFB et 2,8 s de rendu indique un problème front-end. Les correctifs sont opposés, et seule la mesure vous dit dans quel cas vous êtes.

Requêtes par page et principaux responsables

Les pages PrestaShop peuvent exécuter de quelques dizaines à plusieurs centaines de requêtes SQL. L’audit les compte par type de page et classe les pires responsables — souvent un seul module qui devrait mettre une recherche en cache, mais relance une requête à chaque hook. Trouver cette requête vaut souvent plus que n’importe quelle couche de cache ajoutée par-dessus.

Surcoût des modules

Chaque module accroché à une page ajoute du travail, et certains s’exécutent sur toutes les pages, qu’ils y soient nécessaires ou non. L’audit profile les modules qui contribuent réellement au temps d’exécution et ceux qui se lancent inutilement, afin que vous puissiez désactiver ou remplacer les vrais coupables au lieu de deviner.

Poids des ressources et cache

Il mesure le poids total de la page, le nombre de requêtes, et la qualité de la configuration CCC (combine-compress-cache), critical-CSS et JavaScript différé — ou vérifie s’ils sont configurés tout court. Il contrôle aussi toute la chaîne de cache : taux de réussite du cache pleine page, OPcache pour le PHP compilé, et Redis pour le cache d’objets/de requêtes. Un cache qui existe mais touche rarement sa cible ne vaut presque rien, et seul le taux de réussite le révèle.

Plafond de l’hébergement, mobile et Core Web Vitals

Enfin, il examine la réalité matérielle — marge CPU, E/S et mémoire sous charge — et teste le mobile séparément de l’ordinateur, parce que la majorité de votre trafic et la majeure partie des mesures de Google se font sur mobile. Cela rejoint directement les Core Web Vitals : LCP, CLS et INP. Ce ne sont pas des métriques de façade ; ce sont de vrais signaux de classement, d’où le recoupement entre vitesse et référencement, et pourquoi un audit SEO technique et un audit de performance font si souvent remonter les mêmes problèmes.

Un autodiagnostic à faire en dix minutes

Vous n’avez pas besoin de commander quoi que ce soit pour obtenir une première lecture de votre boutique. Ouvrez votre page d’accueil et une page produit bien chargée dans Chrome, puis essayez ceci :

• Lancez une cascade réseau. Ouvrez les DevTools, allez dans l’onglet Network, faites un rechargement forcé, puis regardez la toute première requête. Son temps « Waiting (TTFB) » vous indique la part côté serveur. Au-delà d’environ 600 ms sur un cache chaud, cela pointe vers le back-end.
• Comptez les requêtes et le poids. Le pied de l’onglet Network affiche le nombre total de requêtes et la taille transférée. Des centaines de requêtes ou plusieurs mégaoctets par page sont un signal fort côté ressources/CCC.
• Lisez le profiler PrestaShop. Activez le mode debug sur une copie de préproduction et lancez le profiler — il affiche le nombre de requêtes et les requêtes les plus lentes par page. Une page produit qui exécute 250 requêtes ou plus mérite votre attention.
• Bridez le mobile. Dans les DevTools, choisissez un profil mobile de milieu de gamme avec une limitation « Slow 4G », puis rechargez. Si l’expérience se dégrade ici, c’est ce que ressentent réellement la plupart de vos visiteurs.

Ces chiffres sont des seuils indicatifs, pas des garanties — chaque boutique est différente. Mais ils vous orienteront généralement vers la bonne zone avant que qui que ce soit ne dépense un euro.

Mesurer le TTFB en ligne de commande

Si vous préférez obtenir un chiffre précis du temps serveur sans ouvrir les DevTools, curl affiche directement le détail des timings. C’est en lecture seule — il se contente de récupérer la page et d’afficher le temps pris par chaque phase :

# Print connection, TLS, TTFB and total time for one page load
curl -s -o /dev/null \
  -w "dns:    %{time_namelookup}s\nconnect: %{time_connect}s\nTLS:     %{time_appconnect}s\nTTFB:    %{time_starttransfer}s\ntotal:   %{time_total}s\n" \
  https://yourdomain.com/your-product-page

Le chiffre le plus important ici est le TTFB (time_starttransfer) : tout ce qui précède le premier octet de la réponse. Lancez la commande plusieurs fois afin qu’un cache froid ne fausse pas le résultat. Si ce chiffre reste élevé — largement au-delà d’une demi-seconde sur un cache chaud — votre goulot d’étranglement est côté serveur (PHP, requêtes, hébergement), et aucune optimisation des ressources front-end ne le corrigera. Si le TTFB est bas mais que la page paraît toujours lente dans le navigateur, le coût se situe plutôt dans le rendu et les ressources. Cette simple séparation est toute la raison de mesurer avant d’acheter.

La partie honnête : ce que l’audit vous recommande de faire

Tout l’intérêt de mesurer d’abord, c’est que le verdict n’est souvent pas « achetez un module d’optimisation ». Un bon audit aboutit à l’une de ces directions claires :

• C’est l’hébergement. Si le TTFB reste élevé même lorsque la page est servie depuis le cache et que le serveur atteint son plafond CPU/E/S, aucun module ne corrigera cela — il vous faut un meilleur hébergement ou une configuration serveur ajustée, ce que permet justement de cadrer un audit d’hébergement.
• C’est la configuration. Souvent, les caches existent mais sont mal configurés : CCC à moitié activé, OPcache trop petit, Redis pas réellement branché. C’est un réglage, pas un achat.
• C’est un module ou un thème précis. Parfois, un module lourd ou un thème inefficace constitue tout le problème, et la correction consiste à le remplacer ou à le supprimer.
• Vous avez vraiment besoin d’un outil. Si le goulot d’étranglement vient des ressources front-end et de l’absence de cache pleine page, un module ciblé, au code ouvert, comme Performance Revolution est le bon achat — une fois que vous savez que c’est cette couche qui vous coûte du temps, pas avant.
• Tout va déjà bien. Il arrive que l’audit montre une boutique saine et que la lenteur perçue vienne d’un seul script tiers lent ou d’un problème réseau régional. Le savoir vous évite d’« optimiser » quelque chose qui n’est pas cassé.

Acheter à l’aveugle, c’est ainsi que des boutiques finissent avec trois modules de cache qui se chevauchent et un site plus lent qu’au départ. Diagnostiquer d’abord coûte moins cher, même quand le diagnostic a un prix, parce qu’il vous empêche de dépenser sur la mauvaise couche.

Comment commencer

Si vous voulez une analyse structurée plutôt qu’un après-midi de bricolage, notre audit de performance est conçu exactement pour cela. Vous saisissez l’URL de votre boutique, un rapide contrôle de préparation en lecture seule s’exécute d’abord — aucun identifiant d’administration n’est transmis, consultez nos notes sur la préparation d’un audit de boutique pour voir comment nous gérons les accès — puis seulement l’audit est commandé. Il s’inscrit aux côtés de nos autres services d’experts pour les cas où la solution relève de l’hébergement, de la configuration ou du développement plutôt que d’un produit. Quelle que soit l’issue, vous saurez pourquoi la boutique est lente avant de dépenser pour la rendre rapide — et c’est précisément ce qui fait économiser de l’argent.

Questions fréquentes

J’ai déjà installé un module de cache. Pourquoi ma boutique est-elle toujours lente ?

Parce que le cache n’aide que la couche sur laquelle il agit. Un cache pleine page ne fait rien contre un premier octet lent causé par une base de données surchargée, et un optimiseur front-end ne peut pas corriger un serveur au plafond de sa capacité CPU. Il est aussi courant qu’un cache soit installé mais presque jamais utilisé — CCC à moitié configuré, OPcache trop petit, Redis pas réellement branché. La séparation TTFB ci-dessus vous indique si votre goulot d’étranglement se trouve seulement dans une couche que le cache peut toucher. Souvent, ce n’est pas le cas, d’où l’impression que le module « n’a rien fait ».

Qu’est-ce qu’un « bon » TTFB pour PrestaShop ?

À titre indicatif, moins d’environ 200 ms est sain, environ 200 à 600 ms est acceptable, et un résultat constamment supérieur à environ 600 ms sur un cache chaud indique un problème côté serveur qui mérite d’être creusé. Ce sont des zones, pas des lignes strictes — une page produit lourde fait légitimement plus de travail que la page d’accueil. La comparaison utile est celle de votre propre boutique à froid puis à chaud, et de votre TTFB face au temps de rendu ajouté ensuite par le navigateur. C’est ce ratio, pas un chiffre isolé, qui vous indique où dépenser.

Un audit de performance peut-il garantir que ma boutique sera plus rapide ?

Non, et méfiez-vous de toute personne qui le promet. Un audit vous dit pourquoi la boutique est lente et quel correctif répond au problème — il n’applique pas la correction et ne garantit pas un chiffre. Si la cause est l’hébergement, le gain dépend de la nouvelle stack ; si c’est un module lourd, il dépend de votre capacité à le remplacer ; si tout va déjà bien, le résultat honnête est « ne dépensez rien ». La valeur est de viser correctement la dépense, pas de promettre un nombre de millisecondes.

L’audit va-t-il ralentir ou mettre en risque ma boutique en production ?

Non. Le contrôle de préparation et les mesures sont en lecture seule — ils chargent les pages comme le ferait un visiteur et enregistrent les timings ; rien n’est écrit ni modifié. L’étape du profiler dans l’autodiagnostic est la seule chose à lancer sur une copie de préproduction plutôt qu’en production, car le mode debug expose des informations internes et ajoute une surcharge. L’audit lui-même n’a pas besoin du mode debug sur votre site de production.

En quoi est-ce différent d’un simple test PageSpeed Insights ?

PageSpeed mesure le rendu front-end d’une URL et le note par rapport aux Core Web Vitals — c’est réellement utile, et cela vaut la peine de le lancer. Ce qu’il ne peut pas voir, c’est votre serveur : nombre de requêtes, quel module s’exécute à chaque hook, vos taux de hit de cache, ou si la base de données est le vrai plafond. Une page peut obtenir un bon score PageSpeed tout en restant lente sous la charge réelle du catalogue, ou obtenir un mauvais score pour une raison qu’un module ne peut pas corriger. L’audit couvre la moitié back-end que PageSpeed ne voit pas.

Articles connexes

• Est-il sûr de donner à un auditeur PrestaShop accès à votre boutique ?
• Présentation d’Expert Services : des audits PrestaShop avant d’acheter un nouveau module
• Comment savoir si votre boutique PrestaShop a besoin d'un audit SEO
• Signes que votre boutique PrestaShop a besoin d’un audit de sécurité (et comment faire une première vérification vous-même)
• SEO PrestaShop : le guide complet pour mieux vous positionner