Prestashop est lent, 4 points à vérifier et comment les corriger

La lenteur de Prestashop peut venir de plusieurs problèmes qu'il va falloir identifier.

Avant de commencer il faut savoir pourquoi vous pensez que votre Prestashop est lent. En effet, si c'est parce qu'il a un mauvais score sur des outils comme Pagespeed Insights de Google ou comme GTMetrix il faut alors lire notre article sur ce sujet précis: Comprendre et améliorer le score Pagespeed de votre boutique Prestashop . Si au contraire c'est une lenteur générale de la boutique, et même sur le backoffice, alors c'est surement que votre Prestashop a des temps de réponse trop longs, on va parler de TTFB (Time To First Byte) trop lent. Cet article va vous aider à identifier ce problème de TTFB.

Vérifiez les paramètres de la page Performances de Prestashop

La première chose à faire est d'aller dans la configuration des performances de Prestashop dans le menu "Paramètres avancés" puis "Performances". Ensuite vérifiez les grâce à notre article "La bonne configuration pour améliorer les performances de Prestashop ".

Supprimez les modules inutiles

Prestashop est livré avec beaucoup de modules par défaut et certains sont inutiles ou redondants. Par exemple, si vous utilisez Google Analytics vous n'aurez surement pas besoin des nombreux modules de statistiques.

N'hésitez pas à parcourir la liste de vos modules et à vous demander pour chacun d'eux s'il est vraiment nécessaire ou pas.

Faites un profiling

On appelle "profiling" le fait de mesurer plusieurs données au cours de la génération d'une page. Sur Prestashop a va donc pouvoir mesurer le temps passé, la mémoire consommée, les requêtes SQL exécutées, etc. lors de la génération des pages produits, des catégories, de la page d'accueil, etc. mais aussi du côté du backoffice pour l'administration de la boutique. En effet le chargement des pages peut également être lent du côté back-office et il est important de les optimiser pour passer moins de temps à gérer votre boutique (et ne pas péter un câble parce que ça rame!).

Profiling SQL

Je commence avec le profiling SQL, car il s'avère être le plus efficace. En effet, la majorité des ralentissements sont généralement dus à des requêtes SQL mal optimisées. Les lenteurs attribuables au code PHP sont rares, à moins qu'il s'agisse d'un traitement sur une longue liste de fichiers.

Prestashop propose un mode de "profiling" que je vais détailler dans la section suivante. Cependant, ce mode n'est pas entièrement satisfaisant, car il se contente de générer un "dump" de données considérable, directement sur les pages affichées, et ne peut pas être activé pour les requêtes Ajax.

J'ai donc conçu un module qui enregistre toutes les requêtes envoyées au serveur MySQL, les analyse et les organise pour vous fournir un rapport détaillé et mettre en évidence les requêtes suspectes qui méritent votre attention. Je l'ai déjà testé chez plusieurs clients qui souffraient de lenteurs sur leur boutique Prestashop et le module a su trouver immédiatement l'origine de la lenteur.

Le module peut être utilisé en production car son impact est nul sur les visiteurs. En effet, le profiling n'est actif que pour l'administrateur qui l'active.

Cette fonctionnalité est intégrée au module Speed Pack (Page Cache Ultimate + WEBP + Profiler SQL + Nettoyeur de BDD) mais est également disponible en tant que module indépendant : SQL Profiler .

Profiling intégré à Prestashop

Pour activer le profiling, modifiez la constante _PS_DEBUG_PROFILING_ dans le fichier /config/defines.inc.php.

Si la boutique est ouverte aux clients vous pouvez activer l'outils uniquement pour vous en spécifiant votre IP comme ceci:

define('_PS_DEBUG_PROFILING_', $_SERVER['REMOTE_ADDR'] == '37.123.456.789');

Vous pouvez connaitre votre IP sur https://www.whatsmyip.org/

Une fois le profiling activé vous verrez plusieurs tableaux s'afficher sur toutes les pages côté back-office et front-office. Parcourrons ensemble toutes ces données:

• Loading time: c'est le TTFB, s'il est supérieur à 1 seconde (1000ms) alors cela confirme un problème de TTFB long
• Querying time: s'il représente plus de 50% du "Loading time" c'est que vous avez une requête SQL qui est trop lente ou exécutée trop de fois ou bien que votre serveur de base de données n'est pas assez puissant.
• Queries: c'est le nombre de requêtes SQL exécutées, ne soyez pas effrayé, sur Prestashop il est énorme!

Je ne vais pas tout détailler, uniquement les données importantes.

Vous trouverez aussi un tableau avec les colonnes "Time", "Cumulated Time", "Memory Usage" et "Memory Peak Usage" et les lignes suivantes:

• config: cela représente le chargement du CMS Prestashop, si c'est très lent ici alors votre serveur n'est pas assez puissant ou est mal configuré
• _construct: temps passé dans le constructeur du contrôleur
• init: temps passé dans la méthode init() du contrôleur
• checkAccess: temps passé dans la méthode checkAccess() du contrôleur qui permet de contrôler les permissions, normalement à 0 (ou très très court)
• setMedia: temps passé dans la méthode setMedia() du contrôleur qui permet d'ajouter les fichiers CSS ou javascript, normalement très très court
• postProcess: temps passé dans la méthode postProcess() du contrôleur qui permet d'enregistrer les données d'un formulaire. Peut être long en fonction du formulaire et des traitements à effectuer. Doit être à 0 sur une page d'affichage classique comme les produits, les catégories, etc.
• initHeader: temps passé dans la méthode initHeader() du contrôleur. C'est ici que sont récupérées les données à afficher bien que souvent cela soit fait dans le initContent().
• initContent: temps passé dans la méthode initContent() du contrôleur. C'est ici qu'est appelé le hook 'displayHeader' des modules ainsi que le plus gros des traitements qui vont générer le contenu de la page web.
• initFooter: temps passé dans la méthode initFooter() du contrôleur. Souvent vide car peu de contrôleur font des traitements ici.
• display: temps passé dans la méthode display() du contrôleur. C'est le temps mis par Smarty pour faire le rendu de la page, en d'autres termes le temps passé à compiler les templates et peupler les valeurs. Si la durée est longue c'est que vous avez peut-être oublié d'activer le cache de Smarty ou bien qu'il y a vraiment beaucoup d'éléments à afficher. Cela peut également être un module ou un widget qui est très lent dans l'un de ses hooks.

Malheureusement dans PS1.7 il n'y a plus d'informations concernant l'exécution des modules et des hooks, une Pull Request #20673 a été clôturée mais je ne sais pas dans quelle version elle sera mergée. En attendant, si vous avez Page Cache Ultimate vous pouvez retrouver ces données dans l'outils de profiling intégré.

Le tableau "Stopwatch SQL - xxx queries" liste l'ensemble des requêtes SQL exécutées, de la plus lente à la plus rapide. Personnellement je considère qu'une requête qui dépasse 100ms est lente. Cependant si l'ordre de grandeur des durées est le même, c'est à dire qu'une seule requête ne se démarque pas des autres par sa lenteur alors c'est peut-être le serveur MySQL qui n'est pas assez performant.

Profiling fournit par le module Page Cache Ultimate

Notre module Page Cache Ultimate (également intégré au module Speed Pack (Page Cache Ultimate + WEBP + Profiler SQL + Nettoyeur de BDD) ) propose un outils pour mesurer le temps passé par chaque module dans chaque hook. La procédure pour analyser la lenteur d'une page web est la suivante:

1. activez le profiling dans la page de configuration de Page Cache Ultimate
2. videz les données de profiling
3. affichez la page web lente
4. rafraichissez le tableau de données et triez le par "durée", du plus grand au plus petit

Si un module est beaucoup plus lent que les autres c'est probablement lui le coupable, dans ce cas la solution est de contacter le développeur et de lui demander une optimisation de la vitesse de chargement de celui-ci. Si vous voyez plusieurs modules lents il est possible que le problème soit lié à la puissance du serveur Apache ou du serveur de base de données (MySQL ou MariaDb).

Vérifiez la puissance de votre hébergement

Si aucun suspect ou indice ne se dégage du profiling et que la lenteur est généralisée alors votre serveur n'est peut-être pas configuré correctement ou qu'il n'est pas assez puissant.

Version de PHP

Commencez par vérifier si la version de PHP est bonne. Regardez ce tableau pour savoir qu'elle version de PHP vous devriez avoir au minimum en fonction de la version de Prestashop:

Légende: = Version recommandée, Oui = Supporté, Non = Non supporté

Paramètres et extensions PHP

Vous pouvez également utiliser ce script PHP pour vérifier si votre serveur Apache est configuré correctement pour Prestashop. Il va vérifier les paramètres et les extensions essentiels au CMS:

Conclusion

Si après tous ces tests et corrections votre TTFB reste très long, supérieur à 1 seconde, il faut envisager de prendre un pack hébergement plus puissant ou alors installer notre module de cache HTML Page Cache Ultimate .

Dans tous les cas je vous souhaite bon courage et j'espère que vous règlerez vos problèmes de performances sous Prestashop rapidement!