Optimisation des performances PrestaShop : Accélérer votre boutique

Pourquoi la vitesse de votre boutique n’est pas optionnelle

Chaque tranche de 100 millisecondes de temps de chargement supplémentaire vous coûte des conversions. Amazon a constaté qu’un délai de 100 ms réduisait le chiffre d’affaires de 1 %. Google a confirmé que les pages se chargeant en plus de 3 secondes perdent 53 % des visiteurs mobiles avant même qu’ils voient vos produits.

Pour une boutique PrestaShop, la vitesse affecte directement trois éléments :

• Taux de conversion : Une boutique qui se charge en 2 secondes convertit environ deux fois plus qu’une boutique qui se charge en 5 secondes. Vos clients n’attendront pas — ils achèteront chez quelqu’un de plus rapide.
• Référencement SEO : Google utilise la vitesse de page comme facteur de classement. Depuis 2021, les Core Web Vitals font partie de l’algorithme. Une boutique lente se classe moins bien, reçoit moins de trafic organique et paie davantage pour sa visibilité.
• Expérience mobile : Plus de 70 % du trafic e-commerce provient du mobile. Processeurs plus lents, moins de mémoire, connexions moins fiables. Si votre boutique est lente sur ordinateur, elle est pénible sur mobile.

L’optimisation de la vitesse n’est pas une tâche ponctuelle — c’est une discipline continue. Chaque module que vous installez, chaque modification du thème, chaque image de produit affecte les performances. Considérez la vitesse comme une fonctionnalité que vous entretenez, pas comme un projet que vous terminez.

Mesurez avant d’optimiser

La pire chose que vous puissiez faire est de commencer à « optimiser » sans savoir où se trouvent vos véritables problèmes. Mesurez toujours en premier.

Les bons outils

• Google PageSpeed Insights : Gratuit, utilise les données réelles des utilisateurs Chrome (CrUX). Testez votre page d’accueil, une page de catégorie et une page produit — ce sont vos points d’entrée les plus courants.
• GTmetrix : Fournit un diagramme en cascade montrant exactement ce qui se charge, dans quel ordre, et combien de temps prend chaque requête. Indispensable pour identifier les goulots d’étranglement.
• WebPageTest : L’outil le plus détaillé disponible. Testez depuis différentes localisations et vitesses de connexion avec des vues filmstrip.

Les Core Web Vitals expliqués

Voici les trois métriques que Google utilise pour évaluer l’expérience utilisateur :

• LCP (Largest Contentful Paint) : Temps nécessaire au chargement complet du plus grand élément visible. Objectif : moins de 2,5 secondes. La plupart des boutiques PrestaShop échouent ici — les images non optimisées et les scripts bloquant le rendu en sont les responsables.
• INP (Interaction to Next Paint) : Temps de réponse de la page aux clics et aux appuis. A remplacé le FID en mars 2024. Objectif : moins de 200 ms. Le JavaScript lourd et les scripts de modules mal écrits provoquent un INP élevé.
• CLS (Cumulative Layout Shift) : Amplitude des décalages de mise en page pendant le chargement. Objectif : moins de 0,1. Les images sans dimensions, les bannières à chargement tardif et les changements de police provoquent le CLS.

Objectifs réalistes

Une boutique PrestaShop riche en fonctionnalités n’obtiendra jamais un score de 100 sur PageSpeed. Visez : mobile 50-70, desktop 80-95, LCP sous les 3s en mobile / 2s en desktop, poids total de la page sous 2 Mo, moins de 80 requêtes HTTP.

Ne cherchez pas le score PageSpeed parfait. Un score de 65 avec un taux de conversion de 3 % vaut mieux qu’un score de 98 sur une page dépouillée où personne n’achète. Optimisez pour l’expérience utilisateur réelle, pas pour un chiffre.

Optimisation du serveur

Aucune astuce frontend ne peut compenser un serveur lent. Si votre serveur met 2 secondes à générer le HTML avant même que le navigateur ne commence à charger les ressources, vous avez déjà perdu.

Configuration de PHP OPcache

OPcache stocke le bytecode PHP précompilé en mémoire afin que PHP ne réanalyse pas les fichiers à chaque requête. Pour PrestaShop (des centaines de fichiers PHP par page), c’est indispensable.

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60
opcache.save_comments=1

Les valeurs par défaut sont trop basses pour PrestaShop. max_accelerated_files doit être d’au moins 20000 (la valeur par défaut est 4000, mais une installation PS typique compte 10 000 à 15 000 fichiers PHP). Réglez memory_consumption sur 128-256 Mo — si la mémoire OPcache se remplit, les entrées sont évincées et vous perdez le bénéfice.

Sur les hébergements cPanel avec validate_timestamps=0, OPcache ne relira JAMAIS les fichiers depuis le disque. Vous devez le réinitialiser via une requête web après chaque déploiement — les réinitialisations en CLI ne vident que le cache CLI, pas le cache web.

Tuning MySQL / MariaDB

Une page produit PrestaShop typique exécute 50 à 200 requêtes SQL. Le paramètre de base de données le plus important est :

[mysqld]
# Set to 50-70% of available RAM on dedicated DB server
innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2

# MySQL 5.7 / MariaDB only (removed in MySQL 8.0)
query_cache_type = 1
query_cache_size = 64M

# Find problem queries
slow_query_log = 1
long_query_time = 1

# Connection settings
max_connections = 150
tmp_table_size = 64M
max_heap_table_size = 64M

Le paramètre innodb_buffer_pool_size détermine la quantité de données conservées en RAM. Si votre base de données fait 500 Mo et que le buffer pool est de 1 Go, la plupart des requêtes sont servies depuis la mémoire. Activez le slow query log et examinez-le chaque semaine — les requêtes dépassant 1 seconde sont des problèmes en attente lors des pics de trafic.

Hébergement : mutualisé vs VPS vs dédié

• Hébergement mutualisé (5-15 $/mois) : Vous partagez le CPU et la RAM avec des centaines de sites. Acceptable uniquement pour de très petites boutiques de moins de 500 produits.
• VPS (20-60 $/mois) : Ressources dédiées. Le meilleur compromis pour la plupart des boutiques. Prenez au minimum 4 Go de RAM, 2 cœurs CPU, stockage SSD.
• Dédié (80-300 $/mois) : Pour les boutiques à fort trafic (plus de 1000 commandes par jour) ou les catalogues de plus de 100 000 produits.

Si vous êtes sur un hébergement mutualisé et que votre boutique est lente, passer à un VPS vous apportera un gain de vitesse supérieur à toutes les autres optimisations réunies.

PHP-FPM et Redis

Utilisez PHP-FPM au lieu de mod_php — il exécute PHP comme un service séparé, réduisant l’utilisation de la mémoire et améliorant la gestion des processus. Utilisez Redis pour le stockage des sessions et du cache au lieu du système de fichiers. Configuration dans app/config/parameters.php :

'ps_cache_enable' => true,
'ps_caching' => 'CacheRedis',

Optimisations intégrées de PrestaShop

CCC (Combine, Compress, Cache)

Accessible dans Paramètres avancés → Performances, CCC combine les fichiers CSS/JS en fichiers uniques et les minifie. Activez-le toujours en production. Attention aux pièges :

• Les fichiers avec les attributs defer ou async restent séparés (c’est voulu)
• Les fichiers externes (Google Fonts, Stripe.js) ne sont jamais combinés
• Des modules mal codés peuvent casser lorsque CCC réordonne les ressources — si l’activation de CCC casse votre processus de commande, désactivez-le et identifiez le module problématique
• Videz toujours le cache et testez minutieusement après l’activation

Paramètres des templates Smarty

Réglez la compilation des templates sur « Recompiler les templates si les fichiers ont été mis à jour » en production. N’utilisez jamais « Forcer la compilation » — cela recompile chaque template à chaque chargement de page.

Mode Debug — Vérifiez ceci en premier

Le mode debug désactive toute mise en cache, force la recompilation des templates et enregistre tout. Vérifiez qu’il est désactivé :

// In app/config/defines.inc.php — MUST be false on production
define('_PS_MODE_DEV_', false);

Nous avons vu des boutiques fonctionner en mode debug pendant des mois. Leur problème de « boutique lente » a disparu lorsque ce seul paramètre a été corrigé.

Désactivez les modules inutiles

Chaque module activé se connecte au système d’événements de PrestaShop. Une installation fraîche est livrée avec plus de 80 modules. Chacun charge des classes PHP, peut enregistrer du CSS/JS sur chaque page, exécute des callbacks de hooks et peut lancer des requêtes en base de données — même lorsqu’il ne renvoie aucun contenu.

Parcourez Modules → Gestionnaire de modules et désinstallez tout ce que vous n’utilisez pas activement. Si vous avez trois modules d’analytics faisant la même chose, n’en gardez qu’un.

Optimisation des images

Les images représentent généralement 60 à 80 % du poids total d’une page. C’est là que la plupart des boutiques ont la plus grande marge d’amélioration.

WebP et dimensions adaptées

Les images WebP sont 25 à 35 % plus légères que le JPEG sans perte de qualité visible. PrestaShop 8.x prend en charge WebP nativement. Pour les versions antérieures, utilisez une conversion côté serveur ou un module.

Le gaspillage le plus courant : servir des images de 2000x2000 px dans des miniatures de 300 px. Configurez les types d’images dans Apparence → Paramètres des images pour correspondre aux tailles d’affichage réelles de votre thème. Ne téléversez pas des images sources de 4000 px « au cas où » — 1200 px suffisent pour le zoom produit sur les écrans Retina.

Chargement différé (Lazy Loading)

Différez le chargement des images situées sous la ligne de flottaison jusqu’à ce que l’utilisateur y fasse défiler la page :

<img src="product.jpg" loading="lazy" width="300" height="300" alt="Product Name">

Ne chargez PAS en différé les images au-dessus de la ligne de flottaison (logo, bannière principale, première rangée de produits) — elles affectent le LCP et doivent se charger immédiatement.

Régénération des images

Après avoir modifié les dimensions des images, régénérez les images existantes via Apparence → Paramètres des images ou en ligne de commande :

php bin/console prestashop:image:regenerate --type=products

Optimisation frontend

Minimisez les requêtes HTTP

Vérifiez votre diagramme en cascade dans GTmetrix. Plus de 100 requêtes signifie un problème. Causes courantes : modules chargeant leurs propres fichiers CSS/JS, Google Fonts avec de multiples graisses, widgets de réseaux sociaux et outils d’analytics multiples.

CSS critique

Les navigateurs bloquent le rendu tant que tout le CSS du <head> n’est pas téléchargé. Le CSS critique extrait uniquement les styles nécessaires au viewport initial et les intègre en ligne. La feuille de styles complète se charge de manière asynchrone. Cela peut réduire le temps de chargement perçu de 1 à 3 secondes sur mobile, mais nécessite une régénération à chaque modification du CSS du thème.

JavaScript : Defer et Async

Utilisez defer pour la plupart des scripts de modules (téléchargement en parallèle, exécution après l’analyse du HTML). Utilisez async uniquement pour les scripts indépendants comme les outils d’analytics. Dans PrestaShop 1.7+ :

$this->context->controller->registerJavascript(
    'module-my-script',
    'modules/mymodule/views/js/front.js',
    ['position' => 'bottom', 'priority' => 200, 'attribute' => 'defer']
);

Optimisation des polices

Les polices personnalisées ajoutent silencieusement 200 à 400 Ko de téléchargements. Bonnes pratiques :

• Hébergez les polices vous-même au lieu d’utiliser Google Fonts (élimine une recherche DNS supplémentaire)
• Sous-ensembles : ne conservez que les caractères dont vous avez besoin (les sous-ensembles Latin uniquement sont 60 à 80 % plus légers)
• Utilisez font-display: swap pour que le texte soit visible immédiatement dans une police de substitution
• Limitez-vous à 2 graisses — regular (400) et bold (700) couvrent la plupart des besoins
• Utilisez le format WOFF2 — meilleure compression, support universel par les navigateurs

@font-face {
    font-family: 'YourFont';
    src: url('/themes/your-theme/assets/fonts/yourfont.woff2') format('woff2');
    font-weight: 400;
    font-style: normal;
    font-display: swap;
}

Bases du CDN

Un CDN sert les fichiers statiques depuis des serveurs proches de vos visiteurs. Cloudflare est l’option gratuite la plus populaire. Configurez un domaine CDN dans Paramètres avancés → Performances → Serveurs médias pour les images, le CSS et le JS.

Optimisation de la base de données

Les bases de données PrestaShop grossissent silencieusement. Des tables qui fonctionnaient bien au lancement deviennent problématiques après deux ans de données accumulées.

Nettoyez les anciens paniers

ps_cart et ps_cart_product grossissent avec chaque visiteur — y compris les bots et les sessions abandonnées. Après un an, ces tables peuvent contenir des millions de lignes.

-- Delete cart products for old abandoned carts (not linked to orders)
DELETE cp FROM ps_cart_product cp
INNER JOIN ps_cart c ON cp.id_cart = c.id_cart
LEFT JOIN ps_orders o ON c.id_cart = o.id_cart
WHERE o.id_order IS NULL
AND c.date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

-- Delete the empty carts
DELETE c FROM ps_cart c
LEFT JOIN ps_orders o ON c.id_cart = o.id_cart
LEFT JOIN ps_cart_product cp ON c.id_cart = cp.id_cart
WHERE o.id_order IS NULL AND cp.id_cart IS NULL
AND c.date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

Sauvegardez toujours votre base de données avant d’exécuter des requêtes DELETE. Testez toujours sur un environnement de préproduction d’abord. Le pattern LEFT JOIN + IS NULL garantit que les paniers liés à des commandes ne sont jamais supprimés.

Nettoyez les logs et les connexions

-- Application logs
DELETE FROM ps_log WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

-- Visitor tracking
DELETE FROM ps_connections_page WHERE id_connections IN (
    SELECT id_connections FROM ps_connections
    WHERE date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH)
);
DELETE FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

-- Orphaned guest records
DELETE g FROM ps_guest g
LEFT JOIN ps_connections c ON g.id_guest = c.id_guest
WHERE c.id_guest IS NULL;

-- Search stats, 404 logs, email logs
DELETE FROM ps_statssearch WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH);
DELETE FROM ps_pagenotfound WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);
DELETE FROM ps_mail WHERE date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

Nettoyez l’index de recherche

Si vous utilisez une solution de recherche externe (Elasticsearch, Algolia), ces tables sont du poids mort :

TRUNCATE TABLE ps_search_index;
TRUNCATE TABLE ps_search_word;

Optimisez les tables et les index

Après de grosses suppressions, récupérez l’espace disque :

OPTIMIZE TABLE ps_cart, ps_cart_product, ps_connections,
    ps_connections_page, ps_guest, ps_log;

Ajoutez les index manquants pour les requêtes courantes :

-- Check existing indexes first: SHOW INDEX FROM ps_cart;
ALTER TABLE ps_cart ADD INDEX idx_cart_date (date_add);
ALTER TABLE ps_connections ADD INDEX idx_conn_date (date_add);
ALTER TABLE ps_orders ADD INDEX idx_orders_ref (référence);
ALTER TABLE ps_product ADD INDEX idx_product_ref (référence);

Utilisez EXPLAIN sur les requêtes lentes pour vérifier que les index sont utilisés — si la colonne « type » affiche « ALL », cela signifie un parcours complet de la table.

Stratégies de mise en cache

Cache de page complète

L’amélioration la plus spectaculaire disponible. Sans cache, chaque requête exécute des centaines de fichiers PHP et plus de 100 requêtes SQL (200-500 ms). Avec le cache de page complète, la même page est servie en 5-20 ms.

Varnish est le standard de l’industrie. nginx FastCGI cache est plus simple si vous utilisez déjà nginx :

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=PS:100m inactive=60m;

set $skip_cache 0;
if ($http_cookie ~* "PrestaShop-") { set $skip_cache 1; }
if ($request_uri ~* "/cart|/order|/my-account|/admin") { set $skip_cache 1; }

location ~ \.php$ {
    fastcgi_cache PS;
    fastcgi_cache_valid 200 10m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
}

Le défi réside dans l’invalidation du cache — vider les pages mises en cache lorsque les produits, les prix ou les stocks changent. Cette complexité explique pourquoi de nombreuses boutiques renoncent au cache de page complète.

Cache d’objets et cache navigateur

Le cache d’objets (via Redis) stocke les résultats de requêtes coûteuses en mémoire. Moins spectaculaire que le cache de page complète (réduction de 30 à 50 % du temps de requête), mais bien plus simple — PrestaShop gère l’invalidation automatiquement.

Les en-têtes de cache navigateur indiquent aux navigateurs de vos visiteurs de stocker les fichiers statiques localement :

# Apache (.htaccess)
<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType font/woff2 "access plus 1 year"
</IfModule>

Erreurs de performance courantes

• Trop de modules (50+) : Chacun ajoute une surcharge d’autoloader, des callbacks de hooks, du CSS/JS et des requêtes. Une boutique avec 30 modules sera toujours plus performante qu’une avec 80. Il n’existe pas de module à coût zéro.
• Modules chargeant des ressources partout : Un module de popup qui ne se déclenche que sur la page d’accueil mais charge 150 Ko de JavaScript sur chaque page est du pur gaspillage. Vérifiez votre diagramme en cascade pour repérer les ressources de modules non pertinentes.
• Sliders lourds en page d’accueil : 3 à 5 images haute résolution plus une bibliothèque JS = 1 à 5 Mo pour un composant avec lequel moins de 1 % des utilisateurs interagissent au-delà de la première diapositive. Utilisez plutôt une seule image statique en bannière.
• Thèmes personnalisés non optimisés : Bootstrap complet chargé pour 3 composants, CSS/JS non minifiés, pas de dimensions d’images, scripts synchrones. Exigez des audits de performance de la part des développeurs de thèmes.
• Index de base de données manquants : Une requête avec un index adapté prend 10 ms. Sans index, elle prend 5 secondes — et vous ne le remarquerez pas avant les pics de trafic.

Checklist de suivi des performances

Vérifications rapides (5 minutes)

• Lancez PageSpeed Insights sur la page d’accueil, une page de catégorie, une page produit
• Vérifiez que _PS_MODE_DEV_ est à false
• Confirmez que Smarty n’est PAS réglé sur « Forcer la compilation »
• Vérifiez que CCC est activé
• Vérifiez qu’OPcache est actif via phpinfo()

Maintenance mensuelle (30 minutes)

• Nettoyez les paniers abandonnés dans ps_cart / ps_cart_product (plus anciens que 3 mois)
• Nettoyez ps_log, ps_connections, ps_connections_page, ps_guest
• Lancez OPTIMIZE TABLE sur les tables nettoyées
• Examinez le slow query log
• Désinstallez les modules inutilisés

Revue trimestrielle (2 heures)

• Test GTmetrix complet depuis plusieurs localisations — comparez avec le trimestre précédent
• Examinez les Core Web Vitals dans Google Search Console
• Auditez les ressources des modules pour repérer le CSS/JS inutile
• Vérifiez les tailles d’images — assurez-vous qu’il n’y a pas de fichiers surdimensionnés
• Examinez l’utilisation des ressources serveur (CPU, RAM, I/O disque)
• Testez sur un véritable appareil mobile, pas seulement en émulation
• Vérifiez les en-têtes de cache navigateur
• Consultez les logs d’erreurs PHP (les erreurs consomment des ressources)

Après chaque déploiement

• Videz le cache PrestaShop
• Réinitialisez OPcache si validate_timestamps=0
• Lancez un test PageSpeed rapide pour détecter les régressions
• Vérifiez la console du navigateur pour les erreurs JavaScript
• Testez le processus de commande de bout en bout

Par où commencer

L’optimisation des performances est un processus, pas une destination. Commencez par les quatre actions à plus fort impact : corrigez la configuration de votre serveur, optimisez vos images, désactivez les modules inutiles et nettoyez votre base de données. Ces actions à elles seules résolvent 80 % des problèmes de performance de la plupart des boutiques PrestaShop.

Mesurez avant et après chaque modification. Tenez un journal. La meilleure optimisation est celle que vos clients remarquent — un chargement d’images plus rapide et un processus de commande réactif se traduisent directement en confiance, satisfaction et conversions.