10 conseils pratiques pour accélérer votre boutique PrestaShop 9
PrestaShop 9 offre aux marchands une base technique plus moderne, mais la rapidité de la boutique dépend encore fortement de la configuration, des modules, de la conception de la base de données, des images, de l'hébergement et des tâches en arrière-plan.
Il n'existe pas de case à cocher unique qui rende toutes les boutiques PrestaShop rapides.
La méthode la plus efficace consiste à repérer les principaux goulets d'étranglement et à les corriger dans l'ordre.
Ce guide présente dix améliorations pouvant apporter des résultats concrets dans de vraies boutiques, sans conseils vagues comme « achetez un meilleur hébergement ».
Note sur les versions : Cet article a été vérifié le 22 septembre 2026. PrestaShop 9.0 recommande PHP 8.4, tandis que PrestaShop 9.1 prend en charge et recommande PHP 8.5. PrestaShop 9 intègre la prise en charge native de WebP et AVIF ainsi que plusieurs améliorations des performances du front-office.
Avant toute modification : mesurez les performances de la boutique
Avant d'appliquer des optimisations, enregistrez une référence initiale.
Testez plusieurs types de pages :
- page d'accueil ;
- catégorie ;
- produit ;
- recherche ;
- panier ;
- commande ;
- fiche produit du back-office ;
- fiche commande du back-office.
Mesurez :
- Time to First Byte ;
- poids total de la page ;
- nombre de requêtes ;
- Largest Contentful Paint ;
- temps de réponse du serveur ;
- temps d'exécution PHP ;
- requêtes de base de données lentes ;
- durée des tâches cron.
Si possible, effectuez les tests pendant l'exécution des tâches de fond habituelles.
Une boutique peut sembler rapide sans importations ni synchronisations actives, puis ralentir fortement lorsque ces tâches démarrent.
L'objectif de cette référence est simple : après chaque changement important, mesurez de nouveau.
1. Utiliser la bonne version de PHP
L'une des vérifications les plus simples concerne l'environnement PHP.
Le tableau de compatibilité actuel de PrestaShop recommande :
- PHP 8.4 pour PrestaShop 9.0 ;
- PHP 8.5 pour PrestaShop 9.1.
Les versions récentes de PHP améliorent les performances et le moteur d'exécution, mais il faut tester la compatibilité.
Ne changez pas directement la version PHP en production.
Créez un environnement de préproduction et testez :
- page d'accueil ;
- pages produit ;
- passage de commande ;
- modules de paiement ;
- modules de livraison ;
- importations ;
- tâches cron ;
- commandes CLI ;
- modules personnalisés.
Vérifiez également PHP en CLI
Une erreur fréquente consiste à vérifier uniquement la version de PHP utilisée par le site web.
Exécutez :
php -v
depuis le même environnement que celui utilisé par cron.
Il est possible d'avoir :
PHP Web = 8.5
PHP CLI = 8.2
Cela peut provoquer des problèmes déroutants : la boutique fonctionne dans le navigateur, mais les commandes planifiées échouent.
Activer OPcache
Une boutique PrestaShop en production devrait normalement utiliser OPcache.
OPcache conserve le bytecode PHP compilé en mémoire au lieu d'analyser et de compiler les fichiers PHP à chaque fois.
Vérifiez qu'il est réellement activé et que sa capacité est suffisante pour :
- le cœur de PrestaShop ;
- Symfony ;
- les modules ;
- le code personnalisé.
Ne supposez pas que les paramètres par défaut du serveur sont optimaux.
2. Identifier les modules les plus lents
Le nombre de modules installés n'est pas le principal indicateur de performance.
Un seul module mal conçu peut être plus lent que cinquante bons modules.
Un module peut ralentir la boutique s'il :
- exécute des requêtes SQL coûteuses sur chaque page ;
- effectue des appels API distants ;
- charge de gros volumes de données ;
- rattache des traitements lourds à des hooks globaux ;
- recalcule des données qui pourraient être mises en cache ;
- effectue des opérations sur les fichiers pendant l'affichage du front-office.
Effectuer un test contrôlé
En préproduction :
- mesurez une page lente ;
- désactivez un module non essentiel ;
- mesurez à nouveau ;
- recommencez.
Si le temps de chargement passe de :
1.8 secondes
à :
600 millisecondes
après la désactivation d'un seul module, vous avez trouvé une cible d'optimisation à fort potentiel.
Ne supprimez pas simplement ce module s'il est important.
Profilez son code et identifiez l'opération coûteuse.
3. Optimiser les requêtes de base de données
Les grandes boutiques PrestaShop sont souvent limitées par la base de données.
Une requête qui prend 20 ms avec 1 000 produits peut durer plusieurs secondes après des années de croissance du catalogue.
Activez le journal des requêtes lentes pendant une période contrôlée.
Recherchez les requêtes associées à :
- listes de produits ;
- pages de catégorie ;
- recherche ;
- grilles du back-office ;
- synchronisation des stocks ;
- importations ;
- flux de données.
Utilisez ensuite :
EXPLAIN
pour examiner comment la base de données exécute la requête.
Repérer les analyses complètes des tables
Un module peut exécuter de manière répétée une requête comme :
SELECT *
FROM ps_custom_queue
WHERE status = 'pending'
AND id_shop = 2
ORDER BY id_queue
LIMIT 100;
Si la table contient des millions de lignes sans index utile, la base de données peut parcourir bien plus de données que nécessaire.
Un index composite approprié pourrait être :
(id_shop, status, id_queue)
Mais n'ajoutez jamais d'index à l'aveugle.
L'index correct dépend de la requête réelle et de la répartition des données.
Éviter les écritures inutiles
Mettre à jour un produit alors que rien n'a changé entraîne inutilement :
- écritures SQL ;
- maintenance des index ;
- invalidation du cache ;
- exécution des hooks.
Les intégrations fournisseurs devraient utiliser des horodatages, des hachages ou un suivi des modifications lorsque cela est possible.
4. Utiliser correctement WebP et AVIF
PrestaShop 9 a introduit la prise en charge native de formats d'image modernes, notamment :
- WebP ;
- AVIF.
Ces formats peuvent réduire considérablement le volume des images transférées.
Mais activer WebP ou AVIF ne garantit pas à lui seul une boutique rapide.
Vérifiez également :
- dimensions des images source ;
- types d'images générées ;
- qualité de compression ;
- tailles d'images responsives ;
- chargement différé ;
- comportement du CDN.
Ne pas charger une image immense dans une petite vignette
Si une fiche produit de catégorie mesure 320 pixels de large, télécharger une image de 2 000 pixels est un gaspillage.
Le navigateur peut l'afficher en 320 pixels, mais le client supporte quand même le coût du téléchargement et du décodage.
Utilisez une taille générée adaptée.
Auditer les types d'images
Les thèmes et les modules peuvent créer de nombreuses tailles de vignettes.
Imaginez :
80,000 produits
× 4 photos
× 10 types d'images
Cela peut produire :
3,200,000 images générées
Si le thème n'utilise que six types d'images, les autres sont peut-être inutiles.
Ne les supprimez pas avant de vérifier que :
- les modules ;
- les flux ;
- les e-mails ;
- les places de marché ;
ne les utilisent pas.
5. Déplacer les tâches lourdes vers CLI et cron
Une requête du navigateur n'est pas adaptée au traitement de 100 000 produits.
Les opérations longues risquent d'atteindre :
- les délais d'expiration du proxy ;
- les limites de temps d'exécution PHP ;
- les déconnexions du navigateur ;
- les limites de mémoire.
Utilisez CLI, cron ou des workers de file d'attente pour :
- les importations fournisseurs ;
- le traitement des images ;
- la génération des flux ;
- les mises à jour des prix ;
- la synchronisation des stocks ;
- la maintenance en masse.
Traiter par lots
Au lieu de :
Traiter les 100,000 produits
utilisez :
Réserver 200 enregistrements
Traiter
Enregistrer la progression
Quitter ou continuer
Cela facilite :
- la reprise ;
- la surveillance ;
- les nouvelles tentatives ;
- l'arrêt en toute sécurité.
Ajouter un verrouillage
Si cron s'exécute chaque minute alors que le traitement précédent est toujours actif, un second worker peut démarrer.
Utilisez des verrous ou des baux.
Des tâches lourdes dupliquées peuvent doubler la consommation des ressources et provoquer des incohérences de données.
6. Mettre efficacement en cache les ressources statiques
CSS, JavaScript, les polices et les images changent bien moins souvent que le HTML.
Configurez des en-têtes de cache navigateur appropriés.
Les ressources statiques se prêtent à de longues durées de cache lorsque les noms de fichiers ou les URL changent lors du déploiement.
Exemples :
CSS
JavaScript
JPG
PNG
WebP
AVIF
polices
Cela réduit les téléchargements répétés et le trafic du serveur.
Utiliser un CDN si nécessaire
Un CDN peut améliorer la diffusion des ressources statiques aux clients éloignés du serveur d'origine.
Il peut aussi réduire la charge du serveur web.
Cependant, un CDN ne peut pas corriger un PHP lent.
Si le Time to First Byte atteint déjà deux secondes avant le téléchargement des images, optimisez d'abord l'application.
7. Faire attention au cache de pages complètes
Le cache de pages complètes semble intéressant, car il peut éviter une grande partie de l'exécution PHP.
Mais les pages de commerce électronique sont souvent personnalisées.
Le résultat peut varier selon :
- le client ;
- le groupe de clients ;
- la devise ;
- le pays ;
- la langue ;
- les règles fiscales ;
- le contenu du panier ;
- la boutique.
Un cache de pages mal conçu peut afficher un mauvais :
- prix ;
- panier ;
- remise ;
- bloc client.
N'appliquez un cache agressif que si sa clé représente correctement tous les contextes importants.
Pour de nombreuses boutiques, le cache des ressources statiques et le cache applicatif sont des points de départ plus sûrs.
8. Supprimer les modules inutilisés et l'ancien code
Le code inutilisé complique la maintenance.
Les anciens modules peuvent encore :
- enregistrer des hooks ;
- charger des chargeurs automatiques ;
- laisser des tâches cron actives ;
- générer des requêtes de base de données ;
- poser des problèmes de compatibilité PHP.
Auditez l'installation de production.
Pour chaque module, demandez-vous :
- Est-il utilisé ?
- Qui en est responsable ?
- Quand a-t-il été mis à jour pour la dernière fois ?
- Possède-t-il une tâche planifiée ?
- Stocke-t-il des données métier ?
- Existe-t-il une alternative ?
Supprimez les modules obsolètes avec précaution.
Ne supprimez pas un module sans vérifier si un autre système dépend de ses données.
Examiner également les overrides
Un ancien override peut remplacer une méthode du cœur par du code écrit pour une ancienne génération de PrestaShop.
Cela peut causer des problèmes de performance et de compatibilité.
9. Maîtriser la concurrence PHP-FPM
Augmenter le nombre de workers PHP n'améliore pas toujours les performances.
Supposons :
Processus occupé moyen = 180 MB
Si :
pm.max_children = 40
alors la mémoire potentielle des workers est :
7.2 GB
sans compter :
- MySQL ;
- Redis ;
- Nginx ;
- le système d'exploitation ;
- les tâches CLI.
Sur un serveur de 8 Go, c'est risqué.
Lorsque la mémoire est épuisée, Linux peut utiliser le swap ou arrêter des processus, entraînant de fortes latences.
Mesurez la mémoire des workers sous une charge réaliste et définissez une limite sûre.
L'objectif est de disposer d'une concurrence suffisante sans épuiser la marge de mémoire disponible.
10. Surveiller les performances en continu
L'optimisation n'est pas un projet ponctuel.
Les performances évoluent lorsque :
- le catalogue s'agrandit ;
- les modules sont mis à jour ;
- le thème change ;
- le trafic marketing augmente ;
- les fournisseurs ajoutent des produits ;
- les tâches cron s'allongent.
Surveillez :
- le temps de réponse ;
- le taux HTTP 5xx ;
- le CPU ;
- la RAM ;
- la file d'attente PHP-FPM ;
- les connexions à la base de données ;
- les requêtes lentes ;
- les entrées/sorties disque ;
- l'espace disque libre ;
- l'utilisation des inodes ;
- la file d'attente des tâches ;
- la durée des tâches cron.
Surveiller également les traitements métier
Une importation de produits qui dure 20 minutes aujourd'hui et 90 minutes le mois prochain constitue une régression, même si la vitrine reste rapide.
Suivez la durée et le débit des traitements.
Audit rapide des performances PrestaShop en 30 minutes
Si vous n'avez qu'une demi-heure, procédez comme suit :
1. Vérifier PHP
Confirmez :
php -v
ainsi que la version PHP utilisée par le web.
2. Vérifier OPcache
Assurez-vous qu'il est activé.
3. Mesurer trois pages
Relevez les mesures pour :
- la page d'accueil ;
- une catégorie ;
- un produit.
4. Inspecter les requêtes SQL lentes
Examinez les requêtes les plus lentes de la base de données.
5. Vérifier les tailles d'images
Comparez les dimensions affichées avec celles des fichiers téléchargés.
6. Examiner les tâches cron actives
Repérez les tâches exécutées pendant les heures de pointe.
7. Vérifier la charge du serveur
Inspectez :
- la RAM ;
- le CPU ;
- le disque ;
- l'attente des E/S.
Cet audit rapide indique généralement la prochaine action utile.
Exemple : corriger une page de catégorie lente
Supposons qu'une page de catégorie prenne :
2.1 secondes TTFB
Le profilage montre :
Module de filtre personnalisé: 950 ms
Requête de base de données: 600 ms
Autres traitements PHP: 350 ms
Travail restant: 200 ms
Avant d'acheter un serveur plus puissant, commencez par le module de filtres personnalisé.
Il manque peut-être un index à la requête.
Après avoir ajouté le bon index :
Requête de base de données: 80 ms
Mettez ensuite en cache les métadonnées des filtres :
Module de filtre: 150 ms
Nouveau TTFB :
780 ms
C'est bien plus efficace que d'ajouter du matériel à l'aveugle.
Exemple : corriger les ralentissements liés aux importations
Imaginez que la vitrine soit rapide la majeure partie de la journée, mais lente entre 02 h et 04 h.
L'importation du fournisseur exécute :
analyse complète des produits
téléchargement complet des images
mise à jour complète des stocks
mise à jour complète des prix
pour chaque produit.
Une meilleure conception sépare les tâches :
Analyse fournisseur
↓
Détecter les enregistrements modifiés
↓
File de mise à jour des produits
├── processus de prix
├── processus de stock
└── processus d'images
Les produits inchangés sont alors ignorés.
Le worker d'images peut être limité à un ou deux processus.
Les mises à jour de stock peuvent rester fréquentes.
Cela réduit les pics de charge et raccourcit le travail total.
Ce qu'il ne faut pas faire
N'installez pas tous les « modules de vitesse » que vous trouvez
Les modules de performance peuvent entrer en conflit ou mettre en cache du contenu incorrect.
Ne videz pas tous les caches chaque minute
Une invalidation constante annule l'intérêt du cache.
N'ajoutez pas d'index de base de données au hasard
Les index doivent répondre à de vraies requêtes.
N'augmentez pas indéfiniment les limites de mémoire
Corrigez les algorithmes gourmands en mémoire.
Ne lancez pas cinq workers d'images parce qu'un seul est lent
Vérifiez d'abord si le CPU ou le disque est déjà saturé.
Ne mesurez pas uniquement la page d'accueil
Les charges des pages catégorie, produit, paiement et back-office diffèrent.
Liste de contrôle des performances de PrestaShop 9
- Version PHP prise en charge et adaptée
- OPcache activé
- OPcache correctement dimensionné
- Concurrence PHP-FPM mesurée
- Requêtes de base de données lentes examinées
- Index vérifiés avec
EXPLAIN - Modules coûteux identifiés
- Appels API distants retirés des chemins critiques
- WebP/AVIF évalués
- Dimensions des images correctes
- Types d'images inutilisés supprimés
- Ressources statiques mises en cache
- CDN envisagé
- Tâches lourdes exécutées via CLI
- Verrous utilisés pour cron
- Importations traitées par lots
- Produits inchangés ignorés
- Files d'attente surveillées
- Espace disque et inodes surveillés
- Référence de performance conservée
Questions fréquentes
Pourquoi ma boutique PrestaShop 9 est-elle lente ?
Les causes courantes comprennent les modules lents, les requêtes SQL inefficaces, les images trop volumineuses, un trop grand nombre de workers PHP, un hébergement surchargé et des tâches de fond en concurrence avec le trafic client.
Que faut-il optimiser en premier ?
Le composant le plus lent selon les mesures. Ne choisissez pas une solution avant d'avoir mesuré le goulet d'étranglement.
PrestaShop 9 prend-il en charge WebP ?
Oui. PrestaShop 9 intègre la prise en charge native de WebP.
PrestaShop 9 prend-il en charge AVIF ?
Oui. La prise en charge d'AVIF est également native dans PrestaShop 9.
Dois-je utiliser PHP 8.5 ?
PrestaShop 9.1 prend en charge et recommande actuellement PHP 8.5. PrestaShop 9.0 recommande PHP 8.4. Testez les modules avant de changer.
Redis accélère-t-il PrestaShop ?
Il peut améliorer certaines charges de travail, mais ne corrige pas automatiquement des requêtes SQL lentes ou des modules inefficaces.
Dois-je d'abord mettre à niveau le serveur ?
Seulement si la surveillance montre que les ressources du serveur sont la véritable limite. Les corrections du code et de la base de données apportent souvent davantage.
Comment accélérer une grosse importation de produits ?
Lisez les données source en flux, traitez-les par lots, ignorez les enregistrements inchangés, séparez la mise à jour des produits du traitement des images et limitez la concurrence des workers.