Les pages de la boutique mettent plusieurs secondes à s’afficher. Ou bien c’est le back-office qui rame : la liste des commandes traîne, une fiche produit met longtemps à s’enregistrer.
La tentation est de prendre un serveur plus gros. C’est parfois la bonne réponse, souvent non. Avant de changer quoi que ce soit, nous cherchons ce qui freine vraiment.
Les causes que nous rencontrons le plus
- Un module trop gourmand : un seul module mal écrit peut lancer des centaines de requêtes à chaque page.
- Une base de données qui a grossi : paniers abandonnés, statistiques, journaux de connexion jamais nettoyés.
- Un cache mal réglé, ou désactivé après une intervention et jamais remis.
- Des robots qui parcourent la boutique sans arrêt, surtout les filtres et la recherche, et occupent le serveur.
- Un serveur sous-dimensionné, ou partagé avec trop d’autres sites.
- Des images trop lourdes et un thème qui charge beaucoup de scripts inutiles.
Boutique lente ou back-office lent : pas les mêmes pistes
Quand c’est la boutique qui est lente pour les visiteurs, nous regardons d’abord le cache, les images, le thème et les robots.
Quand c’est le back-office, la cause est plus souvent dans la base de données ou dans un module qui ajoute des calculs à chaque écran. Un back-office rapide tôt le matin et lent en journée oriente aussi vers le serveur : il sature quand le trafic monte.
Ce que nous mesurons
Nous commençons par des mesures, pas par des réglages. Le temps de réponse du serveur, les requêtes lentes de la base, le poids de chaque page, et ce que font les robots dans les journaux d’accès.
Ces mesures donnent un ordre de priorité. Il vaut mieux corriger la cause principale que d’empiler dix petites optimisations.
Un exemple précis : des statistiques qui débordent
PrestaShop enregistre chaque visite dans ses tables de statistiques, ps_connections et ps_guest. Sur une boutique de quelques années, elles dépassent souvent le million de lignes, et personne ne les vide.
Le journal des requêtes lentes le montre tout de suite :
# Query_time: 4.82 Rows_examined: 1240512
SELECT COUNT(*) FROM ps_connections WHERE date_add > '2026-10-01';Près de cinq secondes pour une seule requête, à chaque ouverture du tableau de bord. Archiver ces anciennes lignes suffit souvent à rendre au back-office toute sa vitesse.
Comment nous corrigeons
Selon ce que montrent les mesures : nettoyage de la base, réécriture ou remplacement d’un module, réglage du cache, filtrage des robots, ou changement de serveur quand c’est vraiment lui qui limite.
Chaque correction est vérifiée sur un site de test avant d’arriver sur la boutique. Nous refaisons les mesures après, pour vous montrer ce qui a changé.
Ils étaient dans ce cas
Plus Power vend des jantes avec une recherche par véhicule, appuyée sur une base de près de 100 000 entrées. Sans travail sur la base et sur le module de recherche, le site aurait été bien trop lent. Nous avons écrit ce module sur mesure et optimisé la base pour que la recherche reste rapide. Voir l’étude de cas Plus Power.
Et si c’est l’hébergement ?
Quand le serveur est vraiment la limite, nous en changeons sans couper la boutique. La méthode est décrite sur la page changer d’hébergeur sans couper son site.
Pour le reste de notre travail sur cette plateforme, voyez notre page agence PrestaShop.