Votre boutique met 4 secondes à charger. Vos clients n’attendent pas — ils partent chez le concurrent d’à côté.
Vous avez déjà vidé le cache, activé la compression, peut-être même installé un module de cache. Rien n’a vraiment changé !
Et quand vous contactez votre hébergeur, il vous répond que « tout est normal côté serveur ».
Le problème, c’est que la plupart des marchands — et beaucoup de prestataires PrestaShop — passent directement aux optimisations sans avoir d’abord identifié la source du problème. Résultat : des heures perdues à optimiser le mauvais endroit.
Ce guide vous donne la méthode inverse : on mesure d’abord, on agit ensuite. Trois étapes, trois outils gratuits, zéro jargon.
Sommaire
- Pourquoi la lenteur vous coûte plus cher que vous le pensez
- Étape 1 : mesurer le TTFB pour savoir si c’est le serveur
- Étape 2 : activer le profiler pour identifier le module coupable
- Étape 3 : analyser la base de données
- Comment éviter que votre PrestaShop ne ralentisse à nouveau
Pourquoi un e-commerce PrestaShop lent coûte plus cher que vous le pensez ?
L’impact sur vos ventes — en chiffres et euros
Un PrestaShop lent frustre vos visiteurs et détruit votre chiffre d’affaires en silence. Au contraire, un site qui se charge en 1 seconde convertit 2,5 fois plus qu’un site à 5 secondes.
Les données sur le sujet de la vitesse d’un site e-commerce sont sans appel.
Du côté des géants du web c’est impressionnant :
- Amazon a mesuré qu’un délai de 100 millisecondes coûte 1 % de chiffre d’affaires.
- Walmart a documenté un gain de 1 % de revenus pour chaque 100 ms gagnées.
Pour comparer des réalités de notre quotidien, sur une boutique PrestaShop à 20 commandes par jour avec un panier moyen de 67 € (la moyenne française e-commerce), chaque seconde de lenteur supplémentaire peut représenter une baisse de 7 % des conversions. Cela peut vite représenter des milliers d’euros.
Enfin, 53 % des visiteurs mobiles quittent un site qui met plus de 3 secondes à charger.
L’impact sur votre référencement
Un site lent se fait doubler dans les résultats par des concurrents plus rapides.
Moins de visibilité → moins de trafic → moins de ventes. C’est un cercle vicieux.
Et au-delà du classement, un site lent ralentit aussi le crawl de Google. Et Googlebot dispose d’un « budget d’exploration » limité pour chaque site. Si vos pages mettent trop de temps à répondre, Google en explore moins, et vos nouveaux produits mettent plus de temps à apparaître dans les résultats.
Le piège classique : optimiser sans mesurer
Installer un module de cache sans savoir si le problème vient du serveur, c’est comme mettre un pansement sur une jambe cassée. La majorité des marchands qui nous contactent pour des problèmes de lenteur ont déjà « tout essayé » — mais dans le désordre, sans savoir ce qu’ils cherchaient.
La bonne approche est simple : mesurer → identifier → agir. Et c’est exactement ce qu’on va faire dans les trois étapes suivantes.
Si votre boutique est lente au point de générer des erreurs 500, c’est que le problème est encore plus profond — consultez d’abord notre guide dédié.
Étape 1 — Mesurer le TTFB pour savoir si le problème vient du serveur
Google utilise les Core Web Vitals — dont le TTFB et le LCP (Largest Contentful Paint) — comme signaux de classement.
Le TTFB, c’est quoi et pourquoi c’est la première chose à regarder
Le TTFB — Time To First Byte — c’est le temps que met votre serveur à envoyer le tout premier octet de réponse au navigateur de votre visiteur. C’est la métrique qui sépare immédiatement un problème de serveur d’un problème de front-end.
Si le TTFB est bon (inférieur à 800 ms) mais que le site paraît lent → le problème vient du front-end : images trop lourdes, thème mal optimisé, trop de fichiers JavaScript ou CSS non minifiés. Ce type de problème se corrige sans toucher au serveur.
Si le TTFB est mauvais (supérieur à 1 seconde) → le problème est côté serveur : hébergement sous-dimensionné, module gourmand, ou base de données qui rame. Et aucune optimisation d’images ne résoudra ça.
Cette distinction est fondamentale. Elle évite de perdre des jours à compresser des images alors que le vrai problème se trouve dans la configuration du serveur ou dans un module mal codé.
Comment mesurer votre TTFB en 30 secondes
Vous pouvez également lire notre guide sur les performances PrestaShop complet.
Trois méthodes, toutes gratuites :
- GTmetrix — Entrez l’URL de votre boutique, lancez le test, et lisez la ligne « Server Response Time ». C’est votre TTFB.
- Google PageSpeed Insights — Entrez l’URL, attendez l’analyse, et cherchez dans la section « Diagnostics » la ligne « Reduce initial server response time ». Si elle apparaît en rouge ou orange, votre TTFB pose problème.
- Chrome DevTools — Ouvrez votre site dans Chrome, appuyez sur F12, allez dans l’onglet « Network », rechargez la page, cliquez sur la première requête (le document HTML), et regardez la colonne « Waiting (TTFB) ».
💡 Bon à savoir : Testez toujours sur au moins 3 types de pages — accueil, page produit, page catégorie. Le TTFB peut varier d’une page à l’autre. Les pages catégorie et les pages de recherche sont souvent les plus lentes parce qu’elles génèrent davantage de requêtes en base de données.
Ce que votre TTFB vous dit — tableau de diagnostic
| TTFB | Comportement du site | Diagnostic probable |
|---|---|---|
| < 800 ms | Lent à l’affichage | Problème front-end (images, thème, JS/CSS) |
| > 1 s | Lent partout | Problème serveur : PHP, module ou BDD |
| > 1 s | Lent uniquement en back-office | Module admin gourmand ou BDD saturée |
| Variable (tantôt rapide, tantôt lent) | Intermittent | Mémoire PHP insuffisante ou serveur mutualisé surchargé |
Si votre TTFB dépasse systématiquement 1 seconde, passez directement à l’étape 2. Si le TTFB est bon mais que le site est lent quand même, le problème est côté front-end et ne relève pas de ce guide — mais c’est généralement plus simple (et moins coûteux) à corriger.
Étape 2 — Activer le profiler pour identifier le module coupable
Le profiler PrestaShop, votre meilleur allié
Si le TTFB est élevé, la question suivante est : qu’est-ce qui prend autant de temps côté serveur ? La réponse se trouve dans le profiler de PrestaShop.
Le profiler, c’est un outil intégré qui mesure le temps d’exécution de chaque composant lors de la génération d’une page. Quand on l’active, une barre d’information détaillée apparaît en bas de chaque page avec le temps passé dans chaque module, le nombre de requêtes SQL exécutées, et la mémoire consommée.
Pour l’activer : rendez-vous dans Paramètres avancés → Performance → Mode debug → Oui. Rechargez ensuite la page qui pose problème et regardez les données en bas de page.
Si le back-office est trop lent pour y accéder, passez par FTP : ouvrez le fichier config/defines.inc.php et changez la constante _PS_DEBUG_PROFILING_ de false à true. Même astuce que pour l’erreur 500 — vous pouvez restreindre l’affichage à votre IP pour ne rien montrer à vos clients pendant l’analyse.
Comment lire les résultats sans être développeur
Vous n’avez pas besoin de comprendre chaque ligne. Ce qui compte, c’est de repérer trois choses :
Les gros consommateurs de temps. Un module dont le temps d’exécution se compte en centaines de millisecondes (200 ms, 400 ms, 800 ms) est un module qui ralentit votre boutique de façon significative. Un module à 400 ms sur chaque page, c’est quasiment une demi-seconde de perdue par visiteur, sur chaque clic.
Les modules qui s’exécutent au mauvais endroit. Un module conçu pour la page d’accueil mais qui s’accroche sur toutes les pages — y compris les pages produit et le tunnel de commande — consomme des ressources pour rien. Le profiler montre les « hooks » (points d’accroche) sur lesquels chaque module s’exécute.
Le nombre de requêtes SQL. PrestaShop génère en moyenne entre 120 et 180 requêtes SQL par page. Si le profiler en affiche 300, 400 ou plus, il y a forcément un ou plusieurs modules qui injectent des requêtes supplémentaires.
Le cas du module « invisible » qui rend PrestaShop lent
C’est un scénario qu’on rencontre régulièrement. Un module de recommandations, de statistiques internes, un module de caisse POS ou de SEO qui injecte des dizaines de requêtes SQL supplémentaires à chaque chargement de page. Le résultat : un temps de génération qui passe de 400 ms à plus de 2 secondes, sans que le marchand ne se doute de rien.
La solution n’est pas toujours de désinstaller le module. Parfois, il suffit de le désactiver sur les pages où il n’a pas d’utilité, ou de le remplacer par une alternative mieux codée.
💡 Bon à savoir : Les modules de statistiques internes de PrestaShop sont parmi les plus gourmands. Si vous utilisez déjà Google Analytics ou Matomo pour vos statistiques, désactivez ces modules natifs — ils n’apportent rien de plus et alourdissent chaque page. C’est le premier réflexe de tout expert PrestaShop lors d’un diagnostic de performance.
Pour aller plus loin sur les conflits de modules, consultez notre futur guide dédié aux modules PrestaShop incompatibles.
Étape 3 — Analyser la base de données
Les tables qui grossissent en silence
Votre PrestaShop ralentit progressivement depuis plusieurs mois ? Le site était rapide au lancement, mais il est devenu de plus en plus poussif ? Le coupable est probablement votre base de données.
PrestaShop enregistre par défaut chaque visite, chaque connexion, chaque source de trafic dans sa base de données — via les tables ps_connections, ps_connections_source et ps_guest. Sur une boutique active depuis plus de deux ans, ces tables peuvent peser plusieurs gigaoctets. La base de données devient trop lourde pour MySQL, les requêtes s’empilent, et le TTFB grimpe en flèche.
Pour vérifier : ouvrez phpMyAdmin, sélectionnez votre base PrestaShop, et triez les tables par taille (colonne « Taille » ou « Size »). Si ps_connections, ps_guest ou ps_log pèsent plusieurs centaines de mégaoctets, vous tenez une cause majeure de lenteur.
La correction consiste à vider ces tables avec un TRUNCATE — une opération qui supprime les données de statistiques internes sans toucher aux commandes, aux clients, ni au catalogue.
⚠️ Attention : Faites toujours une sauvegarde complète de votre base de données avant toute manipulation SQL. En cas de doute, confiez cette opération à un technicien.
Quand la base de données n’est pas le problème
Si les tables sont de taille raisonnable et que le TTFB reste élevé malgré tout, le coupable est soit un module (étape 2), soit le serveur lui-même.
Et c’est là qu’on touche au point que votre hébergeur ne vous dira probablement jamais : un hébergement mutualisé à 15 €/mois n’est pas conçu pour faire tourner PrestaShop correctement. Sur un mutualisé, vous partagez le processeur, la mémoire et le disque avec des dizaines, voire des centaines d’autres sites. Quand l’un de vos « voisins » connaît un pic de trafic, c’est votre boutique qui ralentit.
Les tests comparatifs le confirment : les hébergements mutualisés affichent régulièrement un TTFB supérieur à 1 000 ms sous charge modérée, là où un serveur dédié correctement configuré maintient un TTFB sous 400 ms même en période de pointe. Un serveur dédié peut être 3 à 10 fois plus rapide qu’un mutualisé haut de gamme, simplement parce que les ressources ne sont pas partagées.
Comment éviter que votre PrestaShop ne ralentisse à nouveau
La meilleure lenteur est celle qui n’arrive jamais. Voici les cinq réflexes de prévention les plus efficaces :
- Mesurez le TTFB une fois par mois. GTmetrix ou PageSpeed Insights, ça prend 30 secondes. Si le TTFB commence à grimper, vous le détectez avant que vos clients ne le subissent.
- Nettoyez les tables de statistiques tous les 3 mois. Ou mieux : désactivez les modules de stats natifs PrestaShop et déléguez vos statistiques à un outil externe (Google Analytics, Matomo). Votre base de données vous dira merci.
- Testez chaque nouveau module en staging. Installez le module, activez le profiler, et vérifiez son impact sur le temps de génération avant de passer en production. Un module qui ajoute 500 ms, c’est un module qu’on ne déploie pas.
- Choisissez un hébergement dimensionné pour PrestaShop. PHP 8.1 minimum, au moins 512 Mo de RAM dédiée, OPcache activé, disques NVMe, et un hébergeur qui connaît PrestaShop — pas un généraliste qui vous vend un mutualisé « compatible avec tout ».
- Mettez à jour régulièrement. PrestaShop, PHP, MySQL/MariaDB, vos modules — chaque version apporte des gains de performance. PHP 8.x est jusqu’à 30 % plus rapide que PHP 7.4. Et MariaDB conserve le query cache, contrairement à MySQL 8.0 qui l’a supprimé (un point rarement mentionné mais qui peut faire une vraie différence).
📊 Donnée terrain CYBERIAL : Un client sur deux migré chez CYBERIAL avait un hébergement sous-dimensionné pour PrestaShop. L’autre moitié était chez un hébergeur généraliste incapable de conseiller ou d’optimiser correctement la configuration serveur pour PrestaShop. Dans les deux cas, aucune optimisation côté boutique n’aurait suffi à résoudre le problème sans d’abord traiter l’infrastructure.
Votre boutique PrestaShop est lente et vous ne savez pas d’où ça vient ? Notre équipe diagnostique la cause exacte et remet votre site à niveau. Forfait dépannage à 150 €, intervention 7j/7. Ligne directe : 09 72 03 59 17.
Pour une boutique rapide toute l’année : le forfait maintenance CYBERIAL à 69 €/mois inclut le monitoring des performances, l’optimisation continue et l’intervention prioritaire.