# 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.

- Source canonique : [https://allaux.fr/guides/diagnostiquer-boutique-lente](https://allaux.fr/guides/diagnostiquer-boutique-lente)
- Langue : FR
- Dernière mise à jour : 2026-07-26

## Réponse directe

> Mesurez d’abord le TTFB pour savoir si le temps perdu est côté serveur ou côté affichage, puis comptez les requêtes SQL exécutées sur la page la plus lente. Dans la majorité des cas, la cause se trouve dans l’un des deux, rarement dans les deux à la fois.

## La démarche de diagnostic

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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

## FAQ

### Le diagnostic de performance risque-t-il de ralentir davantage le site ?

Non, la mesure et le profilage se font sans interrompre le site ni modifier son fonctionnement. Seules les corrections identifiées ensuite sont appliquées, en général testées avant d’être mises en production.

### Combien de temps prend un diagnostic complet ?

En général une demi-journée à une journée pour identifier les causes principales. La correction elle-même varie fortement selon ce qui est en cause : un ajout d’index se règle en quelques minutes, un module mal optimisé demande davantage de temps.

### Un site rapide en local mais lent en production, est-ce normal ?

Oui, c’est même fréquent : l’environnement de test contient en général beaucoup moins de données, ce qui masque les problèmes d’index ou de requêtes qui n’apparaissent qu’avec un volume réel de produits et de commandes.

### La lenteur touche uniquement le back-office, faut-il s’en inquiéter autant ?

Oui, même si l’impact commercial est indirect : un back-office lent ralentit la gestion quotidienne du catalogue et des commandes, et peut être le signe avant-coureur d’un problème qui touchera bientôt le front-office avec la croissance du catalogue.