Audit de performance PrestaShop : trouver ce qui ralentit la boutique avant de corriger

Un audit de performance PrestaShop sépare trois temps : celui que la boutique met à construire la page, celui que la page met à arriver, celui que le navigateur met à l’afficher. Il classe les causes par gain attendu et mesure chaque correction avant et après. Faites écrire ces deux éléments avant de le commander.

• Un audit de performance PrestaShop commence par les visites réelles de la Search Console
• Le journal des requêtes lentes de la base nomme les requêtes coupables
• Les interrupteurs du mode de débogage isolent les modules tiers, sur une copie de la boutique
• Le thème et les modules se départagent par comparaison sur une même page
• Les outils d’un audit de performance PrestaShop et le repère documenté de chacun
• Le diagramme en cascade du navigateur désigne les images et les scripts tiers lourds
• Cinq éléments à exiger par écrit dans le livrable d’un audit de performance PrestaShop
• La mesure d’un audit PrestaShop se fausse quand les conditions changent
• Sources consultées
• Foire aux questions

Un audit de performance PrestaShop commence par les visites réelles de la Search Console

Le rapport Core Web Vitals de la Search Console et PageSpeed Insights lisent le rapport d’expérience utilisateur de Chrome (CrUX), qui couvre les 28 derniers jours de visites réelles. Un test de laboratoire se joue dans des conditions uniques : un appareil, un réseau, un cache vide. D’où la consigne de Google sur web.dev : le terrain fixe les priorités, le laboratoire sert à déboguer.

Au 14 octobre 2026, les pages de la documentation développeur consultées pour la version 8 portent un avertissement qui renvoie vers leur équivalent de PrestaShop 9, sur lequel s’appuie cette page. La page d’optimisation de la 9 ouvre sur un principe : prendre une mesure de référence avant de toucher à quoi que ce soit.

Le journal des requêtes lentes de la base nomme les requêtes coupables

Chaque page de la boutique interroge la base de données, où PrestaShop range produits, clients et commandes. Le journal des requêtes lentes les consigne avec leur durée. MySQL le livre désactivé : la variable « slow_query_log » l’active, et « long_query_time » fixe le seuil en secondes. MariaDB renomme ces deux variables « log_slow_query » et « log_slow_query_time » à partir de la version 10.11.

Un outil de synthèse résume ensuite le fichier : « mysqldumpslow » côté MySQL, « mariadb-dumpslow » côté MariaDB. Sur un hébergement dont la configuration de la base appartient à l’hébergeur, l’activation se demande à lui.

Prenons une requête de 0,05 seconde exécutée 60 fois dans une même page de catégorie : elle ajoute 3 secondes, contre 1 seconde pour une requête unique d’une seconde. Pour que le journal montre ce cumul, que la durée d’une requête isolée cache, le seuil doit descendre sous 0,05 seconde ; le manuel prévient que le fichier peut grossir très vite.

La documentation de l’éditeur nomme aussi quatre tables qui grossissent avec le temps : « log », « connections », « guest » et « configuration ». Cette dernière se charge à chaque requête que PrestaShop traite. Demandez à l’hébergeur le nombre de lignes de chacune.

Les interrupteurs du mode de débogage isolent les modules tiers, sur une copie de la boutique

La section « Mode debug » de Paramètres avancés > Performances (« Advanced parameters > Performance » dans la documentation) offre deux interrupteurs d’isolement : « Désactiver les modules non développés par PrestaShop » et « Désactiver toutes les surcharges ». Les surcharges sont des modifications du cœur de PrestaShop apportées de l’extérieur. La documentation les destine au repérage de l’origine d’une erreur. Leur usage pour chronométrer une page est une déduction : la même mesure, répétée avec et sans.

Le mode de débogage ralentit sensiblement la boutique, avertit la documentation développeur. Il montre aussi aux clients les messages d’erreur que les réglages par défaut leur cachent. D’où la règle : copie de la boutique, production exclue. Le profileur, l’outil qui mesure où le code passe son temps et que la constante « _PS_DEBUG_PROFILING_ » du fichier config/defines.inc.php active, suit la même règle.

Décrire mon besoin →

Le thème et les modules se départagent par comparaison sur une même page

Servez la même page avec le thème livré par défaut avec votre version, puis avec le vôtre : l’écart isole le thème. Le même exercice se fait module par module. La documentation d’optimisation liste quatre défauts typiques : un module gourmand en ressources, sans cache, avec un cache excessif, ou branché sur trop de pages. Un module se branche par un « hook », le point d’accroche par lequel il insère son code dans la page.

Paramètres avancés > Informations (« Advanced Parameters > Information » dans la documentation) affiche la liste des fichiers modifiés. Sur une installation neuve, elle ne détecte aucun changement ; ensuite elle recense les écarts avec l’installation d’origine, modules, thèmes et surcharges compris. C’est l’inventaire que l’audit doit passer en revue.

Les outils d’un audit de performance PrestaShop et le repère documenté de chacun

Les seuils des Core Web Vitals et la lecture du rapport relèvent de la mission Core Web Vitals.

Le diagramme en cascade du navigateur désigne les images et les scripts tiers lourds

Les outils de développement de Chrome affichent la cascade des ressources d’une page : chaque fichier, son poids, son moment de chargement, son domaine d’origine. Un script servi par un autre domaine que le vôtre peut venir d’un tiers : pixel publicitaire, module d’avis, messagerie. web.dev conseille de retrouver dans cette cascade la ressource du plus grand élément affiché. Elle désigne l’image ou le fichier à alléger en premier.

Cinq éléments à exiger par écrit dans le livrable d’un audit de performance PrestaShop

Exigez ces cinq éléments, écrits :

• les conditions de mesure : matériel du serveur, réglages de PHP, d’Apache et de MySQL, configuration et version de PrestaShop, ce que la documentation de l’éditeur demande de noter pour comparer deux mesures ;
• les pages testées : accueil, panier, catégorie filtrée, fiche avec une déclinaison choisie, résultats de recherche, tirées de la liste du banc d’essai de l’éditeur ;
• le classement des causes par gain attendu et par effort, chacune marquée « constat » ou « hypothèse » ;
• la mesure avant et après de chaque correction, sur les mêmes pages ;
• la liste de ce qui reste hors périmètre : thème, modules sans mise à jour, hébergement et réglage du serveur et du cache, qui suivent une fois la cause localisée.

Un gain chiffré annoncé avant toute mesure reste une hypothèse. Le devis varie probablement avec le nombre de modules à passer en revue, la taille du catalogue, l’accès aux journaux du serveur et la présence d’une copie de la boutique. Faites préciser si les corrections sont comprises ou chiffrées à part, et qui paie la remise en état quand l’une d’elles casse une page.

La mesure d’un audit PrestaShop se fausse quand les conditions changent

Plusieurs réglages modifiés en même temps rendent le résultat illisible : impossible de dire lequel a payé. Un réglage par passage, chaque passage mesuré.

Le premier passage sur une page tombe sur des caches vides. La documentation du banc d’essai demande un tour de chauffe à un seul utilisateur avant de chronométrer.

Alléger les images avant de connaître la part du serveur risque de déplacer l’effort sur le mauvais maillon. web.dev découpe le temps d’affichage du plus grand élément en quatre temps, dont la réponse du serveur.

Dans le message du formulaire de cette page, reportez la version de PrestaShop, le nombre de modules et les adresses des pages à tester.

Décrire mon besoin →

Sources consultées

• PrestaShop, documentation développeur de PrestaShop 9, « Optimize your PrestaShop performance » et « Taking care of your PrestaShop », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de PrestaShop 9, « Introduction to configuration », rubrique du mode de débogage, consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de PrestaShop 9, « How to benchmark your PrestaShop » et « Front-Office Benchmark », consulté le 14 octobre 2026.
• PrestaShop, documentation utilisateur de la version 8, « Performance » et « Information », rubrique Paramètres avancés, consulté le 14 octobre 2026.
• PrestaShop, documentation utilisateur de la version 1.7 en français, « Paramètres de performances », section « Mode debug », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur, « System requirements » (versions 1.7 et 8), consulté le 14 octobre 2026.
• PHP, « Unsupported Branches », php.net, consulté le 14 octobre 2026.
• Oracle, « MySQL 8.4 Reference Manual », « The Slow Query Log » et « Server System Variables » (entrée long_query_time), consulté le 14 octobre 2026.
• MariaDB, « Slow Query Log Overview », consulté le 14 octobre 2026.
• Google, « Why lab and field data can be different (and what to do about it) », web.dev, consulté le 14 octobre 2026.
• Google, « About PageSpeed Insights » et « Core Web Vitals report » (aide de la Search Console), consulté le 14 octobre 2026.
• Google, « Optimize Largest Contentful Paint », web.dev, consulté le 14 octobre 2026.

Foire aux questions

Un audit de performance modifie-t-il la boutique ?

Les mesures de terrain et de laboratoire ne touchent à rien. L’activation du journal des requêtes lentes change la configuration de la base, à convenir par écrit ; le mode de débogage, qui montre les messages d’erreur aux visiteurs, se joue sur une copie. Les corrections relèvent d’une autre étape, avec son propre accord.

Peut-on auditer une boutique sans accès au serveur ?

En partie. PageSpeed Insights et la cascade du navigateur se lisent de l’extérieur ; le rapport de la Search Console demande l’accès à la propriété. Le journal de la base, le profileur et la configuration de PHP exigent un accès. Un audit de l’extérieur dit où le temps se perd côté visiteur, pas pourquoi le serveur met du temps à répondre.

Un audit sert-il sur une boutique en PrestaShop 1.7 ou 8 ?

Oui, avec une limite. La branche 1.7.8 ne dépasse pas PHP 7.4, que php.net ne corrige plus depuis le 28 novembre 2022. La branche 8 s’arrête à PHP 8.1, sans correctif depuis le 31 décembre 2025. L’audit trouve les causes de lenteur de la boutique ; le plafond posé par la version de PrestaShop reste hors de sa portée.

Quelle différence avec un audit SEO ?

L’audit SEO relève l’indexation, les balises et le maillage des pages. L’audit de performance mesure des temps de réponse et d’affichage, sur ces mêmes pages. Un rapport SEO peut signaler une page lente : la cause de cette lenteur se cherche dans l’audit de performance.