PrestaShop lent ? 7 causes qui ralentissent votre boutique (et les corriger)

PrestaShop est un CMS e-commerce costaud et gourmand en ressources. Aussi un CMS e-commerce des plus exigeants en matière de maintenance.

Quand il est bien configuré, il tient la route. Quand il est laissé à lui-même, les performances se dégradent petit à petit. Au début c'est imperceptible. Puis un jour vous ouvrez votre back-office et chaque clic met trois secondes à répondre. Vos fiches produits chargent au ralenti. Google vous a fait passer de la page 1 à la page 3.

Un site lent, ce n'est pas qu'une question de confort. C'est du chiffre d'affaires perdu.

Voici ce que j'ai constaté sur les boutiques que j'ai auditées, et ce qui revient le plus souvent.

Ensuite, nous verrons un cas client pour une boutique PrestaShop 1.6 à migrer en PrestaShop 9 et non PrestaShop 1.9 comme j'ai pu le lire sur certains posts sur les réseaux sociaux. 

Commençons par les fondamentaux des performances PrestaShop

Le cache Smarty qui recompile en permanence

À noter avant de commencer : si votre boutique tourne encore sous PrestaShop 1.6 ou 1.7, la question du cache Smarty n'est qu'un élément parmi d'autres. Ces versions sont aujourd'hui obsolètes et ne bénéficient plus du même niveau de maintenance que les versions récentes. PrestaShop 1.6 a atteint sa fin de vie officielle en juin 2019 et PrestaShop 1.7 n'est désormais plus maintenu. Une boutique e-commerce exposée à Internet ne devrait donc plus rester durablement sur ces versions, notamment pour des raisons de sécurité et de compatibilité avec les versions modernes de PHP et des bibliothèques utilisées par l'écosystème.

PrestaShop utilise Smarty pour le rendu d'une partie des templates du front-office. Le principe est simple : les fichiers .tpl sont compilés afin d'éviter de refaire inutilement ce travail à chaque chargement de page.

En production, la compilation forcée des templates ne doit pas être activée. La documentation officielle de PrestaShop indique que $smarty->force_compile doit rester à false en production. Lorsqu'elle est forcée, Smarty recompilera les templates au lieu de réutiliser efficacement ceux déjà compilés, ce qui augmente inutilement le travail effectué par le serveur.

C'est un réglage que l'on retrouve régulièrement après une phase de développement. Pendant la modification d'un thème ou d'un module, le développeur peut volontairement activer la compilation forcée afin de voir immédiatement ses changements. C'est parfaitement normal sur un environnement de développement.

Le problème apparaît lorsque ce réglage reste actif sur la boutique de production.

PrestaShop recommande au contraire, en production, de ne recompiler les templates que lorsque les fichiers concernés ont été modifiés. Le cache Smarty doit également rester correctement configuré.

C'est une différence importante entre un environnement de développement et une boutique réellement exploitée :

Développement : on peut forcer la compilation et désactiver le cache pour voir immédiatement les modifications.

Production : on évite la compilation forcée et on conserve le mécanisme de cache afin que les templates déjà compilés puissent être réutilisés.

PrestaShop documente d'ailleurs explicitement ce fonctionnement sur les versions 1.7, 8 et 9. Le principe n'a donc pas changé fondamentalement avec les nouvelles versions.

Comment vérifier le réglage ?

Dans le back-office, rendez-vous dans Paramètres avancés → Performances, puis vérifiez les paramètres liés à Smarty.

En production, la compilation forcée doit être désactivée. Le mode debug doit également rester désactivé. PrestaShop précise que le mode debug entraîne une pénalité importante sur les performances et doit être utilisé uniquement pendant les phases de développement ou de diagnostic.

Après une modification d'un fichier .tpl, le cache Smarty peut devoir être vidé afin que PrestaShop prenne en compte la nouvelle version du template. Les fichiers compilés sont notamment stockés dans /var/cache/<ENV>/smarty/compile.

Enfin, il ne faut pas s'arrêter à ce seul réglage. Un cache Smarty correctement configuré n'empêchera pas un module mal développé, un thème trop lourd ou une mauvaise utilisation des mécanismes de cache de ralentir la boutique. La documentation PrestaShop recommande notamment de profiler les modules qui s'exécutent sur les pages importantes du front-office et de rechercher les consommations excessives de ressources, l'absence de cache ou, à l'inverse, une sur-utilisation du cache.

La combinaison CSS/JS désactivée

PrestaShop dispose depuis longtemps de mécanismes permettant de combiner, compresser et mettre en cache les fichiers CSS et JavaScript.

Sur les anciennes versions, notamment PrestaShop 1.6 et 1.7, ces réglages faisaient partie des optimisations classiques du menu Paramètres avancés → Performances. La documentation PrestaShop 1.6 indiquait notamment que le Smart Cache CSS pouvait être utilisé pour combiner et compresser les feuilles de style, tandis que la combinaison JavaScript nécessitait davantage de prudence en raison des problèmes de compatibilité possibles.

La raison est simple : le JavaScript est beaucoup plus sensible à l'ordre et au mode de chargement des fichiers. Un module peut attendre qu'une bibliothèque soit chargée avant son propre script, dépendre d'un ordre précis ou utiliser du code qui supporte mal la combinaison et la compression.

C'est d'ailleurs un problème que l'on retrouve régulièrement dans les retours des utilisateurs et développeurs PrestaShop. Sur le forum officiel, plusieurs intervenants recommandent d'activer les optimisations CSS/JS puis de tester soigneusement le front-office. Des problèmes de JavaScript liés à des modules ont également conduit à désactiver temporairement le Smart Cache JavaScript pour isoler la cause d'un dysfonctionnement. Documentation PrestaShop

Le scénario classique est donc le suivant : un module provoque un problème lorsque l'optimisation JavaScript est activée. Le développeur désactive alors le Smart Cache ou la combinaison des fichiers pour rétablir le fonctionnement de la boutique. La correction temporaire devient ensuite la configuration permanente.

Le problème n'est pas nécessairement la désactivation elle-même. Le problème est de ne jamais revenir chercher la cause du dysfonctionnement.

PrestaShop 8 et 9 : il faut raisonner autrement

Sur PrestaShop 8, la logique de compilation des assets est déjà plus moderne. Le thème Classic utilise notamment Webpack pour compiler ses fichiers CSS et JavaScript, et la documentation recommande de compiler les ressources du thème en fichiers optimisés pour la production.

PrestaShop 9 va encore plus loin avec son système de gestion des assets. Les thèmes et les modules peuvent enregistrer leurs propres feuilles de style et scripts, définir leur priorité, leur emplacement et, pour JavaScript, utiliser notamment async ou defer. Les assets peuvent également être associés à des pages spécifiques plutôt que chargés systématiquement partout.

Cela change légèrement la manière d'aborder l'optimisation.

Le nombre de fichiers n'est plus le seul indicateur à regarder. Avec les navigateurs et protocoles modernes, notamment HTTP/2 et HTTP/3, réduire mécaniquement le nombre de requêtes n'est plus une règle absolue.

Un fichier JavaScript unique de plusieurs centaines de kilo-octets chargé sur toutes les pages peut par exemple être plus problématique qu'une série de fichiers plus petits chargés uniquement lorsqu'ils sont nécessaires.

L'objectif est donc de réduire le travail réellement demandé au navigateur, et pas simplement de faire disparaître des lignes dans l'onglet Network.

Ce qu'il faut vérifier

Lors d'un audit PrestaShop, il faut notamment regarder :

• si les mécanismes de cache et de minification sont correctement configurés ;

• combien de fichiers CSS et JavaScript sont réellement chargés sur chaque type de page ;

• quels modules ajoutent ces ressources ;

• si des scripts sont chargés sur des pages où ils ne servent à rien ;

• si certains fichiers sont inutilement volumineux ;

• si le JavaScript bloque le rendu ou peut être chargé avec defer ou async lorsque c'est techniquement approprié ;

• si une ancienne désactivation du CCC provient d'un problème de compatibilité toujours présent ;

• et surtout si un module ou le thème est responsable d'une surcharge inutile.

Sur PrestaShop 9, la documentation permet précisément de gérer ces ressources au niveau du thème et des modules : un asset peut être enregistré uniquement pour une page donnée, déplacé en bas de page, chargé avec defer, ou retiré lorsqu'il n'est pas nécessaire.

Enfin, ne cochez pas aveuglément toutes les options de performance. PrestaShop recommande de mesurer les performances avant et après chaque modification : benchmark, modification, nouveau benchmark.

La bonne démarche consiste donc à mesurer la situation réelle, identifier les assets inutiles ou problématiques, corriger les modules concernés et vérifier le résultat sur les principales pages de la boutique.

Une optimisation CSS/JS efficace n'est pas une case cochée dans le back-office. C'est un résultat mesuré.

Les modules peuvent plomber les performances

C'est l'un des problèmes que l'on retrouve le plus souvent sur les boutiques PrestaShop qui ont plusieurs années et qui ont accumulé les développements.

Le problème n'est pas le nombre de modules en lui-même. C'est ce que chaque module fait, où il intervient et à quelle fréquence.

Un module PrestaShop peut s'accrocher à différents hooks du système et exécuter son propre code lorsqu'un de ces hooks est déclenché. Il peut alors générer du HTML, charger des fichiers CSS ou JavaScript, effectuer des traitements PHP, interroger la base de données ou communiquer avec un service externe. Les hooks constituent justement l'un des principaux mécanismes permettant aux modules d'intervenir dans le fonctionnement de PrestaShop.

Le problème apparaît lorsqu'un module intervient sur trop de pages, ou lorsqu'il effectue un traitement coûteux à chaque appel.

La documentation officielle de PrestaShop cite elle-même les modules accrochés à trop de pages parmi les causes potentielles de ralentissement. Elle recommande notamment de rechercher les modules qui consomment beaucoup de ressources, qui utilisent mal le cache ou qui sont activés sur un nombre excessif de pages.

Prenez un exemple simple.

Un module de livraison n'a aucune raison de charger un gros fichier JavaScript sur la page d'accueil si ce script n'est nécessaire que pendant le tunnel de commande.

Même chose pour un module de paiement : ses traitements les plus spécifiques devraient être déclenchés lorsque cela est nécessaire, et non multiplier inutilement les traitements sur les fiches produits ou les pages de contenu.

Avec cinq modules, le problème peut passer inaperçu.

Avec vingt, trente ou cinquante modules accumulés au fil des années, le cumul peut devenir beaucoup plus difficile à maîtriser. Et deux modules apparemment légers peuvent également devenir coûteux lorsqu'ils interviennent tous les deux sur les mêmes hooks ou effectuent plusieurs traitements sur une même requête.

Le nombre de modules ne suffit donc pas pour diagnostiquer un ralentissement

Une boutique équipée de 30 modules peut être parfaitement performante.

À l'inverse, un seul module mal conçu peut provoquer une dégradation importante s'il effectue trop de requêtes SQL, réalise un traitement coûteux, utilise mal le cache, charge des ressources inutilement ou appelle un service externe à chaque requête.

C'est pour cette raison que PrestaShop recommande de mesurer et profiler les modules, plutôt que de simplement compter leur nombre. Le principe recommandé est toujours le même : mesurer la situation, modifier un élément, puis mesurer à nouveau.

Que faut-il auditer ?

Lors d'un audit, il faut notamment identifier :

• les modules réellement utilisés par la boutique ;

• les modules installés mais devenus inutiles ;

• les modules branchés sur un grand nombre de hooks ;

• les modules chargés sur des pages où leur fonctionnalité n'est pas nécessaire ;

• les requêtes SQL particulièrement coûteuses ;

• les traitements PHP qui consomment beaucoup de temps ;

• les fichiers CSS et JavaScript injectés par les modules ;

• les modules qui utilisent mal le cache ;

• les appels vers des API ou services externes ;

• et les modules qui font doublon avec une fonctionnalité déjà assurée par le thème, PrestaShop ou un autre module.

Sur les versions modernes de PrestaShop, il est également possible de gérer plus précisément les modules attachés aux hooks. PrestaShop 9 permet notamment au thème de définir des modules_to_unhook afin de retirer certains modules de certains emplacements lorsque leur présence n'est pas nécessaire.

Il ne faut donc pas chercher à supprimer des modules au hasard.

L'objectif est d'identifier ceux qui apportent une réelle valeur commerciale ou fonctionnelle, puis de mesurer leur coût technique. Un module indispensable mais lourd doit être optimisé ou remplacé. Un module inutile doit être supprimé. Et lorsqu'un module n'est nécessaire que sur certaines pages, son chargement doit être limité autant que possible à ces pages.

C'est cette approche qui permet de trouver les véritables goulots d'étranglement d'une boutique PrestaShop, plutôt que de simplement dire : « vous avez trop de modules ».

Avant de désactiver un module à l'aveugle, mieux vaut savoir lesquels sont réellement utiles : notre sélection des modules PrestaShop indispensables en 2026 aide à faire le tri.

La base de données s'encrasse

Une boutique PrestaShop qui fonctionne depuis plusieurs années accumule naturellement des données.

Certaines sont indispensables au fonctionnement de la boutique. D'autres deviennent progressivement obsolètes : anciens logs, connexions historiques, visiteurs anonymes, données laissées par certains modules après leur désinstallation, anciennes entrées de configuration, etc.

La documentation officielle de PrestaShop reconnaît explicitement ce phénomène. Elle indique que certaines tables peuvent devenir très volumineuses avec le temps et recommande notamment de nettoyer régulièrement les anciennes données des tables de logs, de connexions et de visiteurs.

Le cas de la table de configuration mérite également une attention particulière. Au fil des installations et désinstallations de modules, elle peut accumuler de nombreuses entrées. PrestaShop précise que son contenu est chargé lors de chaque requête et qu'une table configuration devenue trop volumineuse peut donc avoir un impact sur les performances.

Le problème n'est pas simplement « une grosse base »

Une base de données volumineuse n'est pas nécessairement une base de données lente.

Une boutique disposant de plusieurs dizaines de milliers de produits peut parfaitement fonctionner correctement si les requêtes sont efficaces, les index adaptés, le serveur correctement dimensionné et les données correctement mises en cache.

À l'inverse, une boutique beaucoup plus petite peut rencontrer des ralentissements importants si un module exécute des requêtes coûteuses, si certaines requêtes ne peuvent pas utiliser correctement les index ou si MySQL manque de ressources.

C'est particulièrement important sur les catalogues complexes : nombreuses déclinaisons, prix spécifiques, règles de catalogue, multiboutique ou modules qui ajoutent leurs propres tables et requêtes. Dans ces situations, ce n'est pas simplement le volume de données qui compte, mais la manière dont PrestaShop et ses modules interrogent cette base.

Les index doivent être vérifiés, pas ajoutés au hasard

Lorsqu'une requête devient lente, l'une des vérifications consiste à analyser son plan d'exécution et à déterminer si les index existants sont réellement utilisés.

Ajouter des index supplémentaires sans analyser les requêtes n'est pas une optimisation en soi. Les index accélèrent certaines lectures, mais ils occupent également de l'espace et peuvent augmenter le coût des opérations d'écriture.

La bonne démarche consiste donc à identifier les requêtes réellement lentes, à les analyser puis à déterminer si le problème vient d'un index absent, d'une requête mal conçue, d'un volume de données devenu important ou d'un autre élément de l'infrastructure.

PrestaShop recommande d'ailleurs une approche basée sur la mesure : benchmark, modification, nouveau benchmark.

Et le cache Redis ou Memcached ?

Le cache peut effectivement réduire la charge exercée sur la base de données, mais il ne remplace pas son nettoyage ni l'optimisation des requêtes.

PrestaShop documente l'utilisation de mécanismes de cache comme APCu ou Memcached dans certaines configurations et recommande également de dimensionner correctement la mémoire disponible pour MySQL/MariaDB, notamment le buffer pool InnoDB.

Il faut donc distinguer deux problèmes :

Une base mal entretenue doit être nettoyée.

Une base trop sollicitée doit être analysée et éventuellement soulagée par du cache, une optimisation des requêtes, un meilleur dimensionnement de MySQL/MariaDB ou une architecture adaptée.

Que faut-il vérifier ?

Lors d'un audit PrestaShop, je vérifie notamment :

• la taille des principales tables ;

• l'évolution des tables de logs et de connexions ;

• les anciennes données laissées par les modules ;

• la taille et le contenu de la table configuration ;

• les requêtes SQL lentes ;

• les index utilisés par les requêtes importantes ;

• le plan d'exécution des requêtes problématiques ;

• la configuration mémoire de MySQL/MariaDB ;

• le buffer pool InnoDB ;

• et l'utilisation éventuelle d'un système de cache adapté à l'architecture de la boutique.

Une base de données PrestaShop ne doit donc pas être nettoyée « au hasard ». On identifie d'abord ce qui grossit, ce qui est réellement obsolète et ce qui pénalise les requêtes, puis on intervient avec une sauvegarde et des mesures avant/après.

Des images trop lourdes

Sur une boutique, les images pèsent souvent plus que tout le reste de la page. Le scénario classique : des photos envoyées telles qu'elles sortent de l'appareil, à 3 000 ou 4 000 pixels de large, puis affichées en vignette de 300 pixels sur la page catégorie. Le navigateur télécharge l'image entière pour n'en montrer qu'une fraction.

PrestaShop génère pourtant ses propres miniatures, une par type d'image défini dans les paramètres des images du back-office. Encore faut-il que ces types correspondent aux tailles réellement affichées par le thème, et que les miniatures aient été régénérées après un changement de thème. Selon la version, PrestaShop sait aussi produire des formats plus légers comme le WebP ou l'AVIF ; sur une version ancienne, c'est un module ou une conversion côté serveur qui s'en charge.

Ce qu'il faut vérifier

• la taille des images d'origine envoyées dans le catalogue ;
• la correspondance entre les types d'images et les emplacements du thème ;
• la régénération des miniatures après tout changement de thème ;
• le chargement différé (lazy loading) des images situées sous la ligne de flottaison ;
• le format servi : JPEG ou PNG partout, ou un format moderne quand le navigateur l'accepte.

Un hébergement sous-dimensionné ou une version de PHP dépassée

Toutes les optimisations du monde ne rattrapent pas un serveur qui met une seconde à répondre avant même d'envoyer la page. Sur un hébergement mutualisé chargé, PrestaShop partage le processeur, la mémoire et la base de données avec d'autres sites : aux heures de pointe, le temps de réponse s'envole, et la boutique ralentit au moment où elle reçoit le plus de visiteurs.

La version de PHP compte autant. Une boutique PrestaShop 1.6 tourne souvent encore sous PHP 7.0 ou 7.1, des versions qui ne reçoivent plus aucun correctif depuis des années : elles sont plus lentes que les versions actuelles, et elles posent un vrai problème de sécurité. Vérifiez aussi que le cache d'opcodes (OPcache) est activé : sans lui, PHP recompile le code à chaque requête.

Ce qu'il faut vérifier

• le temps de réponse du serveur (TTFB) sur une page catégorie, mesuré plusieurs fois dans la journée ;
• la version de PHP active pour le domaine, et sa compatibilité avec votre version de PrestaShop ;
• l'activation d'OPcache et la mémoire allouée à PHP ;
• les limites de l'offre d'hébergement (processus PHP simultanés, connexions à la base).

C'est l'un des points sur lesquels j'interviens le plus souvent. Nous hébergeons les boutiques de nos clients sur des serveurs gérés en France, avec une version de PHP à jour : l'hébergement est inclus dès la formule Sérénité de la maintenance PrestaShop (249 € HT/mois), et avec la formule Essentiel (149 € HT/mois), un serveur géré s'ajoute dès 39 € HT/mois.

Un thème trop lourd

Les thèmes achetés sur les places de marché sont conçus pour impressionner sur une démo : diaporamas, méga-menus, blocs animés, dizaines de polices et d'icônes. Chaque fonction ajoute ses fichiers CSS et JavaScript, souvent chargés sur toutes les pages, même là où elle ne sert pas. Beaucoup de ces thèmes s'accompagnent en plus de leurs propres modules, qui se greffent sur les hooks de la page d'accueil, des catégories et des fiches produits.

Le résultat se voit dans PageSpeed Insights : beaucoup de ressources bloquantes, un JavaScript volumineux et un LCP qui dépasse largement les 2,5 secondes recommandées par Google.

Ce qu'il faut vérifier

• le nombre de fichiers CSS et JavaScript chargés sur une fiche produit ;
• les modules livrés avec le thème, et ceux qui servent réellement ;
• les diaporamas et animations de la page d'accueil ;
• les polices et bibliothèques d'icônes chargées en entier pour quelques caractères.

Quand le thème est trop lourd pour être allégé, le remplacer coûte souvent moins cher que de le corriger : c'est d'ailleurs l'occasion qu'offre une migration.

Quand la version freine tout : la migration vers PrestaShop 9

Beaucoup de boutiques que j'audite tournent encore sous PrestaShop 1.6 ou 1.7, avec des années de modules, de personnalisations et un thème devenu difficile à maintenir. Au-delà de la vitesse, ces versions imposent des contraintes de PHP, de modules et de sécurité : PrestaShop 9.0 demande au minimum PHP 8.1 et prend en charge les versions 8.2 à 8.4, PrestaShop 9.1 ajoute PHP 8.5, et le cœur passe de Symfony 4.4 à Symfony 6.4.

La migration n'est pas un bouton magique pour autant. Une boutique ne devient pas rapide parce qu'elle passe en version 9 : le gain dépend du thème, des modules, des requêtes SQL, du cache, des images et du serveur. Ce qui change vraiment, c'est la remise à plat que la migration oblige à faire : modules abandonnés retirés, overrides anciens relus, scripts inutiles supprimés.

• Depuis PrestaShop 1.6 : c'est une reconstruction technique autour des données existantes. Le thème n'est pas compatible et doit être refait, les modules et les développements spécifiques sont à reprendre un par un.
• Depuis PrestaShop 1.7 : le saut est moins radical, car Symfony et Composer sont déjà dans le cœur, mais le changement de PHP et le tri des modules restent un vrai chantier.
• Depuis PrestaShop 8 : une boutique bien entretenue ne gagnera pas forcément beaucoup en vitesse. La migration sert surtout à rester sur un socle à jour.

Le détail de chaque cas, le coût et la méthode sont dans le guide de migration de PrestaShop 1.6 et 1.7 vers PrestaShop 9 et dans les nouveautés de PrestaShop 9.

Cas client : une boutique de chaussures à Bailleul

Voici le cas d'une boutique de chaussures de Bailleul, dans les Flandres, dont la migration de PrestaShop 1.6 vers PrestaShop 9 est en préparation. C'est un exemple typique de boutique qui a bien vendu pendant des années et que le temps a alourdie. Les chiffres viennent de l'audit technique de la base de données et du serveur, réalisé en septembre 2026.

Le point de départ

• PrestaShop 1.6 sous PHP 7.0, une version de PHP qui ne reçoit plus de correctifs depuis 2019 ;
• un score mobile PageSpeed Insights de 14/100 ;
• 5 246 fiches produits, 11 427 déclinaisons de pointures et de couleurs, environ 40 000 images ;
• 154 modules actifs, dont trois systèmes de recherche superposés et trois ou quatre modules pour afficher les marques ;
• 126 fichiers de surcharge (overrides) du cœur de PrestaShop, dont 79 liés à un seul module de recherche tiers ;
• des tables techniques très chargées : plus d'un million de lignes dans l'index de recherche, 426 300 visiteurs anonymes enregistrés, 113 846 paniers et 89 008 journaux d'envoi d'e-mails.

Ce que ça explique

On retrouve presque toutes les causes de cet article au même endroit : une version de PHP dépassée, des modules qui font doublon et se greffent chacun sur les mêmes pages, une base de données encombrée de données techniques jamais purgées, et un thème avec ses propres modules (dix-sept dans ce cas). Aucune de ces causes ne suffirait seule à expliquer un score de 14/100. Ensemble, si.

Le plan prévu

Le projet repart d'un thème neuf, ce qui fera disparaître d'un coup les dix-sept modules du thème actuel. Les redondances seront tranchées (un seul moteur de recherche, la recherche à facettes native de PrestaShop 9), les modules tiers utiles portés un par un, et les quelque 2 270 lignes de code des overrides réellement actifs relues avant d'être reproduites ou abandonnées. Les tables techniques ne seront pas migrées : elles se reconstituent d'elles-mêmes. L'objectif fixé est un score mobile supérieur à 85/100 à la mise en ligne.

Mesurer avant d'agir

Chaque boutique PrestaShop est différente. Une optimisation qui produit un gain important sur une installation peut n'avoir pratiquement aucun effet sur une autre.

La première règle d'une optimisation sérieuse est donc simple : mesurer avant de modifier.

La documentation officielle de PrestaShop recommande elle-même cette méthode : établir une référence, effectuer une modification, puis mesurer à nouveau. Sans benchmark initial, il est impossible de savoir avec certitude si une intervention a réellement amélioré les performances ou si elle a déplacé le problème ailleurs.

Quels outils utiliser pour mesurer les performances PrestaShop ?

Pour le Front Office, plusieurs outils sont complémentaires.

PageSpeed Insights permet d'obtenir à la fois des données de laboratoire issues de Lighthouse et, lorsqu'elles sont disponibles, des données réelles provenant du Chrome UX Report. Cette distinction est essentielle : un test Lighthouse est réalisé dans des conditions simulées, tandis que les données CrUX reflètent l'expérience réelle d'utilisateurs sur les 28 derniers jours.

Lighthouse permet d'identifier les problèmes liés au chargement, au JavaScript, aux ressources bloquantes, aux images et à différents aspects de l'expérience utilisateur.

GTmetrix apporte une lecture particulièrement intéressante avec son Waterfall : chaque requête peut être analysée individuellement afin d'identifier les ressources qui retardent le chargement, les scripts tiers, les fichiers trop lourds ou les temps d'attente serveur.

WebPageTest permet d'aller encore plus loin dans les scénarios de test, notamment en faisant varier le navigateur, le terminal, la localisation et les conditions réseau.

Mais ces outils ne doivent pas être utilisés uniquement pour obtenir un score.

Un 95/100 sur PageSpeed Insights ne signifie pas qu'une boutique est parfaitement optimisée. À l'inverse, un score inférieur à 90 ne signifie pas nécessairement qu'il faut chercher à atteindre 100 à tout prix.

Le véritable objectif est d'identifier le goulot d'étranglement.

Est-ce le serveur qui répond trop lentement ?

Est-ce le PHP qui passe trop de temps à générer la page ?

Est-ce une requête SQL trop coûteuse ?

Est-ce un module qui ajoute des traitements inutiles ?

Est-ce le JavaScript qui monopolise le thread principal ?

Est-ce une image LCP trop lourde ?

Est-ce une police ou un script tiers qui bloque le rendu ?

Est-ce simplement une page beaucoup trop lourde ?

La documentation PrestaShop rappelle d'ailleurs qu'un problème de performance peut provenir de très nombreux endroits : CPU, mémoire, stockage, réseau, configuration serveur ou application. L'objectif est d'identifier le goulot d'étranglement actuel, de le traiter, puis de rechercher le suivant.

Les métriques à suivre sur PrestaShop

Pour une boutique e-commerce, je ne me limite jamais au score PageSpeed.

Les Core Web Vitals constituent une référence beaucoup plus intéressante pour mesurer l'expérience réelle :

• LCP (Largest Contentful Paint) : vitesse d'affichage du contenu principal ;

• INP (Interaction to Next Paint) : réactivité de la page aux interactions ;

• CLS (Cumulative Layout Shift) : stabilité visuelle pendant le chargement.

Google recommande actuellement un LCP inférieur ou égal à 2,5 secondes, un INP inférieur à 200 ms et un CLS inférieur à 0,1 pour une bonne expérience utilisateur.

Mais pour une boutique PrestaShop, il faut également regarder les indicateurs techniques qui permettent d'expliquer ces résultats :

• TTFB ;

• temps de génération PHP ;

• nombre et poids des requêtes ;

• poids total de la page ;

• quantité de JavaScript exécutée ;

• ressources bloquantes ;

• requêtes SQL lentes ;

• utilisation CPU et mémoire ;

• temps de réponse du serveur ;

• taux de cache ;

• performances du back-office.

Le benchmark doit également être reproductible. Une mesure prise une seule fois n'est pas suffisante pour conclure qu'une optimisation fonctionne. La charge serveur, le réseau, le cache et les conditions de test peuvent faire varier considérablement les résultats.

C'est particulièrement important avec les outils de laboratoire : Google rappelle que les données Lighthouse et les données réelles CrUX peuvent différer précisément parce qu'elles ne mesurent pas la même chose.

Comment mesurer un gain de performance réel ?

Une optimisation sérieuse ne consiste pas à modifier dix paramètres simultanément puis à regarder si le score a augmenté.

La méthode est beaucoup plus simple :

1. Mesurer l'état initial.

Prenez plusieurs pages représentatives : accueil, catégorie, fiche produit, panier et éventuellement une page CMS. Mesurez-les sur plusieurs exécutions et notez les résultats.

2. Identifier le goulot d'étranglement.

Le problème peut être côté serveur, PHP, SQL, module, thème, JavaScript, images ou infrastructure.

3. Modifier un élément ou un groupe cohérent d'éléments.

Par exemple : corriger un module particulièrement coûteux, optimiser une requête SQL ou revoir le chargement des ressources du thème.

4. Mesurer à nouveau.

Comparez les mêmes URLs, avec les mêmes conditions de test autant que possible.

5. Vérifier qu'aucune régression n'est apparue.

Une amélioration du LCP qui dégrade l'INP, augmente le TTFB ou casse le tunnel de commande n'est pas une optimisation réussie.

Cette approche correspond directement à la méthodologie recommandée par PrestaShop : benchmark, modification, nouveau benchmark.

Ce qu'on gagne réellement à optimiser une boutique PrestaShop

Les gains dépendent entièrement du point de départ.

Une boutique qui souffre d'un mauvais cache, d'un module très lourd, d'un serveur sous-dimensionné ou d'un JavaScript excessif peut présenter des marges d'amélioration importantes. À l'inverse, une boutique déjà correctement configurée peut nécessiter beaucoup de travail pour gagner quelques centaines de millisecondes.

Il faut donc éviter les promesses universelles du type « diviser le temps de chargement par deux » ou « atteindre 100/100 sur PageSpeed ».

Le bon indicateur est l'amélioration mesurée sur la boutique concernée.

Cela peut être un TTFB qui passe de plusieurs secondes à quelques centaines de millisecondes, un LCP qui revient sous le seuil recommandé, une baisse du temps d'exécution JavaScript, une réduction du poids des pages ou simplement un back-office qui retrouve un temps de réponse normal.

Les outils de performance permettent justement de quantifier ces évolutions. GTmetrix montre par exemple le détail des requêtes dans son Waterfall et permet de conserver un historique des mesures afin de suivre l'évolution d'une page dans le temps.

Dans un contexte professionnel, c'est cette comparaison avant/après qui permet de distinguer une véritable optimisation d'une simple amélioration d'un score de laboratoire.

Performance PrestaShop et taux de conversion

Une boutique plus rapide peut également améliorer l'expérience utilisateur et limiter les abandons liés à des temps d'attente trop importants, notamment sur mobile.

Mais là encore, il faut mesurer plutôt que l'affirmer systématiquement.

Le taux de conversion dépend de nombreux facteurs : prix, offre commerciale, confiance, UX, disponibilité des produits, moyens de paiement, livraison, trafic et qualité des visiteurs. Une amélioration technique ne permet donc pas, à elle seule, de garantir une hausse du taux de conversion.

La bonne méthode consiste à suivre simultanément les performances techniques et les indicateurs business : taux d'ajout au panier, début de checkout, commandes, chiffre d'affaires par session et taux de conversion.

Si une optimisation importante est réalisée, les données Analytics permettent ensuite de vérifier si l'amélioration technique s'accompagne effectivement d'une évolution du comportement des utilisateurs.

Quel impact de la performance sur le SEO ?

La performance a également une dimension SEO, mais il faut éviter une autre simplification : un bon score Core Web Vitals ne garantit pas de meilleures positions dans Google.

Google confirme que les Core Web Vitals sont utilisés par ses systèmes de classement et recommande d'obtenir de bonnes valeurs pour offrir une bonne expérience utilisateur. Mais Google précise également que ces métriques ne constituent pas un signal unique et qu'un bon résultat dans Search Console ou dans un outil tiers ne garantit pas une position élevée dans les résultats.

La performance doit donc être considérée comme une composante du SEO technique et de l'expérience utilisateur, pas comme un bouton permettant de gagner automatiquement des positions.

C'est particulièrement important pour une boutique e-commerce : améliorer le serveur, le chargement des images, le JavaScript et les Core Web Vitals peut résoudre de véritables problèmes d'expérience, mais cela ne remplace ni un contenu pertinent, ni une architecture SEO correcte, ni un maillage interne efficace, ni la qualité des pages produits.

Google indique d'ailleurs que lorsque plusieurs pages présentent des contenus similaires, une bonne expérience de page peut devenir plus importante pour leur visibilité.

La performance PrestaShop ne s'arrête jamais

Une boutique optimisée aujourd'hui peut ne plus l'être dans six mois.

Un nouveau module peut ajouter des scripts sur toutes les pages. Une mise à jour peut modifier le comportement d'un thème. Le catalogue peut passer de 500 à 5 000 produits. Une nouvelle fonctionnalité peut multiplier les requêtes SQL. Le trafic peut augmenter jusqu'à atteindre les limites du serveur.

La performance est donc un processus continu.

PrestaShop fournit lui-même des outils et des méthodologies de benchmark pour mesurer le Front Office et le Back Office. Pour les installations importantes, le projet utilise notamment des scénarios reproductibles et des outils de charge afin de comparer les performances dans des conditions contrôlées.

Une maintenance performante ne consiste donc pas uniquement à appliquer les mises à jour.

Elle consiste également à surveiller les temps de réponse, vérifier les ressources serveur, contrôler les modules, surveiller les requêtes SQL, suivre les Core Web Vitals et refaire régulièrement des mesures.

GTmetrix propose par exemple une surveillance programmée avec historique et alertes afin de détecter une dégradation après une modification du site.

La bonne méthode pour optimiser une boutique PrestaShop

Il n'existe pas de liste universelle de cases à cocher pour rendre une boutique PrestaShop rapide.

La méthode fiable est toujours la même :

Mesurer → identifier → corriger → mesurer à nouveau → surveiller.

C'est cette approche qui permet de savoir si le problème vient réellement du cache, d'un module, de la base de données, du thème, du JavaScript, des images, de PHP ou du serveur.

Et surtout, elle évite de dépenser du temps et de l'argent à optimiser ce qui ne constitue pas réellement le goulot d'étranglement.

Une boutique PrestaShop performante n'est pas celle qui affiche simplement un beau score PageSpeed.

C'est celle dont les performances sont mesurées, comprises, optimisées et surveillées dans le temps.

Aller plus loin

Si votre boutique PrestaShop présente des problèmes de performance, le diagnostic doit être réalisé sur l'ensemble de l'installation : serveur, PHP, base de données, cache, modules, thème, CSS, JavaScript et images.

Pour approfondir le sujet, consultez également nos guides consacrés à PrestaShop 9 et à la migration PrestaShop 9.

Si vous utilisez WooCommerce, nous avons également consacré un guide spécifique aux problèmes de performance de WooCommerce afin d'identifier les principales causes de lenteur et les méthodes d'optimisation.

Enfin, si votre boutique est encore sous PrestaShop 1.6 ou 1.7, notre guide sur la migration PrestaShop vers une version récente détaille les principaux points à vérifier avant de lancer le projet : modules, thème, données, URLs, redirections SEO et performances.

Lexique des termes techniques utilisés dans cet article

Vous n'êtes pas développeur ? Ce lexique reprend les principaux termes techniques utilisés dans cet article et les explique simplement.

AVIF

Format d'image moderne permettant de réduire le poids des images tout en conservant une bonne qualité visuelle. Un fichier plus léger peut contribuer à réduire les données à télécharger lors du chargement d'une page.

Back-office

Interface privée de PrestaShop utilisée par le commerçant pour gérer les produits, commandes, clients, modules, paramètres et contenus de la boutique.

Base de données

Espace dans lequel PrestaShop stocke les informations nécessaires au fonctionnement de la boutique : produits, clients, commandes, catégories, configurations, paniers et autres données.

Benchmark

Mesure des performances réalisée dans des conditions définies afin de disposer d'un point de comparaison. En optimisation, on mesure avant une modification puis après afin de vérifier son impact réel.

Cache

Mécanisme permettant de conserver temporairement certaines données ou certains résultats afin d'éviter de refaire les mêmes traitements à chaque demande. Un cache correctement configuré peut réduire le travail demandé au serveur.

Core Web Vitals

Ensemble de trois indicateurs utilisés par Google pour évaluer certains aspects de l'expérience utilisateur : LCP pour l'affichage du contenu principal, INP pour la réactivité et CLS pour la stabilité visuelle.

CLS

Le CLS, ou Cumulative Layout Shift, mesure les déplacements inattendus des éléments pendant le chargement d'une page. Par exemple, si une image apparaît après le texte et fait soudainement descendre celui-ci, cela génère un déplacement de mise en page.

CSS

Langage utilisé pour définir l'apparence d'une page web : couleurs, tailles, espacements, polices, positionnement et mise en page.

Déclinaison

Variante d'un produit. Un tee-shirt disponible en plusieurs tailles et plusieurs couleurs peut par exemple posséder de nombreuses combinaisons de déclinaisons.

Front-office

Partie publique de la boutique PrestaShop, celle que voient les visiteurs : page d'accueil, catégories, fiches produits, panier et tunnel de commande.

GTmetrix

Outil d'analyse des performances d'une page web. Il permet notamment d'observer le chargement des différentes ressources grâce à une représentation de type Waterfall.

Hummingbird

Thème moderne développé par PrestaShop et utilisé comme thème par défaut à partir de PrestaShop 9.1. Il constitue une base plus récente pour le développement du front-office.

Hook

Point d'accroche de PrestaShop permettant à un module d'exécuter du code ou d'afficher un élément à un emplacement précis de la boutique. Un module peut par exemple utiliser un hook pour ajouter un bloc sur une fiche produit.

Index SQL

Structure utilisée par la base de données pour retrouver plus rapidement certaines informations. Un index correctement choisi peut accélérer une requête, mais ajouter des index sans analyse peut également augmenter le coût des écritures et la taille de la base.

INP

L'INP, ou Interaction to Next Paint, mesure la réactivité d'une page lorsqu'un utilisateur interagit avec celle-ci. Il permet notamment d'évaluer le délai entre une action de l'utilisateur et la réaction visible de l'interface.

JavaScript

Langage de programmation exécuté notamment dans le navigateur. Il permet de créer des fonctionnalités interactives comme les menus, filtres, carrousels, formulaires et certaines fonctionnalités dynamiques du panier.

LCP

Le LCP, ou Largest Contentful Paint, mesure le temps nécessaire pour afficher le principal élément de contenu visible dans la page. Il peut notamment s'agir d'une grande image, d'un titre ou d'un bloc principal.

Google considère actuellement qu'un LCP inférieur ou égal à 2,5 secondes correspond au niveau recommandé pour une bonne expérience utilisateur.

Lazy loading

Technique consistant à différer le chargement de certaines ressources jusqu'au moment où elles deviennent nécessaires. Elle est notamment utilisée pour éviter de charger immédiatement des images situées très bas dans une page.

Lighthouse

Outil d'analyse automatisée développé par Google permettant notamment d'évaluer les performances, l'accessibilité et certains aspects techniques d'une page web.

MariaDB

Système de gestion de base de données utilisé par de nombreuses installations PrestaShop. Il permet notamment de stocker et interroger les données de la boutique.

Memcached

Système de cache pouvant conserver certaines données en mémoire afin d'éviter de refaire certains traitements ou accès à la base de données.

Minification

Réduction de la taille des fichiers CSS ou JavaScript en supprimant notamment les espaces, commentaires et caractères inutiles, sans modifier leur fonctionnement.

Module PrestaShop

Extension permettant d'ajouter une fonctionnalité à PrestaShop : paiement, livraison, avis clients, SEO, statistiques, sécurité, marketing ou autre fonctionnalité spécifique.

Un module peut également ajouter des traitements PHP, des requêtes SQL, du CSS ou du JavaScript.

MySQL

Système de gestion de base de données utilisé par PrestaShop pour stocker et manipuler les informations de la boutique.

PageSpeed Insights

Outil de Google permettant d'analyser les performances d'une page. Il peut fournir des données de laboratoire issues de Lighthouse ainsi que, lorsqu'elles sont disponibles, des données provenant d'utilisateurs réels.

PHP

Langage de programmation exécuté côté serveur et utilisé par PrestaShop pour générer les pages et effectuer une grande partie des traitements de la boutique.

Poids de page

Quantité totale de données nécessaires au chargement d'une page : HTML, images, CSS, JavaScript, polices et autres ressources.

Plus une page est lourde, plus elle peut nécessiter de temps et de données pour être chargée, particulièrement sur une connexion mobile lente.

Requête SQL

Instruction envoyée à la base de données pour rechercher, ajouter, modifier ou supprimer des informations.

Une requête mal optimisée peut demander beaucoup de ressources au serveur et ralentir une page ou le back-office.

Redis

Système de stockage de données en mémoire pouvant notamment être utilisé pour certains mécanismes de cache. Il permet de conserver temporairement certaines informations afin de réduire certains accès à la base de données.

Redirection 301

Redirection permanente d'une URL vers une autre. Elle est particulièrement importante lors d'une migration ou d'une refonte afin d'orienter les visiteurs et les moteurs de recherche vers les nouvelles URLs.

Ressource bloquante

Ressource qui doit être chargée ou traitée avant que certaines étapes du rendu de la page puissent continuer. Certains fichiers CSS ou JavaScript peuvent ainsi retarder l'affichage initial.

SEO

Le SEO, ou Search Engine Optimization, désigne l'ensemble des techniques permettant d'améliorer la visibilité naturelle d'un site dans les moteurs de re

Pour aller plus loin : blog officiel PrestaShop · notes de version PrestaShop