Performances PrestaShop : mesurer, diagnostiquer et améliorer votre boutique

Ce que nous ferions en premier

La bonne correction dépend de la boutique existante : son thème, ses modules, ses intégrations, les données du catalogue, l’hébergement et le trafic. Deux boutiques ayant le même score de vitesse peuvent nécessiter des modifications opposées. Nous reproduirions la page lente, séparerions le temps serveur du travail du navigateur et identifierions les requêtes, appels de modules ou scripts qui consomment ce temps. Si le SQL domine, testez une modification ciblée de requête ou d’index en préproduction avant de changer les réglages du serveur. Si la base attend le stockage ou se dispute la mémoire, évaluez d’abord la charge de l’hébergement. Si le document arrive rapidement mais que la page reste lente à utiliser, travaillez sur les images, le CSS et le JavaScript.

La démarche pratique est la même pour la plupart des corrections : reproduisez le problème sur une copie de préproduction isolée avec des données réalistes, répétez-y la modification avec un moyen de retour testé, déployez-la comme un changement planifié et refaites les mêmes mesures sur la boutique en production. Comparez des requêtes équivalentes avant et après chaque modification, afin que chaque résultat puisse lui être attribué.

Choisir le premier test selon le symptôme

Demandez à votre développeur une trace de requête précisant les traitements coûteux, leur responsable, une modification proposée et la comparaison avant/après. Une capture de la taille de la base ou un score de vitesse isolé ne constitue pas cette preuve.

Si vous souhaitez que cette attribution soit faite pour votre boutique, le PrestaShop Speed & Core Web Vitals Audit suit les requêtes réelles à travers le serveur, la base de données et le navigateur, et fournit un plan de corrections classé par priorité ; les modifications de code, la configuration du serveur et les achats d’hébergement sont hors de son périmètre et font l’objet d’un chiffrage séparé.

Établir une référence et lire les bons indicateurs

Testez la page d’accueil, une catégorie très fréquentée, un produit, le panier et la commande, ainsi que tout écran lent du back-office. Incluez la recherche et les filtres s’ils comptent pour votre boutique. Consignez l’URL, la version du cœur et de PHP, le thème, les modules activés, l’appareil, la localisation, le profil de connexion, l’état du client, la langue, la devise, l’état du consentement, l’état du cache et les conditions de trafic.

Utilisez une copie de préproduction avec des données de catalogue réalistes pour les modifications contrôlées et le profilage. Effectuez plusieurs tests comparables et conservez la médiane et la dispersion. Comparez séparément un nouveau visiteur, un navigateur déjà venu et un client connecté, et incluez des requêtes sans cache : un accès rapide au cache public ne prouve pas que le panier ou la commande sont rapides. Une connexion au back-office n’active pas automatiquement le profilage et n’accélère pas les requêtes du front-office.

Les objectifs Core Web Vitals actuels sont un LCP inférieur ou égal à 2,5 secondes, un INP inférieur ou égal à 200 millisecondes et un CLS inférieur ou égal à 0,1, évalués au 75e percentile séparément sur mobile et ordinateur. INP a remplacé FID en mars 2024.

LCP concerne le plus grand contenu visible admissible, souvent une image ou un bloc de texte. INP concerne la réactivité aux interactions. CLS concerne les déplacements inattendus de la mise en page. Identifiez l'élément, l'événement ou le déplacement réel plutôt que de déduire une cause du seul indicateur.

Le score Performance de Lighthouse est un indicateur composite de laboratoire, pas votre taux de conversion ni une prédiction de classement. Son audit de chargement comprend Total Blocking Time ; il ne note pas directement l'INP terrain lors d'un chargement de page ordinaire. Accessibilité, Bonnes pratiques et SEO sont des catégories d'audit distinctes, pas une certification complète de ces sujets. Lisez l'explication du score et les constats individuels.

Une installation GA4 standard ne collecte pas automatiquement les Core Web Vitals et ne fournit pas les anciens rapports de vitesse Universal Analytics. Ajoutez une instrumentation web-vitals ou RUM explicite, avec les événements et rapports nécessaires. Segmentez par type de page, appareil et marché, avec les contrôles de confidentialité appropriés.

Conservez les mesures commerciales à côté des mesures de vitesse. Le rapport retail 2017 d'Akamai associait, dans son étude, un retard de 100 millisecondes à une baisse de conversion de 7 %. Ce résultat historique n'est pas une formule de prévision du gain de votre boutique.

Isoler la copie de préproduction et préparer un retour arrière

Isolez la copie de préproduction avant que son application restaurée, ses processus de traitement ou ses tâches planifiées ne s’exécutent. Donnez-lui une base de données distincte, des destinations de paiement et d’intégration en sandbox, une boîte de réception de test et un accès externe contrôlé. Restreignez l’accès aux données clients copiées, afin que les tests de performance et de cache ne puissent pas déclencher de messages à de vrais clients ni d’opérations commerciales réelles.

Avant de supprimer des enregistrements, d’ajouter des index, de reconstruire des tables ou de changer le moteur ou la configuration de la base, réalisez des sauvegardes concordantes des fichiers et de la base, testez une restauration en préproduction et documentez le retour arrière. Répétez la modification elle-même, en tenant compte des verrous, de l’espace de stockage nécessaire et de l’interruption de service, afin que le déploiement en production suive une procédure connue à une heure planifiée. Demandez à l’hébergeur de gérer la configuration lorsque vous ne maîtrisez pas le serveur.

Gardez la copie proche de la production : mêmes versions de PrestaShop, de PHP et de la base de données, même thème et mêmes modules, avec des données représentatives. Le matériel de préproduction correspond rarement au serveur de production : utilisez-le pour comparer avant et après, puis confirmez le gain sur la boutique en production avec les mêmes requêtes de référence.

Séparer connexion, travail serveur et travail navigateur

Le TTFB observé côté client comprend des opérations précédant l'arrivée du document : DNS, établissement de connexion, TLS, redirections et trajet requête/réponse. Ce n'est pas un chronomètre direct d'exécution PHP. Waiting dans DevTools mesure un autre intervalle. Utilisez la décomposition temporelle du TTFB pour interpréter votre outil.

Cet exemple shell récupère une page et affiche les temps cumulés de curl. Remplacez l'URL d'exemple par une URL réelle de boutique :

url='https://example.com/'
curl --silent --show-error --output /dev/null   --write-out 'dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n'   "$url"

Ces valeurs sont mesurées depuis le début du transfert : ce ne sont pas des durées indépendantes à additionner. Vérifiez les redirections séparément ou consignez-les explicitement. Répétez avec des états de cache et emplacements géographiques contrôlés.

Un script navigateur récupéré après le premier octet du document ne peut pas retarder ce premier octet. Il peut retarder le rendu, les interactions ou des requêtes ultérieures. Un module PHP effectuant un appel API distant avant d'envoyer le HTML peut retarder la réponse serveur. La cascade réseau du navigateur ne permet pas à elle seule d'identifier ce module PHP.

Utiliser le profileur approprié

Pour le profilage historique de PrestaShop, activez _PS_DEBUG_PROFILING_ dans config/defines.inc.php sur une copie de préproduction à accès restreint :

define('_PS_DEBUG_PROFILING_', true);

Chargez les types de pages concernés et inspectez temps SQL, appels répétés, hooks et mémoire dans le périmètre du rapport. Remettez ensuite l'indicateur à false. _PS_MODE_DEV_ est un interrupteur distinct de développement et de signalement des erreurs. Ce n'est ni l'interrupteur de profilage historique ni la politique de compilation Smarty.

La barre Symfony couvre les requêtes traitées par le noyau Symfony. Son panneau Doctrine ne prouve pas une couverture complète du SQL historique de Db. Confirmez les chemins de base de données et de hooks instrumentés avant d'attribuer tout le travail à un module.

Une vérification d'URL publique permet d'évaluer l'accessibilité et les temps du navigateur. Les nombres de requêtes internes, taux de succès du cache et temps des modules nécessitent un accès autorisé ou une instrumentation. Même de simples consultations peuvent créer des journaux, données d'analyse ou entrées de cache : convenez donc du périmètre et du volume des requêtes de test.

Vérifier les paramètres de production sans les confondre

Dans Paramètres avancés → Performances, examinez chaque paramètre séparément et testez son effet. Laissez le mode développement et le profilage désactivés sur la boutique publique de production.

Le JavaScript différé ou asynchrone et les ressources distantes peuvent rester hors du regroupement CCC normal. Des balises brutes émises par un hook peuvent contourner la gestion des fichiers. Si une modification CCC casse un comportement, isolez le paquet ou la dépendance concerné en préproduction et corrigez son enregistrement ; ne laissez pas un parcours de commande défaillant en service.

Désactivez les modules suspects en préproduction et comparez les mesures. Les contrôles d'exécution du cœur excluent les hooks ordinaires des modules désactivés. Désinstallez uniquement les modules réellement inutiles après avoir examiné leur comportement de désinstallation et conservé les paramètres ou données nécessaires.

Choisir un PHP compatible et inspecter OPcache et l'hébergement

Utilisez une branche PHP maintenue et prise en charge par votre version exacte de PrestaShop, votre thème et vos modules. La matrice PrestaShop 9 actuelle recommande PHP 8.4 pour 9.0 et PHP 8.5 pour 9.1. Vérifiez aussi les dates de maintenance de PHP. Le support amont de PHP 8.1 a pris fin le 31 décembre 2025. Ne passez pas PrestaShop 1.7.8 à PHP 8 comme solution générique d'accélération.

Confirmez qu'OPcache est actif pour le PHP Web, et pas seulement pour le binaire en ligne de commande. Il stocke le bytecode compilé pour éviter de réanalyser les fichiers PHP à chaque requête. JIT est une option distincte ; ne supposez pas qu'elle explique les performances de votre boutique ou doive être activée.

1. Inspectez mémoire utilisée et libre, chaînes internées, scripts et clés en cache sous une charge représentative.
2. Vérifiez cache_full, la mémoire gaspillée et les compteurs de redémarrage pour manque de mémoire, hachage et actions manuelles via opcache_get_status() si l'hébergeur le permet.
3. Dimensionnez mémoire et capacité de scripts selon ces relevés. Un cache plein peut cesser d'accepter des scripts et programmer un redémarrage ; il ne se comporte pas comme un simple cache supprimant continuellement des entrées individuelles.
4. Documentez le comportement au déploiement. Avec opcache.validate_timestamps=1, la vérification des horodatages suit sa configuration, notamment opcache.revalidate_freq. Sans validation, les fichiers modifiés nécessitent une invalidation explicite ou une réinitialisation ou un redémarrage du cache PHP Web concerné.

Une réinitialisation CLI ne vide normalement pas l'OPcache du serveur Web. Attendre soixante secondes n'est pas une procédure universelle. Utilisez les paramètres OPcache et les champs d'état pour définir une politique contrôlée, et gardez les points de diagnostic privés.

Pour PHP-FPM, inspectez les processus occupés, files d'attente, pm.max_children, mémoire des processus et journaux de dépassement de délai. Davantage de processus peut aggraver la pression mémoire ou la contention de la base. Vérifiez charge CPU et temps volé, swap, attente d'E/S disque et latence de la base aux heures chargées. Des outils comme free -m, vmstat 1 5 et iostat -xz 1 5 aident votre administrateur à corréler les symptômes.

Ne dimensionnez pas l'hébergement selon les seules commandes quotidiennes. La navigation simultanée, les filtres, imports, tâches cron, déclinaisons et opérations de commande comptent. Comparez ressources et temps de réponse sous la charge de pointe attendue avant de changer d'hébergeur ou d'ajouter de la capacité. Consultez l'hébergement PrestaShop.

Lorsque les mesures désignent des limites de capacité ou de restauration, le PrestaShop Hosting & Infrastructure Audit examine la charge et rend un avis écrit sur l’amélioration de l’hébergement actuel ou une migration ; les travaux sur le serveur et la migration elle-même sont distincts. Choisissez le parcours de migration en fonction des modules, intégrations, thème et données existants. Pour un changement d’hébergeur qui conserve la configuration actuelle, testez une copie isolée sur le nouvel hébergement. Si l’évaluation conclut à une reconstruction de la boutique, le parcours sûr habituel est une installation cible propre en préproduction, des composants compatibles et une migration des données répétée. Planifiez la synchronisation finale des données et la bascule, et documentez comment un retour arrière préserverait les commandes passées après le lancement.

Trouver le SQL lent et interpréter EXPLAIN

Demandez d’abord à l’administrateur de la base de consigner le moteur et la version exacts : les réglages MySQL et MariaDB ne sont pas interchangeables. Utilisez la surveillance des requêtes existante lorsqu’elle est disponible. Sinon, activez le journal des requêtes lentes de la base avec un seuil choisi d’après les temps des requêtes et la charge. Par exemple, une courte fenêtre de diagnostic pourrait commencer par :

[mysqld]
slow_query_log = 1
long_query_time = 0.5

Faites configurer par l’administrateur de la base une destination de journal autorisée, une limite de stockage, une rotation, un contrôle d’accès et une date de suppression. Le texte des requêtes peut contenir des données personnelles. Recueillez un trafic et des tâches planifiées représentatifs de la période chargée concernée plutôt qu’une durée fixe identique pour toutes les boutiques, puis arrêtez ou ajustez la journalisation détaillée selon les besoins. Journaliser les requêtes sans index et filtrer selon un nombre minimal de lignes examinées peut aider, mais peut aussi créer du bruit et du travail supplémentaire, ou exclure de petites requêtes pertinentes ; le parcours d’une petite table n’est pas automatiquement une anomalie. Consultez le comportement du journal de la base pour votre version.

Résumez un journal avec mysqldumpslow ou pt-query-digest lorsque ces outils sont installés et prennent en charge votre format de journal. Remplacez le chemin par le fichier réel et conservez les rapports dans un emplacement à accès restreint :

mysqldumpslow -s t -t 20 /path/to/slow-query.log
pt-query-digest /path/to/slow-query.log

Classez par temps total, nombre d’appels, lignes examinées et temps de verrouillage, ainsi que par exécution individuelle la plus lente : une requête modeste répétée peut coûter davantage sur une page ou une période chargée qu’une requête plus lente unique. Lisez le mode de tri du résumé avant d’interpréter son classement, car une liste triée par durée moyenne ne répond pas à la même question qu’une liste triée par temps cumulé. Relevez la requête exacte, ses paramètres, le volume de données et le contexte de la boutique avant l’optimisation, et anonymisez les rapports avant de les partager.

Le seuil de capture masque aussi du travail : des requêtes répétées en dessous de ce seuil peuvent être absentes alors que leur coût cumulé compte. Par exemple, des recherches d’avis peuvent chacune se terminer sous le seuil mais s’exécuter à nouveau pour chaque vignette produit, tandis qu’un export planifié ajoute une seule requête lente isolée sans rapport avec cette page. Corrélez la requête lente avec le profilage de l’application, en utilisant une capture limitée plutôt qu’une journalisation sans restriction, et attribuez les deux motifs à leurs appelants avant de décider quelle modification améliorera la requête du client.

Utilisez la requête réelle issue de la requête HTTP lente, avec son contexte de boutique, de langue et de client, et examinez son plan sur une copie de préproduction aux données représentatives. Cet exemple de catégorie en lecture seule utilise le préfixe par défaut, la boutique 1, la langue 1 et la catégorie 42. Il montre la forme, pas la requête générée par votre module de liste ou de filtres installé. Il lit le prix et le statut propres à la boutique dans product_shop et limite les données traduites à la même boutique :

EXPLAIN SELECT p.id_product, pl.name, ps.price
FROM ps_product p
JOIN ps_product_shop ps ON ps.id_product = p.id_product
JOIN ps_product_lang pl ON pl.id_product = p.id_product
  AND pl.id_shop = ps.id_shop
JOIN ps_category_product cp ON cp.id_product = p.id_product
WHERE ps.id_shop = 1 AND pl.id_lang = 1
  AND cp.id_category = 42 AND ps.active = 1
ORDER BY ps.date_add DESC;

Un EXPLAIN ordinaire estime un plan sans exécuter la requête. Les commandes d’analyse fondées sur l’exécution peuvent l’exécuter ; vérifiez le comportement de la commande pour votre moteur et votre version avant de l’utiliser.

Examinez les index existants avant d’en ajouter un. Choisissez l’ordre d’un index composite selon les prédicats d’égalité, les plages, le tri et la réutilisation du préfixe le plus à gauche. Placer la colonne la plus sélective en premier n’est pas une règle universelle. Les index ajoutés consomment de l’espace et du travail d’écriture : mesurez le gain en lecture face au coût en écriture. Évaluez les changements de schéma en préproduction, répétez à la fois leur installation et leur annulation, et planifiez les verrous et l’espace temporaire.

Une table d’avis interrogée par produit, statut de validation et ordre d’affichage montre pourquoi la conception d’un index exige de connaître tout le schéma d’accès. Un index adapté à cette recherche du front-office peut ne pas convenir à une liste d’administration filtrée par boutique. Demandez des plans mesurés pour les deux, ainsi que l’effet sur les imports d’avis et les écritures de modération, avant de valider l’index.

Exemple d’investigation : une catégorie filtrée lente

1. Enregistrez les filtres sélectionnés, l’ordre de tri, la boutique, la langue, la devise et l’état du client. Reproduisez la requête sans cache sur des données de préproduction représentatives.
2. Identifiez les requêtes de sélection des produits, de comptage des facettes, de calcul des prix et des ajouts des modules. Distinguez les appels répétés des requêtes individuellement coûteuses.
3. Examinez les jointures, restrictions, index existants et le plan réels du motif coûteux. L’exemple de catégorie ci-dessus ne montre que la syntaxe ; ce sont les requêtes du module de filtres lui-même qui tranchent ce cas.
4. Proposez une modification de cette requête, un index candidat ou un changement du travail répété du module responsable. Répétez l’opération avec la sauvegarde concordante et le plan de retour arrière déjà préparés.
5. Répétez les mêmes actions de filtrage et de tri. Comparez la durée de la requête, la fréquence des requêtes SQL et les plans, puis vérifiez les produits retournés, les nombres par facette et les prix clients.

Examiner les prix, facettes et recherches répétées

Prix spécifiques et règles panier

La sélection des prix spécifiques dépend du produit, de la déclinaison, de la boutique, de la devise, du pays, du groupe, du client, du panier, de la quantité et des dates, avec des règles de priorité et d’ordre. Un palier de quantité doit s’appliquer à la quantité demandée ; from_quantity >= 1 n’est pas un critère de sélection correct. Mettez entre guillemets obliques les colonnes de date réservées, `from` et `to`, dans le SQL de diagnostic. Profilez l’appel natif de calcul des prix plutôt que de remplacer sa sélection par une recherche incomplète, et ne collez pas en production une requête ou un index de prix provenant d’une autre boutique : un exemple incomplet peut produire un résultat commercial erroné.

Examinez les promotions inactives ou expirées selon votre politique commerciale. Les sélections de règles panier du cœur concernées filtrent déjà l'état actif et les dates : désactivation et date passée ne sont donc pas toutes deux nécessaires pour exclure une règle. Préservez celles encore nécessaires aux commandes, rapports ou campagnes valides.

Mesurez l’évaluation des règles avec des paniers représentatifs. Avant de regrouper des règles qui se chevauchent, faites confirmer par le marchand les combinaisons et le comportement d’expiration voulus, puis testez à nouveau remises et totaux avec des paniers éligibles et non éligibles.

Comptages des facettes et recherche

Profilez l’implémentation de recherche à facettes installée et ses requêtes de comptage réelles. Ne déduisez pas une requête par valeur de filtre possible. Comparez les comptages demandés avec les filtres réellement utilisés par les clients, et testez si la réduction des facettes inutilisées, la correction d’un index ou le cache propre à l’intégration aide. Supprimer un filtre utile simplement pour améliorer un benchmark modifie le parcours d’achat.

Utilisez l'opération d'indexation prise en charge lorsqu'une reconstruction est nécessaire. PrestaShop 9.1 a ajouté une commande de recherche avec des options de reconstruction complète et de périmètre boutique :

php bin/console prestashop:search:index --full --shop-id=1

Consultez l'aide de la commande installée avant de l'utiliser sur une autre version. L'indexation de recherche du back-office est l'alternative sur les versions dépourvues de cette commande. Un moteur externe peut toujours avoir des consommateurs natifs ou des mécanismes de secours ; ne videz pas les tables de recherche natives simplement parce qu'un autre moteur est installé.

Travail N+1

Un hook de liste interrogeant les avis pour chaque produit répète le travail à mesure que le résultat augmente. Si la fonction le permet, collectez les ID produit, récupérez les données agrégées dans une seule requête au périmètre correct et réutilisez-les au rendu. Incluez appartenance à la boutique et conditions de visibilité, validez les ID et gérez une liste vide. Comparez le résultat affiché autant que le nombre de requêtes.

Demandez une proposition de traitement groupé expliquant comment les ID produit de la liste sont collectés, comment le hook d’affichage réutilise les résultats et pourquoi cette réutilisation ne peut pas mélanger les boutiques ou des valeurs propres à un client. Vérifiez le hook exact et les données produit disponibles pour le module et la version installés. Gardez la correction dans le module responsable ou ses points d’extension pris en charge, afin qu’elle survive aux mises à jour. Un nombre de produits, de règles ou de modules installés ne justifie pas automatiquement une suppression ou un remplacement.

Pour le travail avec des API distantes, comparez d’abord le temps passé en base avec les attentes d’API externes : un appel lent vers un fournisseur ou un ERP appelle une autre correction qu’un index manquant. Consignez le comportement en cas de délai dépassé et d’échec. Mettez en cache et actualisez les données en dehors de la requête du visiteur lorsque leurs exigences de fraîcheur le permettent. Les tarifs de livraison, le stock ou les vérifications de paiement au moment de la commande peuvent nécessiter des données à jour : ne supprimez donc pas des vérifications en temps réel nécessaires dans le seul but d’améliorer un benchmark.

Régler la mémoire et la durabilité de la base selon les mesures

Le buffer pool InnoDB met en cache les pages de données et d’index. Dimensionnez-le en tenant compte du système d’exploitation, des processus PHP, de Redis et des tampons de connexion de la base : un pool plus grand peut nuire à la boutique si le reste du serveur commence à utiliser le swap. Un serveur de base dédié et un serveur web et base combiné nécessitent des budgets différents, pas un pourcentage fixe de la mémoire installée. La taille de la base ne prouve pas à elle seule que l’ensemble de données actif tient en mémoire.

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';
SHOW GLOBAL STATUS LIKE 'Slow_queries';
SHOW GLOBAL STATUS LIKE 'Created_tmp_tables';
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';

Prenez deux échantillons sur un intervalle représentatif. Utilisez les variations entre échantillons pour les compteurs cumulés de lectures du buffer pool, de requêtes lentes et de tables temporaires. Lisez Threads_connected comme le nombre actuel de connexions et Max_used_connections comme le nombre simultané le plus élevé depuis le démarrage ou la réinitialisation concernée ; leurs différences ne mesurent pas la charge de connexions. Si la variation des demandes de lecture n’est pas nulle, hit_ratio_percent = (1 - delta_reads / delta_read_requests) * 100, où delta_reads est la variation de Innodb_buffer_pool_reads et delta_read_requests celle de Innodb_buffer_pool_read_requests. Écartez les intervalles qui englobent un redémarrage du serveur ou une réinitialisation des compteurs, et comparez des charges équivalentes plutôt que des totaux recueillis depuis des dates de redémarrage différentes. Un ratio élevé peut coexister avec des requêtes coûteuses, et un ratio plus faible ne justifie pas automatiquement davantage de RAM. Corrélez lectures physiques, latence du stockage et pression mémoire ; un cache plus grand peut améliorer les lectures répétées sans corriger une écriture longue ou une attente de verrou.

Conservez innodb_flush_log_at_trx_commit=1 comme réglage durable normal. Le passer à 2 peut faire perdre des transactions récemment validées après un plantage du système d’exploitation ou une coupure de courant. N’échangez pas la durabilité des commandes contre un gain d’optimisation non mesuré ; toute proposition d’affaiblir le vidage à la validation exige une décision commerciale explicite sur la perte de données et la restauration.

Utilisez une configuration propre à votre version. MySQL 8 a supprimé le cache de requêtes. MariaDB conserve sa propre implémentation, mais testez la contention et le bénéfice pour votre charge avant de l’activer, et ne changez pas de moteur pour la seule vitesse. MariaDB 10.6 a supprimé innodb_buffer_pool_instances. MySQL 8.0.30 a introduit innodb_redo_log_capacity à la place des anciennes pratiques de dimensionnement du redo log ; consultez la documentation actuelle du redo log et les variables prises en charge par votre serveur.

Ne collez pas sur chaque serveur des tailles universelles de threads d’E/S, de connexions, de tampons de tri ou de tables temporaires. Les allocations par connexion et la concurrence peuvent épuiser la mémoire, et augmenter en même temps les tampons et les limites de connexions multiplie ce risque sous charge. Gardez Performance Schema disponible pour le diagnostic, sauf si des contraintes mesurées justifient un changement ; réglez l’instrumentation plutôt que de la désactiver par principe en production. N’utilisez ses requêtes de surveillance que lorsque l’instrumentation nécessaire est disponible. Examinez Table_locks_waited avec les diagnostics de verrous propres au moteur ; ce n’est pas une mesure complète des attentes de verrous de lignes InnoDB.

Pour chaque modification proposée, demandez à l’hébergeur le réglage actuel, la contrainte mesurée, la valeur proposée, le bénéfice attendu et la procédure d’annulation. Sur un serveur partagé avec PHP, une augmentation du buffer pool doit laisser de la place aux processus PHP chargés et aux imports. Sur un serveur de base dédié, la latence du stockage, les connexions simultanées et les sauvegardes comptent toujours.

Nettoyer les tables uniquement selon une politique de conservation convenue

Mesurez la croissance des tables et la conservation séparément de l’optimisation des requêtes, et examinez cette croissance au regard du coût réel des requêtes et de la taille des sauvegardes. L’activité des visiteurs et la création de paniers dépendent des fonctions activées et des comportements. Certains chemins de nettoyage spécifiques existent déjà, notamment le nettoyage des pages de connexion. Utilisez le guide de maintenance de la base de données pour une conservation des paniers, invités et journaux qui tient compte des dépendances.

Les anciennes données de visite, les recherches, les journaux d’emails, les paniers abandonnés et les règles de prix expirées peuvent être candidats, mais vérifiez d’abord les dépendances liées aux rapports, au service client, à la relance de paniers et aux intégrations, et convenez de ce qu’il faut conserver avec les personnes qui utilisent ces enregistrements. Un ancien panier sans commande n’est pas automatiquement supprimable sans risque. La conservation est une décision commerciale, pas un nombre de jours universel.

Une fois les sauvegardes, un passage testé en préproduction et le retour arrière prêts, Database Cleanup propose des domaines sélectionnables, des durées de conservation, un aperçu des lignes et une simulation avant suppression. Il ne touche pas aux commandes, comptes clients, produits en ligne et paniers liés à des commandes, et limite le nettoyage multiboutique aux boutiques sélectionnées. Si le problème inclut aussi des images orphelines et des fichiers inutilisés, Cleanup Revolution ajoute ces domaines, des nettoyages avec aperçu, des réglages de conservation et un plafond de lignes par exécution. Les images qu’il supprime restent récupérables dans une corbeille datée pendant une durée choisie, ce qui ne garantit pas la récupération de chaque enregistrement supprimé, et les comptes sans commande nécessitent une double confirmation distincte. Choisissez l’outil selon le périmètre de maintenance plutôt que d’installer les deux par défaut.

Prévisualisez les candidats exacts, validez un premier lot contrôlé, puis vérifiez le comportement du front-office, le nombre de candidats et l’historique d’exécution avant de planifier la suite. Les domaines protégés d’un outil de nettoyage ne remplacent pas votre propre sauvegarde. InnoDB peut réutiliser l’espace libéré, mais supprimer des lignes ne rend pas forcément l’espace au système d’exploitation, et reconstruire une table peut nécessiter de l’espace supplémentaire et des verrous. Un OPTIMIZE TABLE systématique après chaque nettoyage est inutile, et vider l’index de recherche n’est pas de l’entretien ; si la recherche doit être reconstruite, utilisez l’opération d’indexation prise en charge par votre version.

Réduire le travail des images, styles et scripts JavaScript

Inspectez l'élément LCP réel et sa chaîne de requêtes. Adaptez les dimensions des images générées à leur taille d'affichage, à la densité de l'appareil et aux besoins de zoom. Il n'existe ni plafond universel de taille d'image source ni économie de format garantie. Réservez les dimensions des images pour réduire les déplacements et chargez rapidement les images visibles prioritaires en différant celles hors écran lorsque c'est approprié.

Régénérez les miniatures concernées après modification des types d'images. Sauvegardez d'abord les images. Dans PrestaShop 9.1+, php bin/console prestashop:thumbnails:regenerate products --delete supprime les miniatures produit existantes avant de les reconstruire. Exécutez les reconstructions importantes hors pointe. Pour reprendre une exécution interrompue, omettez --delete afin de conserver les fichiers existants et de générer les fichiers manquants. Les versions précédentes nécessitent leur outil de back-office pris en charge ou un outil fourni séparément. L'enregistrement WebP est apparu en 8.0 ; la génération multiformat, dont AVIF, en 8.1 comme fonction expérimentale. Confirmez la prise en charge du serveur et du thème et inspectez le format livré au navigateur. Consultez l'optimisation des images.

Le CSS critique est l'ensemble des styles nécessaires à la fenêtre initiale. Générez-le pour des pages et états responsive représentatifs, intégrez le sous-ensemble validé dans la page et chargez correctement le CSS restant. Préservez les styles de secours et testez menus, bannières de consentement, variantes linguistiques et contenu inséré dynamiquement. Une extraction incomplète peut provoquer clignotements, déplacements ou commandes manquantes.

Réduisez le CSS et le JavaScript inutilisés à partir de mesures couvrant tous les états nécessaires. La couverture d'une seule fenêtre initiale ne prouve pas qu'un sélecteur peut être supprimé sans risque. Comparez un carrousel à une bannière principale statique si son comportement apporte peu, puis testez le résultat réel.

Pour les scripts externes classiques, defer reporte l'exécution à la fin de l'analyse en conservant l'ordre des scripts différés ; async convient aux opérations indépendantes dont l'ordre de fin peut varier. Aucun ne supprime le coût d'exécution. L'option d'enregistrement JavaScript de PrestaShop est au pluriel :

['position' => 'bottom', 'priority' => 200, 'attributes' => 'defer']

Transmettez ces options à registerJavascript() pour enregistrer un fichier dont vous avez la maîtrise. Enregistrez-le uniquement sur les pages qui en ont besoin. Testez les dépendances et toutes les interactions concernées après modification de l'ordre ou du moment d'exécution. Regroupez les outils de suivi en double et contrôlez correctement les services non essentiels.

Auditer les polices, icônes et le thème

1. Filtrez Réseau sur Font avec le cache navigateur désactivé. Consignez fichiers, tailles transférées et feuilles de style à l'origine des requêtes.
2. Inspectez les styles calculés et Coverage sur les types de pages et interactions pour identifier familles, graisses, styles et icônes utilisés.
3. Recherchez les fichiers enregistrés, imports CSS et modèles du thème actif. Les thèmes basés sur Classic utilisent normalement templates/_partials/head.tpl ; les thèmes personnalisés peuvent différer.
4. Supprimez les ressources inutiles dans les sources maintenues du thème ou un thème enfant. Vérifiez toutes les langues prises en charge, symboles monétaires et contenus dynamiques.

Classic et Hummingbird incluent des déclarations de police Material Icons. Inspectez le CSS livré avant de supposer que l'un des thèmes a éliminé les polices d'icônes. Inspectez la version exacte et les bibliothèques ajoutées par les modules. Un sous-ensemble ou des icônes SVG sélectionnées peuvent réduire les ressources inutilisées, mais conservez les symboles nécessaires et les libellés accessibles.

Demandez uniquement les graisses et caractères utilisés. WOFF2 et des sous-ensembles soigneusement choisis peuvent réduire les transferts ; le gain dépend de la police et des langues. Une pile de polices système évite des téléchargements de polices Web supplémentaires. Par exemple :

font-family: system-ui, -apple-system, "Segoe UI", sans-serif;

Pour les polices conservées, choisissez une politique font-display appropriée. swap affiche le texte de secours pendant le chargement, mais les métriques peuvent changer et provoquer des déplacements. Rapprochez les métriques de la police de secours si possible et testez la mise en page. Pour Google Fonts, demandez explicitement display=swap si souhaité et inspectez le CSS reçu ; ce n'est pas universel sur toutes les URL de l'API. Consultez les consignes de l'API Fonts.

Héberger soi-même des polices sous licence évite la requête vers ce fournisseur distant et peut réutiliser la connexion à votre origine. Le chargement distant nécessite toujours une évaluation appropriée de la confidentialité. L'affaire Google Fonts de Munich de janvier 2022 a accordé 100 EUR de dommages-intérêts civils, et non une amende administrative, comme l'explique l'autorité de Basse-Saxe.

Pour comparer des thèmes, utilisez les mêmes données et paramètres de préproduction, un thème par défaut compatible et des états de cache consignés. Changer de thème modifie aussi les fonctions et la présentation des modules : la différence est une expérience, pas une comptabilité exacte de tout le coût du thème. Désactivez séparément effets, polices ou composants pour affiner. Conservez les modifications maintenues dans un thème enfant si approprié.

Dans une trace Performance, inspectez les tâches JavaScript longues et leurs piles d'appels. Utilisez les événements Layout/Recalculate Style et les diagnostics de recalcul forcé pour repérer les recalculs de mise en page répétés. Les marques rouges seules ne les démontrent pas. Consultez la référence de performances DevTools pour interpréter la trace.

Auditer ce que les modules exécutent et chargent réellement

Établissez par page un inventaire du CSS/JS des modules, tailles transférées et décodées, requêtes, appels SQL, exécution serveur et widgets nécessitant ces ressources. L'enregistrement des hooks ou le nombre de modules ne suffit pas à connaître le coût.

En contexte monoboutique, Apparence → Positions affiche les enregistrements de hooks. Activez Afficher les hooks invisibles pour inclure les hooks d'action tels que actionFrontControllerSetMedia à côté des hooks d'affichage comme displayHeader. Le cœur permet des exceptions de contrôleur pour les enregistrements de hooks et un module peut enregistrer ses fichiers conditionnellement. Un hook sans HTML visible peut tout de même effectuer une initialisation nécessaire.

Filtrer Réseau sur /modules/ est un bon début. Ce filtre ne repère pas les fichiers regroupés par CCC ou le thème, les ressources distantes et les fichiers générés dynamiquement. Retracez les initiateurs et le contenu des paquets ; désactivez temporairement CCC en préproduction pour un diagnostic si nécessaire.

1. Trouvez les ressources coûteuses et appels serveur sur la page lente.
2. Vérifiez où leurs fonctions apparaissent. Avis et boutons de liste d'envies peuvent légitimement nécessiter des fichiers dans les listes de catégorie.
3. Bloquez une URL de ressource précisément ciblée pour une expérience navigateur, puis inspectez les dysfonctionnements. Bloquer le domaine partagé de la boutique n'isole pas un module.
4. Désactivez un module suspect en préproduction et répétez les mêmes tests. Le blocage navigateur ne supprime pas le travail des hooks serveur ; désactiver un module modifie aussi le comportement de la page.
5. Préférez corriger l'enregistrement conditionnel dans le module. Utilisez les exceptions de hooks ou une logique de désenregistrement et réenregistrement après vérification des dépendances et de l'initialisation seulement.
6. Revérifiez les interactions produit, catégorie, compte, panier, commande, consentement et mobile.

Préservez les fonctions utiles en réduisant leur travail inutile. Il n'existe ni budget universel de dix millisecondes par module ni pourcentage d'économie garanti par un audit.

Choisir la couche de cache et tester admissibilité et invalidation

Ajoutez du cache là où les mesures montrent un travail répété qui peut être réutilisé sans risque. Un nouveau cache modifie la charge ; il ne dispense pas de mesurer ni de garder un parcours sans cache en bonne santé.

Intégration Redis

Installez un véritable service Redis, la prise en charge PHP requise et l'adaptateur reliant le chemin de cache visé. Le paramètre ps_caching doit désigner un adaptateur de cache applicatif installé ; il ne configure pas le stockage des sessions. Un adaptateur personnalisé utilisé avec Performance Revolution se nomme MPRCacheRedis ; suivez la procédure d'installation prise en charge par son implémentation.

Configurez séparément le stockage des sessions PHP ou Symfony, avec ses politiques de verrouillage et d'échec. Cookies client et sessions PHP sont des mécanismes différents, et passer à Redis ne supprime pas intrinsèquement le verrouillage.

Les API d’écriture en base du cœur peuvent appeler l’invalidation de l’adaptateur lorsque le cache est activé. Le SQL direct, les imports externes et les caches propres aux modules peuvent suivre d’autres chemins. Testez les mises à jour de prix, de stock, de produits, de catégories et de configuration par chaque voie d’écriture que vous utilisez. Redis lui-même ne sait pas quelles pages ou quels résultats de requêtes PrestaShop sont devenus périmés. Testez aussi l’expiration, les requêtes simultanées et le comportement en cas de panne du service Redis.

La page d’aide de Redis Cache Manager & Monitor couvre les vérifications de connexion, la gestion des clés et les interrupteurs distincts pour les données stockées, les sessions et les pages des visiteurs non connectés. Un service Redis fonctionnel est nécessaire ; testez en préproduction chaque intégration activée, l’invalidation et le comportement en cas de panne.

Cache de page entière

Un nouveau visiteur avec un cache navigateur froid peut recevoir une réponse d'un cache de pages partagé chaud. Les réponses admissibles en cache peuvent éviter du travail coûteux en base et réduire le TTFB, même si le chemin de requête sous-jacent est lent. Les accès sans résultat en cache et les requêtes exclues ou privées nécessitent toujours une application saine.

Un module applicatif exécute toujours PHP sur son chemin de cache. Un proxy inverse externe ou cache FastCGI correctement configuré peut contourner PHP pour les réponses en cache. Considérez leurs temps comme des mesures différentes. Définissez explicitement l'admissibilité selon méthode de requête, contrôleur résolu, paramètres de requête, hôte/boutique, langue, devise et tout facteur influant sur le résultat public.

Excluez panier, commande, compte, connexion, back-office, API, AJAX et réponses personnalisées, sauf mécanisme d'isolation conçu spécifiquement. Respectez les réponses private/no-store et le comportement de création de cookies. Une liste noire de fragments d'URL anglais manque les chemins traduits et les contrôleurs en paramètres de requête.

Testez avec deux navigateurs et différents états client. Vérifiez les clés de cache, variations de consentement et l'absence de partage de contenu privé entre visiteurs. Testez l'invalidation pour modifications de produits, prix, stock, catégories, début et fin de promotion et imports externes. Un TTL est une tolérance délibérée aux données périmées, pas une invalidation complète.

La purge par tags et les fragments dynamiques peuvent aider lorsqu’ils sont implémentés. ESI, l’hydratation côté navigateur et le remplacement de marqueurs en PHP sont des techniques différentes. Pour le cache applicatif pris en charge, les marqueurs côté serveur, les cibles de CSS critique et la couverture du profilage, consultez la page d’aide de Performance Revolution. Le module mesure aussi la vitesse réelle des pages chez les clients et peut servir les pages publiques admissibles via Cloudflare en option, avec des copies publiques variant selon la langue, la devise, le pays et l’appareil, et un renouvellement des pages concernées lorsque les prix ou le stock changent ; le panier, la commande, les comptes et les visites connectées utilisent la boutique en direct. Vérifiez en préproduction son adéquation avec votre cache, votre thème et vos intégrations sur mesure existants.

Checklist de recette du cache

• Préchauffez une page produit publique admissible, puis modifiez son prix et son stock par les voies de mise à jour habituelles de la boutique, y compris les imports ERP ou en masse le cas échéant. Vérifiez à quel moment la copie publique est mise à jour.
• Changez la langue, la devise et le pays de destination. Testez les prix par groupe de clients et les affichages de prix personnalisés ; excluez toute page ou tout contexte dont les variantes ne peuvent pas être démontrées sans risque.
• Ajoutez au panier, connectez-vous et ouvrez les pages de compte et de commande. Vérifiez que le contenu personnel est correct pour chaque visiteur et que les réponses privées ne sont pas réutilisées.
• Répétez en préproduction l’expiration, les absences simultanées dans le cache et la panne du service de cache. Vérifiez que la solution de repli reste correcte et que le rétablissement ne submerge pas le serveur d’origine.
• Consignez la couche responsable de chaque réponse en cache et la façon de l’invalider. Confirmez qu’un autre proxy ou CDN ne peut pas conserver de copie après l’actualisation du cache applicatif.

Cache statique et préchauffage

Des entrées fraîches du cache navigateur peuvent éviter un aller-retour réseau. La validation ETag effectue normalement une requête conditionnelle. Utilisez une longue fraîcheur uniquement avec une stratégie appropriée de déploiement de fichiers versionnés ; un vidage serveur ne peut pas effacer le cache navigateur de chaque visiteur. Un CDN peut servir les fichiers publics près des visiteurs, mais vérifiez TLS, CORS pour les polices, en-têtes de cache et invalidation.

Videz uniquement les couches concernées avec les outils pris en charge. Préchauffez les pages admissibles importantes après un déploiement avec une concurrence et une charge limitées. Ne supposez pas qu'activer le cache de modèles rendus déplace les fichiers PHP des modèles compilés dans Redis. Préchauffer l'origine et les points de présence CDN sont des opérations distinctes, et le préchauffage peut ajouter de la charge. Comparez des exécutions volontairement froides et chaudes plutôt que de masquer leur différence.

Le guide du cache de page entière, de Redis et du CDN approfondit ces couches.

Gérer les déclinaisons et la lenteur du back-office

La capacité du catalogue dépend des déclinaisons, associations, images, caractéristiques, filtres, prix et imports autant que du nombre de produits. Il n'existe pas de plafond pratique unique de produits pour toutes les boutiques. Testez la charge d'une copie de préproduction avec données et trafic réalistes.

Six tailles, huit couleurs et cinq finitions produisent 240 déclinaisons si toutes les combinaisons sont générées. Inspectez les plus grands ensembles avec ces requêtes en lecture seule, en remplaçant le préfixe par défaut si nécessaire :

SELECT id_product, COUNT(*) AS combinations
FROM ps_product_attribute
GROUP BY id_product
ORDER BY combinations DESC
LIMIT 20;

SELECT id_product, COUNT(*) AS stock_rows
FROM ps_stock_available
WHERE id_product_attribute <> 0
GROUP BY id_product
ORDER BY stock_rows DESC
LIMIT 20;

La requête de lignes de stock compte les lignes stockées dans leurs différents périmètres ; ce n'est pas un total de stock isolé par boutique. Examinez l'appartenance aux boutiques et groupes pour l'interpréter.

Supprimez les variantes impossibles, réduisez les dimensions inutiles ou divisez un très gros produit si cela convient aux habitudes d'achat. Des options sans stock ou prix indépendant peuvent plutôt relever de la personnalisation ou d'un configurateur. Revérifiez les conséquences sur URL, images, prix et stock avant de modifier le modèle.

Les gros formulaires et imports peuvent atteindre max_input_vars, post_max_size, la mémoire ou les délais de requête. Traitez les synchronisations de stock et imports par lots et reconstruisez les index de recherche ou de facettes concernés via les outils pris en charge après des modifications importantes.

Profilez les écrans d'administration séparément. Si seul le tableau de bord est lent, testez statistiques, flux et widgets facultatifs. Si le gestionnaire de modules est lent, inspectez les métadonnées et requêtes aux services distants. Les intégrations Marketplace dépendent de la version et de l'installation ; Marketplace n'est plus inclus dans le projet open source depuis la version 8.

Si boutique et back-office sont tous deux lents, inspectez les ressources partagées de PHP, de la base et de l'hébergement. Ce symptôme ne prouve pas une base encombrée. Vérifiez les répertoires de cache accessibles en écriture, reconstructions répétées, OPcache, files des processus, latence de la base et hooks pertinents avant de supprimer des données.

Adapter les opérations à la charge mesurée

Suivez séparément infrastructure, exactitude du stock et charge du personnel. Le nombre mensuel de commandes ne définit pas un niveau d'hébergement et ne rend pas obligatoire le cache de page entière. Les ratios trafic/commandes et les pics de concurrence varient.

Chronométrez les tâches récurrentes : gestion des états, préparation, expédition, messages clients, retours et exports comptables. À titre de planification, 100 commandes mensuelles prenant six minutes chacune représentent dix heures de personnel par mois. Utilisez vos propres temps mesurés et incluez les exceptions avant de décider quoi automatiser.

Distinguez le statut de commande natif, les notifications aux clients et le statut de processus interne propre à un module. Advanced Order Fulfilment peut relier des événements à ses propres étapes de processus, équipes et rappels ; vérifiez séparément les transitions de statut natives et les emails d’expédition aux clients.

Utilisez le processus natif du SAV pour les messages qu’il reçoit réellement. Un module de formulaire distinct peut stocker ses propres envois et notifications : vérifiez donc toute intégration avec un outil de helpdesk. Pour le routage propre aux formulaires, consultez la page d’aide de Better Contact Form.

Rapprochez le stock des commandes, retours et autres canaux de vente. Examinez les actions groupées sur les commandes et exports filtrés, y compris autorisations et effet sur les notifications. Attribuez aux préparateurs, agents de support et administrateurs des comptes individuels avec des accès adaptés à leurs rôles.

Séparez les serveurs Web et de base uniquement si les mesures justifient des ressources indépendantes. Tenez compte de la latence réseau, des connexions sécurisées, sauvegardes et restaurations, paramètres de connexion et tests de déploiement. Un changement de configuration seul n'est pas un plan de migration complet. Incluez personnel, logiciels, infrastructure, frais et retours pour évaluer la marge des commandes supplémentaires.

Maintenir une routine de surveillance et de déploiement

• Consignez des tests de laboratoire reproductibles et des mesures réelles pour les types de pages représentatifs, avec le comportement des accès avec et sans résultat en cache.
• Surveillez disponibilité, erreurs, files des processus PHP, CPU, mémoire, E/S, latence des requêtes, connexions et capacité des caches. Définissez les alertes selon votre référence.
• Examinez les résumés de requêtes lentes, croissance des tables et conservation. Utilisez PMM ou un tableau de bord de base si cela convient à vos besoins opérationnels ; les suggestions automatiques nécessitent toujours des tests de charge.
• Après une modification de module, de thème ou de catalogue, un gros import ou une évolution du trafic, comparez ressources, appels, charge de requêtes et interactions à la référence. Conservez les rapports complets et un court journal des modifications.
• Au déploiement, videz les couches PrestaShop concernées, appliquez la politique OPcache Web documentée, invalidez les fichiers modifiés et préchauffez dans des limites contrôlées.
• Vérifiez de bout en bout les erreurs du navigateur, l’affichage des images, la navigation, les filtres, le panier, le paiement et la confirmation, et vérifiez que les prix, le stock et les intégrations se comportent toujours comme avant.
• Examinez les tendances terrain après accumulation de données suffisantes. Ne jugez pas un rapport terrain glissant sur un seul test de laboratoire ou quelques jours.

Choisissez la prochaine modification selon le coût mesuré, le risque et l'effet sur les clients. Testez à nouveau après celle-ci et prévoyez un retour arrière. Un test plus rapide n'est utile que si catalogue, prix, choix de confidentialité et parcours de commande fonctionnent toujours correctement.

Questions des marchands avant de payer des travaux de vitesse

Faut-il d’abord acheter plus de mémoire ou une offre plus grande ? Demandez quelle attente mesurée cela supprimerait et de quoi les autres services du serveur ont besoin. Plus de mémoire ne corrige ni une requête lente, ni un appel externe, ni le travail du navigateur.

Une grande table a-t-elle besoin d’un index supplémentaire ? Seulement si un schéma d’accès réel en tire un bénéfice suffisant pour justifier le coût en stockage et en écriture. Testez l’index candidat face à la charge en préproduction.

Faut-il d’abord nettoyer la base de données ? Seulement là où un coût mesuré l’indique, par exemple une table en croissance au sein d’une requête lente ou une fenêtre de sauvegarde, et uniquement selon une politique de conservation convenue.

Peut-on commencer par le cache ? Évaluez-le lorsque les traitements publics répétés représentent l’occasion d’amélioration mesurée. Préservez les parcours privés, testez l’invalidation et conservez un parcours sans cache acceptable ; l’ordre des modifications dépend des éléments recueillis.

Quand faut-il refaire l’analyse ? Après des modifications pertinentes de modules ou du catalogue, des imports, des évolutions du trafic ou une régression sur les parcours consignés. Gardez une surveillance suffisante pour repérer ce changement.