Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

Écrire un message contact@allaux.fr
FR EN TR
allaux.
Urgence Parler de mon projet

Votre boutique PrestaShop met trop de temps à charger

Une boutique lente ne se règle pas en changeant d’hébergement au hasard. La lenteur vient presque toujours d’un point précis : requêtes SQL non indexées, cache Smarty mal configuré, ou un module qui exécute du code inutile sur chaque page.

Décrire mon problème Écrire un message

Comment je mesure avant d’intervenir

  1. Profilage de la page

    J’active le débogueur de performance pour lister les requêtes SQL exécutées sur une page donnée, leur nombre et leur temps d’exécution. Une fiche produit qui déclenche plus de 200 requêtes n’est pas normale.

  2. Vérification du cache

    Je contrôle l’état du cache Smarty (compilation et cache de rendu) et, sur PrestaShop 1.6, l’activation de la combinaison et compression CSS/JS (CCC).

  3. Analyse des index MySQL

    Je regarde les requêtes lentes côté base et j’ajoute les index manquants sur les tables les plus sollicitées, typiquement ps_product, ps_product_attribute et ps_category_product.

  4. Audit des modules

    Je repère les modules qui s’accrochent à des hooks exécutés sur chaque page (displayHeader, actionFrontControllerSetMedia) et qui font des appels externes ou des requêtes non nécessaires.

  5. Vérification serveur

    Je vérifie la présence d’OPcache, la version PHP utilisée et si un système de cache mémoire (Redis ou Memcached) est disponible pour remplacer le cache fichier par défaut.

Site PrestaShop lent : le serveur ou le navigateur ?

Avant de corriger quoi que ce soit, il faut savoir si le temps se perd sur le serveur ou dans le navigateur. Ouvrez les outils de développement du navigateur, onglet Réseau, et regardez la première ligne : le temps d’attente de la réponse du serveur, le TTFB.

  • TTFB élevé, au-delà d’une seconde environ : le serveur met du temps à fabriquer la page. La cause est en PHP, en base de données ou dans un module, et c’est l’objet de cette page.
  • TTFB correct mais page longue à s’afficher : le serveur répond vite, le navigateur peine ensuite. Images trop lourdes, scripts tiers (messagerie, avis, suivi publicitaire), polices et JavaScript non différés : c’est un travail sur le front, pas sur le serveur.
  • Seul le back-office est lent : regardez les listes de commandes, de produits ou de clients sur de gros volumes, les modules du tableau de bord, et la taille des tables de statistiques comme ps_connections, ps_guest ou ps_pagenotfound, qui grossissent sans limite quand rien ne les purge.

Les réglages oubliés qui ralentissent toute la boutique

Une part étonnante des boutiques lentes que je vois n’ont aucun problème de code : un réglage de dépannage est resté actif.

  • _PS_MODE_DEV_ laissé à true dans config/defines.inc.php après une intervention. Sur 1.7, 8 et 9, il fait aussi tourner le back-office dans l’environnement de développement de Symfony, nettement plus lent.
  • _PS_DEBUG_PROFILING_ activé : chaque page calcule et affiche son propre profil, ce qui a un coût à chaque affichage.
  • Dans Paramètres avancés > Performances, la compilation des templates réglée sur « Forcer la compilation » : Smarty recompile les gabarits à chaque affichage au lieu de les réutiliser.
  • Le cache désactivé dans ce même écran, parfois pour « voir une modification » et jamais réactivé.

Ces quatre points se vérifient en quelques minutes et ne demandent aucun développement. Ils passent avant toute conclusion sur l’hébergement.

Les signaux qui justifient un audit

  • Fiche produit ou page catégorie qui met plus de 3 secondes à s’afficher
  • Back-office qui devient lent dès que le catalogue dépasse quelques milliers de références
  • Ralentissement progressif au fil des mois sans changement apparent
  • Pic de lenteur uniquement pendant les périodes de forte affluence
  • Score PageSpeed ou Core Web Vitals mauvais malgré un hébergement correct

Ce que je corrige le plus souvent

Le cache fichier par défaut de PrestaShop (var/cache) tient très bien sur un catalogue de quelques centaines de produits, mais devient un goulot d’étranglement sur un gros catalogue avec beaucoup de trafic simultané, car chaque écriture de cache verrouille le disque. Passer sur un cache mémoire change souvent la donne sans toucher au code.

Côté base de données, l’absence d’index sur les colonnes utilisées dans les jointures (id_product, id_shop, id_lang) fait exploser le temps de réponse dès que le catalogue grossit, alors que la même page reste rapide en environnement de test avec peu de données.

Enfin, certains modules de recommandation, de tracking marketing ou de génération de PDF exécutent du code lourd sur chaque affichage de page, y compris quand la fonctionnalité n’est pas utilisée à ce moment-là. Je les identifie via le débogueur de hooks et je propose soit une désactivation conditionnelle, soit un passage en tâche asynchrone.

Pages liées

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.

Qu’est-ce qui est lent exactement ?
Le cache PrestaShop est-il activé ?

Réglages > Performances : un cache désactivé ou mal configuré explique une grande partie des lenteurs constatées.

Combien de références au catalogue, environ ?
Quel type d’hébergement utilisez-vous ? (facultatif)
Avez-vous déjà une mesure chiffrée ? (facultatif)

PageSpeed Insights, GTmetrix, ou simplement un temps ressenti — les deux sont utiles.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

Faut-il changer d’hébergeur pour résoudre la lenteur ?
Pas systématiquement. Je commence par mesurer où le temps est réellement perdu : souvent la cause est dans le code ou la base, pas dans la puissance du serveur.
L’audit de performance va-t-il ralentir ou risquer la boutique en ligne ?
Non, le profilage se fait sans interrompre le site. Les modifications de correction sont testées avant d’être appliquées en production, et je peux intervenir hors heures de forte affluence si besoin.
Quels accès dois-je vous fournir ?
Un accès FTP ou SSH, un accès à la base de données, et si possible un accès à l’espace d’administration de l’hébergement pour vérifier la configuration PHP et le cache disponible.
Combien de temps prend un audit de performance ?
Le diagnostic prend en général une demi-journée à une journée. Les corrections varient ensuite selon leur nature : un ajout d’index se fait en quelques minutes, une refonte de module mal optimisé prend plus de temps.
Est-ce que ça va améliorer mon référencement ?
La vitesse de chargement fait partie des critères pris en compte par Google (Core Web Vitals), donc oui, indirectement, mais ce n’est pas une garantie de meilleur classement à elle seule.
Pourquoi mon site PrestaShop est-il devenu lent du jour au lendemain ?
Une lenteur brutale a presque toujours une cause datée : mode debug resté actif après une intervention, module installé ou mis à jour, version de PHP changée par l’hébergeur, table de statistiques qui a franchi un seuil, ou afflux de robots. Rapprochez la date du ralentissement des dernières interventions et des journaux d’accès avant de toucher au serveur.

Pages liées