Optimisation des performances de PrestaShop 9 : guide complet

Une boutique PrestaShop lente a rarement une seule cause.

Les performances résultent de la combinaison de PHP, des requêtes SQL, des modules, des hooks, des images, du stockage, de la configuration du cache, des tâches en arrière-plan, des paramètres du serveur Web, des services tiers et de l’évolution du catalogue.

PrestaShop 9 offre une base technique plus solide que les générations précédentes. Il utilise Symfony 6.4, prend en charge les versions modernes de PHP, gère nativement les images WebP et AVIF et apporte plusieurs améliorations du front-office et du rendu.

Mais passer à PrestaShop 9 ne rend pas automatiquement toutes les boutiques rapides.

Un module mal écrit peut toujours exécuter une requête SQL coûteuse sur chaque page. Un import fournisseur peut saturer le CPU et le disque. Un thème peut charger des images produit surdimensionnées. Une grande base de données peut encore souffrir d’index manquants.

La bonne méthode pour optimiser PrestaShop 9 est donc :

mesurer → identifier le goulot d’étranglement → effectuer un seul changement → mesurer à nouveau

Ce principe se retrouve également dans la documentation officielle de PrestaShop sur les performances.

Ce guide présente une méthode pratique d’optimisation pour les véritables boutiques en production.

Note de version : Cet article a été vérifié le 22 septembre 2026. PrestaShop 9.1 recommande actuellement PHP 8.5, tandis que PrestaShop 9.0 recommande PHP 8.4. Testez toujours vos modules et votre thème avec la version exacte de PHP que vous prévoyez d’utiliser.

1. Établir une référence de performance

Ne commencez pas par modifier au hasard les paramètres du Back Office.

Commencez par mesurer les performances de la boutique.

Au minimum, mesurez les performances des pages suivantes :

• page d’accueil ;
• page de catégorie ;
• page produit ;
• recherche ;
• panier ;
• validation de commande ;
• page produit du Back Office ;
• page de commande du Back Office.

Ne mesurez pas uniquement le temps de chargement total dans le navigateur.

Les indicateurs utiles comprennent :

• Time to First Byte (TTFB) ;
• temps d’exécution PHP ;
• temps d’exécution des requêtes SQL ;
• nombre de requêtes SQL ;
• volume total de données transférées ;
• Largest Contentful Paint ;
• Interaction to Next Paint ;
• Cumulative Layout Shift ;
• consommation de mémoire PHP ;
• durée de la tâche cron la plus lente.

Vous disposez ainsi d’un point de référence.

Si vous modifiez les paramètres de PHP-FPM et que le TTFB se dégrade de 15 %, vous savez que le changement n’a rien amélioré.

Sans point de référence, l’optimisation relève de la supposition.

2. Tester dans des conditions proches de la production

N’effectuez pas vos benchmarks uniquement avec le mode debug activé.

Le mode développeur modifie le comportement de l’application et peut désactiver ou changer la mise en cache.

De même, ne mesurez pas uniquement les performances en étant connecté comme administrateur si la plupart des clients naviguent anonymement.

Testez :

• un visiteur anonyme ;
• un client avec un panier ;
• un client connecté ;
• un appareil mobile ;
• un ordinateur de bureau.

Répétez également les tests lorsque les tâches en arrière-plan sont actives.

Une boutique peut sembler rapide à 3 h du matin lorsqu’aucun autre traitement ne tourne, puis ralentir chaque matin au démarrage d’un import fournisseur.

3. Trouver le véritable goulot d’étranglement

Une page lente peut être causée par différentes couches techniques.

Goulot d’étranglement CPU

Les symptômes possibles comprennent :

• des processus PHP utilisant fortement le CPU ;
• le traitement des images ralentissant le serveur ;
• des imports en concurrence avec le trafic client ;
• la génération AVIF consommant beaucoup de CPU.

Goulot d’étranglement mémoire

Les symptômes possibles comprennent :

• des processus arrêtés par manque de mémoire (OOM) ;
• des erreurs de mémoire PHP ;
• l’utilisation du swap par le serveur ;
• l’éviction du cache de base de données hors de la RAM.

Goulot d’étranglement de la base de données

Les symptômes possibles comprennent :

• des pages de catégorie lentes ;
• des grilles du Back Office qui expirent ;
• une forte utilisation du CPU par la base de données ;
• une croissance du journal des requêtes lentes ;
• des analyses complètes de tables.

Goulot d’étranglement du disque

Les symptômes possibles comprennent :

• une génération d’images extrêmement lente ;
• un temps d’attente E/S élevé ;
• des requêtes SQL lentes malgré une charge CPU modérée ;
• des opérations sur le système de fichiers retardant la génération du cache.

Goulot d’étranglement réseau

Les symptômes possibles comprennent :

• des appels d’API distants qui retardent PHP ;
• des flux tiers lents ;
• une mauvaise configuration du CDN ;
• des images volumineuses.

N’optimisez pas la mauvaise couche.

4. Utiliser la bonne version PHP

Les exigences officielles actuelles de PrestaShop 9 recommandent :

• PHP 8.4 pour PrestaShop 9.0
• PHP 8.5 pour PrestaShop 9.1

Utiliser une version récente et prise en charge de PHP peut améliorer à la fois les performances et la maintenabilité.

Mais ne commencez pas par modifier la production.

Testez :

• le cœur de PrestaShop ;
• le thème ;
• les modules de paiement ;
• les modules de livraison ;
• les imports ;
• les tâches cron ;
• la CLI ;
• les modules personnalisés.

Les erreurs PHP n’apparaissent souvent que dans des cas particuliers.

5. Activer OPcache

OPcache est l’un des éléments de base d’un environnement PHP performant.

Sans OPcache, PHP analyse et compile à nouveau les fichiers de l’application à chaque fois.

PrestaShop possède une base de code volumineuse, et les modules ajoutent encore davantage de fichiers PHP.

Une configuration PHP de production devrait normalement activer OPcache.

Voici un exemple de paramètres :

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=50000
opcache.validate_timestamps=1

Ces valeurs sont des exemples, pas des recommandations universelles.

Consultez les statistiques réelles d’OPcache.

Les indicateurs importants comprennent :

• la mémoire utilisée ;
• la mémoire libre ;
• le taux de cache hit ;
• le nombre de scripts mis en cache ;
• le nombre de redémarrages.

Si OPcache redémarre constamment parce que le cache est plein, augmentez sa taille en vous appuyant sur des mesures.

6. Ne désactivez pas la vérification des horodatages à l’aveugle

Certains guides de performance recommandent :

opcache.validate_timestamps=0

Cela peut réduire les vérifications de fichiers.

Cependant, cela signifie aussi que les modifications de fichiers PHP peuvent ne pas être détectées tant qu’OPcache ou PHP-FPM n’a pas été redémarré.

Si votre processus de déploiement réinitialise explicitement OPcache, cette approche peut être sûre.

Si les administrateurs téléversent manuellement des fichiers de modules, cela peut provoquer une situation déroutante où le nouveau code est sur le disque mais l’ancien bytecode continue de s’exécuter.

La configuration des performances doit être adaptée à votre processus de déploiement.

7. Dimensionner correctement PHP-FPM

Trop peu de workers créent des files d’attente.

Trop de workers peuvent épuiser la RAM.

Supposons qu’un worker PHP PrestaShop consomme environ 150 Mo en charge réelle.

Si vous autorisez :

pm.max_children = 40

alors la consommation théorique de mémoire des workers est de :

40 × 150 MB = 6000 MB

Cela n’inclut pas :

• MySQL/MariaDB ;
• Redis ;
• Nginx/Apache ;
• le système d’exploitation ;
• le cache du système de fichiers ;
• les tâches cron.

Sur un serveur de 8 Go, cette configuration pourrait être dangereuse.

Mesurez la consommation moyenne et maximale des workers et conservez une marge de sécurité.

8. Séparer PHP Web des tâches CLI lourdes

Un client qui ouvre une page produit ne devrait pas entrer directement en concurrence avec un import de trois heures utilisant le même modèle de processus.

Les tâches lourdes devraient être exécutées via :

• CLI ;
• cron ;
• des files d’attente ;
• des workers dédiés.

Exemples :

• analyse de fichiers XML de fournisseurs ;
• régénération d’images ;
• synchronisation des stocks ;
• mise à jour des prix ;
• génération de sitemaps ;
• génération de flux.

Cela facilite le contrôle de l’utilisation des ressources.

9. Profiler les requêtes SQL

L’optimisation de la base de données peut apporter certains des gains les plus importants aux grandes boutiques.

Activez le journal des requêtes lentes de la base de données pendant une période contrôlée.

Recherchez :

• des requêtes qui parcourent d’énormes tables ;
• des index manquants ;
• des requêtes répétées ;
• des requêtes triant de gros volumes de données ;
• des jointures dont la cardinalité explose.

Utilisez ensuite :

EXPLAIN

pour examiner le plan d’exécution.

N’optimisez pas une requête en vous fiant uniquement à son apparence.

Une requête complexe peut être rapide avec le bon index.

Une requête simple peut être catastrophique si elle parcourt des millions de lignes.

10. Ajouter des index selon les requêtes réelles

Les index sont extrêmement utiles, mais ils ont un coût.

Chaque index :

• consomme de l’espace de stockage ;
• utilise de la mémoire ;
• augmente le coût des écritures ;
• doit être maintenu lors des insertions et des mises à jour.

Supposons qu’un processus de module exécute régulièrement :

SELECT *
FROM ps_module_queue
WHERE id_shop = 2
  AND status = 'pending'
ORDER BY id_queue
LIMIT 100;

Un index composite adapté peut réduire considérablement le travail nécessaire.

Par exemple :

(id_shop, status, id_queue)

Mais le bon index dépend de la requête réelle et de la répartition des données.

Utilisez EXPLAIN avant et après.

11. Éviter SELECT * dans les chemins critiques

Pour des requêtes administratives occasionnelles, sélectionner toutes les colonnes n’a pas forcément d’importance.

Pour les requêtes fréquentes sur des tables larges, cela peut gaspiller :

• des opérations d’E/S de base de données ;
• du trafic réseau ;
• de la mémoire PHP ;
• du temps d’hydratation des données.

Sélectionnez uniquement les champs réellement nécessaires à l’opération.

C’est particulièrement important pour :

• les processus de file d’attente ;
• la synchronisation des produits ;
• les points de terminaison de statut ;
• les tableaux de bord.

12. Auditer les grandes tables

Examinez la taille des tables.

Les sources courantes de croissance incontrôlée comprennent :

• les journaux des modules ;
• l’historique des importations ;
• l’historique des files d’attente ;
• les données abandonnées ;
• les statistiques de visiteurs ;
• les tables temporaires ;
• les enregistrements d’audit.

Ne supprimez pas des données simplement parce qu’une table est volumineuse.

Déterminez d’abord :

• à qui appartiennent les données ;
• si elles sont nécessaires à la comptabilité ;
• si elles sont nécessaires au support ;
• si elles sont nécessaires aux audits ;
• si le module s’attend à les retrouver.

Définissez ensuite une politique de conservation explicite.

Examiner le stockage des statistiques PrestaShop avant le nettoyage

Utilisez le scanner gratuit Stats Table Guard Lite pour examiner les estimations de taille des tables, l’historique des connexions et l’état de collecte des statistiques. Cette analyse reste en lecture seule et peut présenter des métadonnées partielles sur un hébergement restreint.

Si vous avez besoin d’un workflow distinct de prévisualisation et de nettoyage, consultez Stats Table Guard Pro. L’achat de Pro n’est pas encore activé. Les contrôles de nettoyage décrits appliquent une période de conservation et des lots transactionnels lancés explicitement aux anciennes statistiques de connexion ; la suppression de lignes ne garantit pas une réduction immédiate de la taille des fichiers de base de données.

Consultez la Documentation de Stats Table Guard pour les étapes d’analyse et le périmètre des éditions.

13. Traiter les mises à jour massives par lots

Une tâche qui met à jour 100 000 produits dans une seule transaction est difficile à exploiter.

Les problèmes comprennent :

• des verrous prolongés ;
• de grosses transactions ;
• une augmentation de l’utilisation mémoire ;
• un risque de dépassement de délai ;
• des reprises difficiles.

Une approche plus sûre traite des lots de taille limitée :

100 produits
→ enregistrer la progression
→ 100 suivants
→ enregistrer la progression
→ continuer

La taille optimale des lots dépend de la charge de travail.

Testez 50, 100, 500 ou 1 000 éléments et mesurez les résultats.

14. Mettre à jour uniquement les produits modifiés

L’une des meilleures optimisations de synchronisation des fournisseurs consiste à éviter les écritures inutiles.

Si les données du fournisseur n’ont pas changé, ne réécrivez pas le produit.

Une méthode utile consiste à utiliser une empreinte des données source.

Par exemple :

données produit normalisées
        ↓
empreinte SHA-256
        ↓
comparer à l'empreinte enregistrée
        ↓
inchangé → ignorer
modifié → mettre à jour

Les grands systèmes peuvent conserver des empreintes distinctes pour :

• les données principales du produit ;
• le prix ;
• le stock ;
• les caractéristiques ;
• les images ;
• les catégories.

Ainsi, une modification d’image n’oblige pas à réécrire tous les champs du produit.

15. Profiler les modules selon leur coût d’exécution

Ne supposez pas qu’une boutique est lente parce qu’elle possède « trop de modules ».

Le nombre de modules n’est pas l’indicateur essentiel.

Un seul module inefficace peut ralentir davantage que cinquante modules efficaces.

Recherchez les modules qui :

• s’exécutent sur des hooks globaux ;
• exécutent de nombreuses requêtes SQL ;
• appellent des API distantes lors du rendu des pages ;
• traitent de grands volumes de données à chaque requête ;
• chargent des services inutiles ;
• recalculent sans cesse le même résultat.

Désactivez les modules non essentiels un par un dans l’environnement de préproduction et comparez les performances.

16. Éviter les appels HTTP distants pendant le rendu des pages

Une page produit ne devrait pas attendre une API tierce, sauf nécessité absolue.

Si un module exécute :

requête client
→ PrestaShop
→ API distante
→ attendre
→ afficher la page

alors le service distant devient une partie du temps de réponse de votre page.

Parmi les meilleures méthodes :

• un cache local ;
• une synchronisation en arrière-plan ;
• une actualisation planifiée ;
• un traitement asynchrone.

Par exemple, les taux de change peuvent être actualisés périodiquement au lieu d’être téléchargés à chaque chargement de page.

17. Auditer l’exécution des hooks

Certains hooks s’exécutent sur de nombreuses pages.

Si un module associe un traitement coûteux à un hook global, son coût se multiplie à chaque requête.

Analysez les performances de :

• les hooks d’en-tête ;
• les hooks de pied de page ;
• les hooks d’affichage des produits ;
• les hooks du panier ;
• les hooks liés aux clients.

Demandez-vous si l’opération doit vraiment s’exécuter à chaque fois.

Un hook peut se contenter d’afficher des données déjà mises en cache.

18. Utiliser le support natif de WebP et AVIF

PrestaShop 9 a introduit la prise en charge native de :

• WebP ;
• AVIF.

Les informations de publication officielles de PrestaShop 9 mettent expressément ces formats en avant comme améliorations des performances.

Les formats modernes peuvent réduire considérablement le volume des images transférées.

Toutefois, le format du fichier ne constitue qu’une partie de l’optimisation des images.

Prenez aussi en compte :

• les dimensions ;
• la qualité de compression ;
• le nombre de types d’images générés ;
• les images adaptatives ;
• le chargement différé ;
• la mise en cache du CDN.

19. Supprimer les types d’images inutilisés

Les thèmes et les modules peuvent enregistrer plusieurs tailles d’images.

Un grand catalogue peut générer des millions de fichiers.

Exemple :

100,000 produits
× 4 images
× 10 types d'images
= 4,000,000 fichiers générés

Si le thème actuel n’utilise que six de ces types d’images, les quatre autres peuvent représenter un stockage et des tâches de régénération inutiles.

Auditez chaque type d’image avant de supprimer quoi que ce soit.

Vérifiez :

• les modèles du thème ;
• les modules ;
• les modèles d’e-mails ;
• les flux ;
• les places de marché.

20. Ne pas envoyer d’images surdimensionnées

Une fiche produit affichée en 300 × 300 pixels ne devrait pas télécharger une image de 2 000 × 2 000 pixels.

Le navigateur peut la redimensionner visuellement, mais le client télécharge et décode quand même le fichier plus volumineux.

Fournissez une image dont les dimensions sont proches de celles de l’affichage.

Cela réduit :

• la bande passante ;
• la consommation de données mobiles ;
• le temps de décodage ;
• le Largest Contentful Paint.

21. Charger paresseusement les images hors écran

Les images situées initialement hors de la zone visible n’ont pas toujours besoin d’être téléchargées immédiatement.

Le chargement différé peut réduire sensiblement la charge réseau initiale sur :

• les pages de catégories ;
• les résultats de recherche ;
• les carrousels de produits associés.

N’appliquez pas le chargement différé à l’image principale du Largest Contentful Paint sur une page produit sans effectuer de tests.

L’image principale mise en avant peut devoir être chargée immédiatement.

22. Utiliser le cache du navigateur

La documentation actuelle de PrestaShop sur l’optimisation de Nginx recommande de configurer des en-têtes de cache pour les fichiers statiques.

Les ressources statiques telles que :

• CSS ;
• JavaScript ;
• les polices ;
• JPG ;
• PNG ;
• WebP ;
• AVIF ;

peuvent souvent être mises en cache sur de longues périodes si le versionnement des URL est fiable.

Cela réduit le trafic répété et accélère la navigation.

23. Compresser les ressources textuelles

La compression Gzip ou Brotli peut réduire la taille de :

• HTML ;
• CSS ;
• JavaScript ;
• JSON ;
• XML.

Les formats d’images comme JPG, WebP et AVIF sont déjà compressés et ne tirent généralement aucun avantage notable d’une compression gzip générique.

Configurez la compression au niveau du serveur web ou du CDN.

24. Utiliser un CDN là où il est utile

Un CDN est utile pour :

• les images ;
• CSS ;
• JavaScript ;
• les polices.

Il peut réduire la latence pour les clients géographiquement éloignés et diminuer la charge du serveur d’origine.

Mais un CDN ne corrige pas une réponse PHP prenant 2 secondes.

Distinguez :

temps de génération côté serveur

de :

temps de livraison des ressources

lors du diagnostic des performances.

25. Faire attention au cache des pages complètes

La mise en cache des pages entières peut être puissante, mais le commerce électronique est personnalisé.

Le contenu peut varier selon :

• le client ;
• le groupe de clients ;
• le panier ;
• la devise ;
• la langue ;
• la boutique ;
• le pays ;
• les règles fiscales.

Une clé de cache qui ignore ces dimensions peut afficher des éléments incorrects :

• les prix ;
• les paniers ;
• les promotions ;
• les données des clients.

Ne sacrifiez pas l’exactitude au profit d’un score de benchmark.

26. Redis est un outil, pas un interrupteur magique

Redis peut être utile pour :

• le cache ;
• les sessions ;
• l’état des files de tâches ;
• les verrous distribués.

Mais ajouter Redis à un module mal conçu ne corrige pas ses mauvaises requêtes SQL.

Si 80 % du temps de réponse d’une page provient d’une requête coûteuse, optimisez d’abord cette requête.

Utilisez Redis lorsque les mesures montrent qu’il résout un problème précis.

27. Optimiser le serveur Web

La documentation de PrestaShop 9 contient des conseils spécifiques pour l’optimisation du serveur web.

Les domaines importants comprennent :

• keep-alive ;
• la prise en charge de HTTP/2 ou de protocoles plus récents ;
• la compression ;
• les en-têtes de cache ;
• les limites de connexions ;
• la charge de journalisation ;
• la configuration TLS.

Nginx comme Apache peuvent offrir de bonnes performances.

Ne changez pas de serveur web simplement parce qu’un message de forum affirme que l’un est toujours plus rapide.

28. Examiner les journaux d’accès

Les journaux d’accès sont indispensables pour le diagnostic et la sécurité.

Ils génèrent également des entrées/sorties disque.

Sur les boutiques à très fort trafic, journaliser en détail chaque ressource statique peut entraîner des opérations disque inutiles.

Stratégies possibles :

• des journaux distincts pour les ressources statiques ;
• une mise en mémoire tampon ;
• un échantillonnage lorsque cela convient ;
• une conservation plus courte ;
• la désactivation des journaux d’accès pour certaines ressources statiques sans importance.

Ne supprimez pas les journaux nécessaires aux enquêtes sur les incidents.

29. Déplacer les imports lourds hors des heures de pointe

Si un import fournisseur volumineux utilise :

• 80 % du CPU ;
• d’importantes écritures dans la base de données ;
• un traitement continu des images ;

les clients en ressentiront les effets.

Planifiez si possible les tâches lourdes pendant les périodes de faible trafic.

Si une synchronisation en temps réel est nécessaire, répartissez le travail en petits lots continus.

30. Utiliser des verrous pour les tâches cron

L’exécution en double des tâches cron peut anéantir les performances.

Une tâche cron lancée chaque minute peut démarrer une nouvelle instance alors que la précédente fonctionne encore.

Utilisez :

• des verrous du système de fichiers ;
• des baux en base de données ;
• des verrous Redis ;
• une attribution explicite des tâches.

Un verrou robuste doit expirer ou pouvoir être récupéré après une panne.

N’utilisez pas un indicateur booléen permanent qui risque de rester bloqué indéfiniment.

31. Séparer les tâches cron indépendantes

Un verrou global unique pour toutes les tâches automatisées peut limiter inutilement le débit.

Par exemple :

création de nouveaux produits
mise à jour des stocks
mise à jour des prix
téléchargement d'images

peuvent être indépendants.

Si la création est bloquée par une catégorie non mappée, les mises à jour du stock des produits existants devraient pouvoir continuer.

Définissez les verrous au niveau approprié du processus.

32. Surveiller la taille des files d’attente

Si une file reçoit les tâches plus rapidement que les processus ne les traitent, le système prend du retard.

Surveillez :

• le nombre en attente ;
• le nombre de tentatives ;
• le nombre d’échecs ;
• l’ancienneté de la plus vieille tâche en attente ;
• la vitesse de traitement.

Une file contenant 50 000 éléments n’est pas nécessairement problématique si elle en traite 20 000 par heure.

Une file de 500 éléments peut être très problématique si aucun n’a avancé depuis deux jours.

33. Limiter les nouvelles tentatives

Réessayez les opérations ayant échoué temporairement.

Exemples :

• un délai dépassé chez le fournisseur ;
• HTTP 503 ;
• un blocage temporaire de la base de données.

Ne recommencez pas indéfiniment les erreurs de validation permanentes.

Exemples :

• catégorie inconnue ;
• ensemble d’attributs de déclinaison dupliqué ;
• champ obligatoire invalide.

Après un certain seuil, placez l’élément dans un état bloqué ou en échec.

Cela évite que les enregistrements défectueux consomment indéfiniment des ressources.

34. Optimiser la recherche séparément

La recherche peut présenter des caractéristiques de performances très différentes de la navigation classique dans les produits.

Les grands catalogues peuvent nécessiter :

• une indexation optimisée de la recherche native ;
• des modules de recherche spécialisés ;
• des moteurs de recherche externes.

N’installez pas une grande plateforme de recherche si le catalogue et le comportement de recherche ne le justifient pas.

Mesurez séparément la latence et la pertinence des résultats de recherche.

35. Maintenir un Back Office rapide

L’optimisation des performances ne concerne pas uniquement les clients.

Un Back Office lent fait perdre du temps aux employés.

Mesurez :

• la page produit ;
• la grille de produits ;
• les commandes ;
• les pages de stock ;
• la configuration des modules ;
• les actions groupées.

Un module personnalisé qui ajoute une requête lente à chaque grille de commandes peut faire perdre des centaines d’heures de travail en un an.

36. Utiliser la pagination partout

N’affichez jamais des dizaines de milliers d’enregistrements dans un seul tableau du Back Office.

Utilisez :

• la pagination ;
• les filtres ;
• un tri sur index ;
• des requêtes côté serveur.

De même, les pages d’état doivent présenter des résumés et des éléments récents, sans charger tout l’historique de la file.

37. Garder les requêtes du tableau de bord légères

Les tableaux de bord sont ouverts fréquemment.

Ne calculez pas de statistiques coûteuses sur toute l’historique à chaque chargement de page.

Précalculez ou mettez en cache :

• les totaux ;
• les agrégats quotidiens ;
• les décomptes d’échecs récents.

Un tableau de bord opérationnel doit répondre rapidement aux questions sans devenir lui-même l’une des principales charges de la base de données.

38. Désactiver le mode debug en production

Le mode développeur est utile pour le dépannage.

Il ne doit pas rester activé sur une boutique en production.

Les paramètres de développement peuvent :

• exposer des erreurs sensibles ;
• désactiver la mise en cache ;
• augmenter la journalisation ;
• réduire les performances.

Utilisez le mode production pour le fonctionnement normal.

39. Surveiller les performances réelles des utilisateurs

Les outils de tests synthétiques sont utiles.

La surveillance des utilisateurs réels montre ce que vivent réellement les clients.

Suivez les indicateurs selon :

• l’appareil ;
• le pays ;
• le type de page ;
• le navigateur.

Un test sur ordinateur avec une connexion rapide peut masquer une page de catégorie mobile lente.

40. Mettre en place des alertes de performance

Définissez des seuils pertinents pour l’entreprise.

Exemples :

• TTFB du produit supérieur à 800 ms ;
• file PHP-FPM au-dessus d’un seuil défini ;
• CPU de la base de données supérieur à 90 % pendant cinq minutes ;
• espace libre disque inférieur à 15 % ;
• la durée d’une tâche cron double ;
• l’élément le plus ancien de la file d’import dépasse une heure.

Les alertes doivent permettre d’agir.

Évitez de déclencher des alertes à chaque fluctuation mineure.

Exemple de workflow d’optimisation de PrestaShop 9

Un projet d’optimisation concret pourrait se dérouler ainsi :

Phase 1 — Mesurer

Mesurez :

TTFB de la page d'accueil: 900 ms
TTFB de la catégorie: 1.8 s
TTFB du produit: 1.2 s
TTFB du checkout: 800 ms

Phase 2 — Profiler

Découvrez :

Requête de catégorie: 900 ms
Appel API du module: 350 ms
Traitement PHP: 300 ms

Phase 3 — Corriger le plus grand goulot d’étranglement

Ajoutez un index de base de données justifié par les données.

Nouveau TTFB des pages de catégorie :

650 ms

Phase 4 — Corriger l’appel distant du module

Mettez en cache les données distantes pendant cinq minutes.

Nouveau TTFB des pages de catégorie :

320 ms

Phase 5 — Optimiser les images

Réduisez de 40 % le volume initial des images transférées.

Les améliorations disposent désormais de preuves mesurables.

Exemple d’architecture pour un grand catalogue

Pour une grande boutique automatisée :

                        ┌──────────────┐
Clients ─────────────▶│ Nginx / CDN  │
                        └──────┬───────┘
                               │
                        ┌──────▼───────┐
                        │ PHP-FPM      │
                        │ PrestaShop 9 │
                        └──────┬───────┘
                               │
                     ┌─────────▼─────────┐
                     │ MySQL / MariaDB   │
                     └───────────────────┘

Arrière-plan :
Flux fournisseur → File d'attente → Processus produits
                         ├─ processus de stock
                         ├─ processus de prix
                         └─ processus d'images

Cela sépare les requêtes interactives des traitements lourds en arrière-plan.

Liste de contrôle des performances

PHP

• Version PHP compatible
• OPcache activé
• OPcache suffisamment dimensionné
• Processus PHP-FPM mesurés
• Mode production activé
• Versions PHP web et CLI vérifiées

Base de données

• Journal des requêtes lentes examiné
• Requêtes coûteuses analysées avec EXPLAIN
• Index basés sur les charges réelles
• Tables d’historique surdimensionnées vérifiées
• Grandes mises à jour effectuées par lots

Modules

• Hooks globaux analysés
• Appels distants retirés des chemins critiques
• Modules inutilisés supprimés
• Tableaux de bord coûteux mis en cache

Images

• WebP/AVIF activé selon les besoins
• Types d’images inutilisés supprimés
• Dimensions adaptatives utilisées
• Chargement différé des images hors écran
• Régénération exécutée par tâches contrôlées

Serveur

• SSD/NVMe
• RAM libre suffisante
• Pas de swap en charge normale
• Compression activée
• En-têtes de cache du navigateur configurés
• CDN envisagé pour les ressources statiques

Automatisation

• Les tâches cron utilisent des verrous
• Les tâches lourdes sont découpées en lots
• L’état des files est surveillé
• Les tentatives sont limitées
• Les traitements lourds sont séparés du trafic client

Surveillance

• Latence HTTP surveillée
• Saturation des processus PHP surveillée
• Base de données surveillée
• Consommation de disque et d’inodes surveillée
• Durée des tâches cron surveillée
• Alertes configurées

Questions fréquentes

Quel est le moyen le plus rapide d’accélérer PrestaShop 9 ?

Mesurez d’abord. L’amélioration la plus rentable consiste généralement à corriger le plus grand goulot d’étranglement réel : SQL, module, images, saturation PHP-FPM ou tâche en arrière-plan.

PrestaShop 9 prend-il en charge WebP et AVIF ?

Oui. La prise en charge native de WebP et AVIF a été introduite avec PrestaShop 9.

Quelle version PHP est la meilleure pour PrestaShop 9 ?

Le tableau de compatibilité officiel actuel recommande PHP 8.4 pour PrestaShop 9.0 et PHP 8.5 pour PrestaShop 9.1.

Redis rendra-t-il PrestaShop 9 plus rapide ?

Il peut aider certaines charges de cache, sessions, files de tâches ou verrouillage. Il ne corrige pas automatiquement les lenteurs PHP ou SQL.

Faut-il ajouter davantage de cœurs CPU ?

Uniquement si le CPU est le goulot d’étranglement. Si la base de données attend un stockage lent ou si PHP attend une API distante, plus de cœurs peuvent apporter peu d’amélioration.

Pourquoi la boutique n’est-elle lente que pendant les imports ?

L’import rivalise probablement avec le trafic web pour le CPU, la RAM, la base de données ou les entrées/sorties disque. Réduisez la concurrence, fractionnez le travail, modifiez les horaires ou séparez les processus.

Comment accélérer une boutique de 100 000 produits ?

Concentrez-vous sur les imports incrémentiels, les empreintes des sources, les requêtes indexées, les files de taille limitée, le traitement des images, le réglage de la base de données et la suppression des écritures produit inutiles.

Nginx est-il plus rapide qu’Apache ?

Les deux peuvent offrir de bonnes performances. La configuration et le comportement de l’application comptent généralement plus que la marque du serveur.

Faut-il vider le cache toutes les heures ?

Non. Invalider constamment les caches utiles peut réduire les performances. Invalidez-les uniquement lorsque cela est nécessaire.

À quelle fréquence faut-il contrôler les performances ?

Surveillez en continu les principaux indicateurs et réalisez des audits approfondis après les grandes versions, les modifications des modules ou de l’infrastructure et les fortes augmentations du catalogue.

Guides et ressources connexes sur PrestaShop 9

• 10 méthodes pratiques pour accélérer PrestaShop 9
• guide SEO pour PrestaShop 9
• configuration requise pour PrestaShop 9

Quand les symptômes de lenteur sont en réalité des défaillances applicatives

Si des requêtes lentes ou instables se terminent par des erreurs 500 intermittentes, utilisez la procédure sécurisée de diagnostic des erreurs HTTP 500 en production. Crash Snapshot Lite peut enregistrer les incidents applicatifs pris en charge sans laisser le mode débogage complet activé.