Comment diagnostiquer une boutique e-commerce lente
Changer d’hébergement au hasard face à une boutique lente corrige rarement le problème, parce que la lenteur a presque toujours une cause précise et localisable. La mesurer avant d’agir évite de dépenser du temps et de l’argent sur la mauvaise piste.
La démarche de diagnostic
-
Mesurer avec un outil externe
PageSpeed Insights ou GTmetrix donnent une première mesure objective : temps de chargement, TTFB, poids total de la page, et détail des ressources les plus lentes à charger.
-
Séparer temps serveur et temps de rendu
Un TTFB élevé (au-delà de 600 à 800 ms sur une page dynamique) pointe vers un problème serveur ou base de données. Un TTFB correct mais un affichage complet lent pointe plutôt vers le poids des ressources ou le rendu JavaScript.
-
Compter les requêtes SQL sur la page la plus lente
Sur PrestaShop, le mode debug active une barre de profilage qui liste chaque requête SQL et son temps d’exécution. Sur WooCommerce, l’extension Query Monitor offre une fonction équivalente.
-
Vérifier l’état du cache
Un cache désactivé, mal configuré ou systématiquement invalidé est l’une des causes les plus fréquentes et les plus simples à corriger, avant d’envisager toute autre optimisation.
-
Vérifier la configuration serveur
La version de PHP utilisée, la présence d’OPcache, et le memory_limit disponible ont un impact direct, en particulier sur un catalogue volumineux.
-
Isoler les modules ou extensions suspects
Un module ou une extension qui exécute du code lourd sur chaque page (appel externe, tracking, recommandation produit) peut ralentir l’ensemble du site même quand sa fonctionnalité n’est pas utilisée à ce moment.
Pourquoi mesurer avant de changer d’hébergement
Un serveur plus puissant masque temporairement un problème de requêtes mal indexées ou de modules mal optimisés, mais la lenteur revient dès que le catalogue ou le trafic augmente à nouveau. À l’inverse, un hébergement réellement sous-dimensionné pour le trafic reçu ne se corrige pas uniquement en optimisant le code.
C’est pour cela que la mesure précède toujours la décision : elle indique si le problème est structurel (base de données non indexée, absence de cache) ou capacitaire (ressources serveur insuffisantes pour le volume réel de visites). Les deux se traitent différemment et rarement avec la même urgence.
Sur un catalogue de plusieurs milliers de références, l’absence d’index sur les colonnes utilisées dans les jointures (identifiant produit, identifiant boutique, identifiant langue) est une cause récurrente, invisible tant que le volume de données reste faible en environnement de test.
Les signaux qui justifient un diagnostic
- Une fiche produit ou une page catégorie qui met plus de trois secondes à s’afficher
- Un ralentissement progressif au fil des mois sans changement technique apparent
- Un back-office qui devient lent uniquement lorsque le catalogue dépasse plusieurs milliers de références
- Un score PageSpeed ou des Core Web Vitals mauvais malgré un hébergement présenté comme performant
- Une lenteur qui n’apparaît que pendant les pics de trafic
Questions fréquentes
Le diagnostic de performance risque-t-il de ralentir davantage le site ?
Combien de temps prend un diagnostic complet ?
Un site rapide en local mais lent en production, est-ce normal ?
La lenteur touche uniquement le back-office, faut-il s’en inquiéter autant ?
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.