Contacter notre Agence
Confiez nous la réalisation de votre site web élégant et performant ou le pilotage de votre stratégie digitale

Choisissez votre sujet :


Les informations recueillies sur ce formulaire sont enregistrées dans un fichier informatisé nécessaire pour la gestion de nos clients et prospects. En soumettant ce formulaire, vous acceptez que les informations saisies soient exploitées dans le cadre de votre demande de contact et de la relation commerciale qui pourrait en découler. Pour connaitre et exercer vos droits, veuillez consulter notre politique de confidentialité. Conformément à la loi 09-08, vous disposez d'un droit d'accès, de rectification et d'opposition au traitement de vos données personnelles. Ce traitement a été notifié à la CNDP au titre du récépissé n°D-GC-1203/2024.

Nous proposons désormais des tarifications adaptées à tous les budgets. TPE, PME et grands comptes
Lundi-Dimanche : 09h00 - 21h00
(+212) 5 28 23 33 54 +33 (0)2 90 38 09 52
Lundi-Dimanche : 09h00 - 21h00
Appelez-nous : (+212) 5 28 23 33 54
4,8 115 avis
PrestaShop Logo

Guide complet d'optimisation PrestaShop 2026

11 leviers pour booster les performances : serveur, cache, base de données, modules et CDN. Explications techniques et accessibles.

Temps de lecture : 32 min PrestaShop 1.6 / 1.7 / 8 / 9
Nicolas Delmouly
Par — Fondateur · Consultant SEO/SEA
Publié le · Mis à jour le · 32 min de lecture

Sommaire

Partie 2 - Optimisation PageSpeed

Bonus

Pourquoi optimiser la vitesse de votre PrestaShop ?

Avant de plonger dans la technique, comprenons pourquoi la vitesse est cruciale pour votre boutique en ligne.

🎯 L'impact direct sur votre chiffre d'affaires

La vitesse de votre site n'est pas qu'une question technique — c'est un levier business majeur :

  • Taux de conversion : Amazon a démontré qu'une seconde de chargement en plus = -7% de conversions
  • Taux de rebond : 53% des visiteurs quittent un site mobile qui met plus de 3 secondes à charger (Google)
  • Panier moyen : Les sites rapides ont des paniers moyens plus élevés (moins de friction = plus d'achats impulsifs)
  • Fidélisation : Un site lent frustre vos clients et les pousse vers la concurrence
💡 En résumé : Chaque seconde gagnée peut représenter plusieurs milliers d'euros de CA supplémentaire par an, selon votre trafic.

📈 L'impact sur votre SEO

Google affirme utiliser la vitesse comme critère de classement depuis 2010 (desktop) et 2018 (mobile). Concrètement :

  • Les Core Web Vitals (LCP, INP, CLS) sont des signaux de ranking officiels
  • Un site lent est moins bien crawlé par Googlebot (moins de pages indexées)
  • Google favorise les sites offrant une bonne expérience utilisateur

🤔 Qu'est-ce qu'on optimise exactement ?

Il existe deux types de vitesse à ne pas confondre :

  1. La vitesse serveur (backend) — Le temps que met votre serveur à générer la page HTML. C'est ce qu'on optimise dans la partie 1 de cet article.
  2. La vitesse d'affichage (frontend) — Le temps que met le navigateur à afficher la page (images, CSS, JS). C'est la partie 2.

Pourquoi cet ordre ? Si votre serveur met 5 secondes à répondre, compresser vos images ne changera rien. On commence toujours par les fondations.

Glossaire : les termes à connaître

TTFB (Time To First Byte) Temps entre la demande du navigateur et la réception du premier octet de réponse. Mesure la réactivité du serveur.
Core Web Vitals 3 métriques Google : LCP (affichage du plus grand élément), INP (réactivité aux clics), CLS (stabilité visuelle).
OPcache Cache PHP qui garde le code compilé en mémoire. Évite de recompiler le PHP à chaque requête.
LSCache (LiteSpeed Cache) Cache serveur qui stocke les pages HTML générées. Sert la page en mémoire sans exécuter PHP.
Memcached Système de cache en RAM pour stocker les sessions et objets fréquemment utilisés.
Index MySQL Structure qui accélère les recherches dans une table, comme l'index d'un livre.
Lazy Loading Technique qui charge les images uniquement quand elles deviennent visibles à l'écran.
CDN (Content Delivery Network) Réseau de serveurs mondiaux qui rapproche vos fichiers (images, CSS, JS) de vos visiteurs.
WebP / AVIF Formats d'image modernes 25-50% plus légers que JPEG/PNG, avec qualité équivalente.
Brotli Algorithme de compression (successeur de Gzip) qui réduit la taille des fichiers texte transférés.

🔄 Comment une page PrestaShop est générée

👤 Visiteur
clique
→
🌐 CDN
Cloudflare
→
💾 LSCache
cache serveur
→
⚙️ PHP
OPcache
→
🗄️ MySQL
requêtes
→
📄 HTML
réponse

Si LSCache a la page en cache → réponse immédiate (~50ms)
Sinon → PHP + MySQL doivent générer la page (~200-500ms optimisé, 2-5s non optimisé)

Cet article est en 2 parties :

Partie 1 - Vitesse réelle (sections 1-11) : Le temps que met votre serveur à répondre (TTFB, PHP, MySQL, cache). C'est la fondation.

Partie 2 - Score PageSpeed (sections 12-14) : L'optimisation frontend (images WebP, lazy loading, Core Web Vitals). C'est la finition.

Commencez toujours par la partie 1. Optimiser les images ne sert à rien si votre serveur met 5 secondes à répondre !

Ce guide présente une méthodologie concrète d'optimisation, testée en conditions réelles. Elle s'applique à toutes les versions de PrestaShop (1.6, 1.7, 8 et 9). Plutôt que d'appliquer des optimisations génériques trouvées sur le web, nous allons identifier vos vrais problèmes grâce à un monitoring en temps réel, puis les corriger de manière ciblée.

💡 L'approche de cet article : En tant que développeur web, j'aborde l'optimisation PrestaShop non seulement du point de vue SEO/marketing, mais surtout côté performance backend, serveur, base de données, cache et expérience utilisateur réelle — ce qui n'est pas souvent couvert ailleurs.

📌 Cet article est écrit par un développeur.

Il traite uniquement de la performance réelle PrestaShop côté serveur
(TTFB, PHP, MySQL, cache, infrastructure).

Il ne traite pas :
— de scores PageSpeed ou Lighthouse
— d'optimisation "cosmétique" frontend
— de plugins miracles ou solutions marketing

Vitesse réelle vs Score PageSpeed : quelle différence ?

Bon PageSpeed Insight n'est pas égal à site rapide - Un score de 95 peut être lent, un score de 55 peut être rapide
Un bon score PageSpeed ne garantit pas un site rapide — et inversement.
Vitesse réelle (cet article) Score PageSpeed (partie 2)
Ce qu'on mesure Temps de réponse du serveur (TTFB), exécution PHP, requêtes SQL Rendu visuel, taille des ressources, expérience perçue
Où ça se passe Serveur (backend) Navigateur (frontend)
Optimisations Cache, OPcache, MySQL, index, Memcached, LiteSpeed Images WebP, lazy loading, CSS critique, Brotli
Impact UX / Conversion Indirect (temps d'attente perçu) Direct (fluidité visuelle, réactivité aux clics)
Priorité 🥇 À faire EN PREMIER 🥈 À faire ensuite
Ordre logique : Optimisez d'abord le serveur (cet article), puis le frontend (partie 2). Compresser des images ne sert à rien si votre serveur met 5 secondes à générer la page HTML !
  • Si votre serveur met +2s à générer une page, aucune optimisation frontend ne fera gagner +1s réelle.
  • La vitesse serveur est le socle. Le frontend n'est que la finition.

Objectifs de temps de réponse

TTFB vs Temps total :
• TTFB (Time To First Byte) = temps jusqu'au premier octet reçu par le navigateur
• Temps total HTML = fin de génération + transfert complet du document
Métrique ❌ Mauvais ⚠️ Moyen ✅ Bon 🚀 Excellent
TTFB (Time To First Byte) > 1s 500ms - 1s 200ms - 500ms < 200ms
Temps total (HTML généré) > 3s 1s - 3s 500ms - 1s < 500ms
Exemple concret : Le site soudure.pro, optimisé avec les techniques de cet article, affiche un TTFB de ~50ms grâce à LiteSpeed + LSCache. C'est 20 à 40× plus rapide qu'un PrestaShop non optimisé (qui tourne généralement entre 1000 et 3000ms).

curl -w "TTFB: %{time_starttransfer}s" https://www.soudure.pro/ → 0.051s (= 51ms)
💡 Rappel : curl affiche en secondes. Pour convertir : 0.051s × 1000 = 51ms

⏱️ Mesurer en 3 minutes (avant d'optimiser)

Avant toute optimisation, mesurez votre état actuel. Ce travail peut être réalisé gratuitement avec l'outil analyse-seo.net. Vous pouvez aussi ouvrir un terminal et lancer ces 3 commandes (remplacez l'URL par votre site) :

# 1. TTFB page d'accueil (cache chaud - après 2-3 requêtes)
curl -w "TTFB: %{time_starttransfer}s | Total: %{time_total}s\n" -o /dev/null -s https://votre-site.com/

# 2. TTFB page produit (cache contourné avec timestamp)
curl -w "TTFB: %{time_starttransfer}s | Total: %{time_total}s\n" -o /dev/null -s "https://votre-site.com/un-produit?nocache=$(date +%s)"

# 3. Vérifier si LSCache est actif
curl -sI https://votre-site.com/ | grep -i "x-litespeed-cache"
🖱️ Pas à l'aise avec le terminal ? Utilisez ces outils en ligne :
  • analyse-seo.net — Audit complet gratuit avec TTFB, headers, Core Web Vitals
  • GTmetrix — TTFB + cascade de chargement détaillée
  • WebPageTest — Tests avancés depuis plusieurs localisations
  • PageSpeed Insights — Métriques Google officielles (Core Web Vitals)
Commande Ce qu'elle mesure Valeur cible
#1 Cache chaud Performance maximale (page cachée) < 100ms avec LSCache, < 500ms sans
#2 Cache contourné Performance réelle PHP/MySQL < 500ms (bon), < 1s (acceptable)
#3 LSCache Le cache serveur est-il actif ? Doit afficher "hit" ou "miss"
💡 Conseil : Notez ces valeurs AVANT d'optimiser. Après chaque modification majeure, relancez ces commandes pour mesurer le gain réel.
🔍 Comment interpréter les résultats :
  • #2 (nocache) explose (> 1s) mais #1 (cache) est rapide → Problème PHP/MySQL/modules. Le cache masque le problème. Voir sections 2-3 et 9.
  • #1 (cache) lent aussi → Cache pas efficace (variations, cookies, exclusions). Voir section 8.
  • Les deux sont lents → Problème serveur global (OPcache absent, serveur surchargé). Voir sections 1 et 6.

🧠 Schéma canonique — Pipeline réel d'une requête PrestaShop

Ce schéma représente exactement ce qui se passe côté serveur quand un visiteur demande une page. Imprimez-le mentalement, c'est la clé pour comprendre toutes les optimisations.

Où se perd le temps côté serveur PrestaShop - Navigateur, CDN, Serveur web, PHP, MySQL jusqu'au TTFB
Visualisation simplifiée : où se perd le temps côté serveur.

Version détaillée du pipeline :

Visiteur / Bot
     |
     v
DNS / Cloudflare
     |
     v
Serveur Web (LiteSpeed / Apache)
     |
     ├──► LSCache ?
     │        |
     │        ├── HIT  → HTML servi directement (20–100 ms) ✅ FIN
     │        |
     │        └── MISS → exécution complète 👇
     |
     v
Bootstrap PrestaShop
(init.php, autoload, config)
     |
     ├─ Chargement 100–300 fichiers PHP
     ├─ Lecture configuration (DB)
     ├─ Construction du contexte (langue, devise, client, panier)
     |
     ⏱️ 30–150 ms (OPcache chaud, VPS/dédié)
     ⏱️ 100–300 ms (mutualisé)
     ⏱️ 200–700 ms (sans OPcache ❌)
     |
     v
Modules ACTIFS
     |
     ├─ Fichiers chargés
     ├─ Hooks enregistrés
     |
     ⏱️ 50–400 ms selon nombre/qualité des modules
     |
     v
Exécution des hooks
(displayHeader, displayHome, etc.)
     |
     ├─ Code PHP modules
     ├─ Appels SQL
     |
     ⏱️ Variable → souvent le vrai goulot
     |
     v
MySQL
     |
     ├─ Memcached ?
     │      ├─ HIT  → réponse immédiate
     │      └─ MISS → requête SQL
     |
     ├─ Index présent ?
     │      ├─ OUI → index lookup (rapide)
     │      └─ NON → full table scan ❌
     |
     ⏱️ 20 ms → 2000 ms (selon index)
     |
     v
Smarty
     |
     ├─ Templates compilés ?
     │      ├─ Oui → cache utilisé
     │      └─ Non → recompilation + I/O disque ❌
     |
     ⏱️ 20–100 ms
     |
     v
HTML généré
     |
     v
Compression (Brotli / Gzip)
     |
     v
Réponse HTTP envoyée
     |
     v
Navigateur

🔥 Lecture clé du schéma

✅ Ce que LSCache fait réellement

LSCache court-circuite 100% de la chaîne PHP/MySQL/Smarty pour les pages publiques.

Quand le cache est HIT, rien d'autre n'est exécuté.

❌ Ce que LSCache ne fait PAS
  • Panier
  • Checkout
  • Compte client
  • AJAX / API

👉 Ces pages passent TOUJOURS par tout le pipeline.

D'où l'importance de : OPcache (bootstrap), Index MySQL (requêtes), Audit des modules (hooks) — même avec LSCache actif.

Energiedin intervient principalement sur la vitesse serveur des sites PrestaShop — là où se joue la performance réelle ressentie par les utilisateurs, bien au-delà des scores marketing.

🎯 Version "mental model" (ultra-synthèse)

Page publique ? | ├─ Oui → LSCache → 50 ms → FIN | └─ Non → Bootstrap → Modules → Hooks → MySQL → Smarty → HTML
💡 La vérité fondamentale

Tant que votre serveur n'a pas terminé cette chaîne d'exécution,
le navigateur ne peut strictement rien afficher.

Optimiser le frontend avant d'avoir raccourci ce pipeline serveur
revient à peindre une voiture dont le moteur est encore démonté.

🩺 Règles de diagnostic rapide (utilisez ce schéma)

Si TTFB lent, posez-vous ces 3 questions :

Pages publiques lentes ? → Problème de cache HIT faible : cookies, variations, exclusions LSCache. Section 8
Panier/checkout lent ? → Problème hooks/modules sur actionCartSave, displayShoppingCart, etc. Section 9
Admin lent ? → Souvent MySQL (requêtes stats) + modules back-office. Section 2

Où perd-on 80% du temps ?

Étape Temps typique Optimisation Gain
Serveur web 5-20ms LiteSpeed + LSCache Élimine tout le reste (pages publiques)
Bootstrap PHP 30-300ms OPcache Significatif (mesurez avant/après)
Modules 50-400ms Désinstaller les inutiles Variable selon modules retirés
Hooks Variable Profiler + supprimer Souvent le plus gros gain
MySQL 20-2000ms Index + Memcached Très variable (full scan → index)
Smarty 20-100ms "Jamais recompiler" Élimine les I/O disque

📊 Ordres de grandeur par levier d'optimisation

Ces gains sont des ordres de grandeur observés sur des boutiques réelles (stack LiteSpeed + PHP 8.x). Ils varient selon thème, modules, catalogue, trafic et CPU. Mesurez avant/après sur votre propre installation.

Action Métrique impactée Gain typique Cas réel
OPcache activé Temps compilation PHP Élimine la recompilation TTFB : variable selon bootstrap
Index MySQL ajouté Temps de LA requête ciblée Variable (full scan → index lookup) Ex mesuré : 1200ms → 20ms
LSCache activé TTFB pages publiques en cache Très significatif Ex mesuré : ~1000ms → 50ms (cache HIT)
Bot Fight Mode Charge serveur Variable (à mesurer) Dépend de la part de bots malveillants
Memcached Requêtes MySQL répétitives Variable selon ce qui est caché Effet sur TTFB : modéré
Modules désinstallés Temps bootstrap Variable Dépend des modules (stats, sliders = gros gains)
"Jamais recompiler" I/O disque (stat() sur fichiers) Élimine les vérifications Gain faible mais systématique
Images WebP Poids des images -25 à -35% vs JPEG optimisé Impact sur temps de chargement perçu

Matrice de compatibilité PHP / PrestaShop (source officielle)

PrestaShop 1.6 et 1.7 :

PrestaShop 5.67.07.17.27.37.48.0+
1.6.1.x ✓✓★✗✗✗✗
1.7.0 ~ 1.7.3 ✓✓★✗✗✗✗
1.7.5 ~ 1.7.6 ✓✓✓★✗✗✗
1.7.7 ✗✗✓✓★✗✗
1.7.8 ✗✗✓✓✓★✗

PrestaShop 8.x :

PrestaShop ≤7.17.27.37.48.08.1≥8.2
8.0 ~ 8.2 ✗✓✓✓✓★✗

PrestaShop 9.x :

PrestaShop ≤8.08.18.28.38.4≥8.5
9.0 ✗✓✓✓★✗

Légende : ✓ = Compatible | ★ = Version recommandée | ✗ = Non compatible
Source : Documentation officielle PrestaShop

⚠️ "Recommandé" = version officiellement supportée + la plus stable pour modules/thèmes.
Des combinaisons "ça marche chez moi" existent (ex: PS 1.7.8 sur PHP 8.0), mais elles sont hors support officiel. En cas de bug, vous serez seul.
PHP MySQL Memcached LiteSpeed Cloudflare

⚡ Quick Check : votre PrestaShop est-il optimisé ?

Vérifiez ces 6 points en 2 minutes. Si tout est vert, vous êtes déjà bien optimisé.

php -i | grep opcache.enable → doit afficher On
echo "stats" | nc localhost 11211 → doit répondre (Memcached actif)
PrestaShop → Paramètres avancés → Performances → Cache activé, "Jamais recompiler"
curl -I votre-site.com | grep -i x-litespeed-cache → doit afficher hit (LSCache)
⚠️ 1ère requête = miss, c'est normal. Relancez 2×.
Cloudflare → Speed → Overview → CDN actif, Brotli On
curl -o /dev/null -s -w "%{time_starttransfer}" https://votre-site.com/ → TTFB < 200ms = excellent

Un point rouge ? Suivez la section correspondante ci-dessous.

🏠 Ce que vous pouvez faire selon votre hébergement

Type Ce que vous pouvez faire Ce que vous ne pouvez PAS faire
Mutualisé
(OVH, Ionos...)		 Sections 4, 5, 9, 10, 12-14
PrestaShop, modules, Cloudflare, images		 Sections 1-3, 6-8
Pas d'accès SSH, pas de config PHP/MySQL
VPS / Cloud
(o2switch, Scaleway...)		 Tout (avec accès root) -
Dédié / cPanel
(WHM, Plesk...)		 Tout + optimisations serveur avancées -

💡 Conseil : Sur mutualisé, les gains sont limités. Si votre TTFB dépasse 500ms malgré les optimisations possibles, envisagez un VPS (à partir de 5€/mois).

📌 Mutualisé sans SSH ? Ce guide couvre serveur + application. Sautez directement aux sections 4, 5, 9, 10 et 12-14. Les sections 1-3 et 6-8 nécessitent un accès SSH ou root.

🛡️ Avant de commencer : backup et environnement de test

Ne jamais tester en production. Avant toute modification :

  1. Backup complet : fichiers + base de données
  2. Environnement de staging : clone de votre site pour tester
  3. Plan de rollback : savoir revenir en arrière en 5 minutes
# Backup rapide avant modifications
mysqldump -u user -p votre_base > backup_$(date +%Y%m%d_%H%M).sql
tar -czf backup_files_$(date +%Y%m%d_%H%M).tar.gz public_html/

# Rollback si problème
mysql -u user -p votre_base < backup_XXXXXXXX.sql

💡 Astuce staging : Softaculous (cPanel) permet de cloner un site en 1 clic. Sinon : sous-domaine + copie fichiers + dump SQL → import.

Objectif réaliste de ce guide

Pages publiques (cache HIT) TTFB < 200ms
Pages dynamiques (panier, checkout, compte) TTFB < 500ms

Ce que ce guide vous permet de faire :

  • ✅ Réduire le TTFB de manière mesurable et reproductible
  • ✅ Stabiliser le serveur sous charge (plus de timeout, moins de load)
  • ✅ Éviter les optimisations placebo qui font perdre du temps sans résultat
Compatibilité PHP — Versions recommandées

PrestaShop 1.6.1.x→ PHP 7.1 (recommandé)
PrestaShop 1.7.x→ Varie : 7.1 à 7.4 selon sous-version
PrestaShop 8.x→ PHP 8.1 (recommandé)
PrestaShop 9.x→ PHP 8.4 (recommandé)
Les commandes PHP 8+ de ce guide (ea-php81, etc.) ne s'appliquent qu'à PrestaShop 8/9.

1. Diagnostic initial du serveur

En résumé : Avant de soigner, il faut diagnostiquer. Cette étape permet de voir si votre serveur est en bonne santé ou s'il "étouffe" sous la charge. On vérifie la mémoire disponible, l'utilisation du processeur et quels programmes consomment le plus de ressources. 🏥 C'est comme un médecin qui prend votre tension et votre température avant de vous prescrire quoi que ce soit.
Complexité : ★☆☆☆☆ Facile Impact : ☆☆☆☆☆ Observation

Avant toute optimisation, on doit comprendre l'état actuel du serveur. Voici les commandes essentielles :

# Charge système et mémoire
uptime
free -h

# Espace disque
df -h /

# Processus les plus gourmands en CPU
ps aux --sort=-%cpu | head -15

# Processus les plus gourmands en mémoire
ps aux --sort=-%mem | head -15
🖱️ Pas d'accès SSH ? Consultez cPanel → Server Status ou Resource Usage pour voir la charge serveur. Votre hébergeur (o2switch, OVH, Infomaniak...) propose souvent un tableau de bord avec ces métriques.

Ce qu'on cherche :

  • Load average : idéalement inférieur au nombre de CPU
  • Swap : si trop utilisé, c'est signe de manque de RAM
  • MySQL : souvent le processus le plus gourmand
  • lsphp : les processus PHP PrestaShop

🩺 Symptôme → Cause probable → Section à lire

Symptôme observé Cause probable Section
TTFB > 500ms sur toutes les pages OPcache absent ou mal configuré Section 6
TTFB lent uniquement sur certaines pages Requêtes SQL sans index ou module lent Section 2 + Section 9
Ajout au panier très lent (> 1s) Module avec hook cart mal optimisé Section 9 (audit de code)
Site rapide puis lent après quelques heures Buffer Pool trop petit ou tables trop grosses Section 2 + Section 4
Load average élevé, CPU à 100% Bots / attaques ou OPcache absent Section 10 + Section 6
Swap utilisé > 1GB Manque de RAM, trop de processus PHP Augmenter RAM ou réduire MaxProcesses
Pages produit lentes, listing rapide Module sur hook displayProductAdditionalInfo Section 9
Tout est lent sauf l'admin LSCache actif en admin mais cache HIT=0 en front Section 8
  • Diagnostiquez avant d'optimiser — ne pas appliquer des solutions au hasard
  • Utilisez le tableau ci-dessus pour identifier la cause probable
  • Un bon diagnostic = une optimisation ciblée et efficace

MySQL2. Audit MySQL en temps réel

En résumé : MySQL est la base de données qui stocke tout : vos produits, clients, commandes, etc. Quand votre site est lent, c'est souvent parce que la base met trop de temps à retrouver les informations demandées. Cet audit permet d'identifier précisément quelles requêtes prennent trop de temps. 🔍 Imaginez une bibliothèque géante sans classement. Chaque fois qu'un client demande un livre, le bibliothécaire doit fouiller partout. L'audit nous montre quels "livres" sont demandés souvent et prennent trop de temps à trouver.
Complexité : ★★★☆☆ Moyenne Impact : ★★★★☆ Élevé

C'est l'étape la plus importante. On va identifier les requêtes qui posent problème pendant que le site est sous charge.

Optimiser la vitesse d'un site PrestaShop nécessite des compétences de développement backend, bien au-delà du marketing ou des outils de scoring. C'est ce type d'intervention technique qu'Energiedin réalise au quotidien.

Étape 1 : Activer le slow query log

# Se connecter à MySQL et activer le monitoring
mysql -e "SET GLOBAL slow_query_log = 'ON';"
mysql -e "SET GLOBAL long_query_time = 0.5;"
mysql -e "SET GLOBAL log_queries_not_using_indexes = 'ON';"

Étape 2 : Lancer un test de charge

Utilisez un outil comme analyse-seo.net pour générer du trafic intensif pendant que vous surveillez MySQL. L'audit en temps réel permet d'identifier les requêtes problématiques sous charge réelle.

🖱️ Pas d'accès SSH ? Vous pouvez exécuter ces commandes SQL directement dans phpMyAdmin (accessible depuis cPanel/Plesk). Pour le monitoring en temps réel, regardez l'onglet "État" ou "Statut du serveur" dans phpMyAdmin.

Étape 3 : Surveiller en temps réel

# Voir les requêtes en cours d'exécution
mysql -e "SHOW FULL PROCESSLIST\G"

# Charge système
cat /proc/loadavg

# Nombre de connexions MySQL
mysql -e "SHOW STATUS LIKE 'Threads_connected';"

Étape 4 : Analyser les requêtes lentes

# Top des temps de requête les plus longs
grep "Query_time:" /var/lib/mysql/slow.log | awk '{print $3}' | sort -rn | head -20

# Requêtes SELECT les plus fréquentes
grep -E "^SELECT" /var/lib/mysql/slow.log | sort | uniq -c | sort -rn | head -15

# Requêtes qui examinent beaucoup de lignes (full table scan)
grep -B5 "Rows_examined: [0-9]\{4,\}" /var/lib/mysql/slow.log | grep -E "^SELECT"

Étape 5 : Vérifier les métriques clés

# Buffer pool hit ratio (doit être > 99%)
mysql -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';"
mysql -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';"

# Calcul : (read_requests - reads) / read_requests * 100
Astuce : Concentrez-vous sur les requêtes qui apparaissent très souvent dans les logs. Une requête de 50ms exécutée 10 000 fois a plus d'impact qu'une requête de 2 secondes exécutée 5 fois.
⚠️ Après votre test, remettez les variables comme avant : 
mysql -e "SET GLOBAL slow_query_log = 'OFF';"
mysql -e "SET GLOBAL long_query_time = 10;"
mysql -e "SET GLOBAL log_queries_not_using_indexes = 'OFF';"
Note MySQL 8+ / MariaDB 10.1.7+ : Si vous cherchez le "Query Cache", sachez qu'il a été supprimé depuis MySQL 8.0 (deprecated en 5.7). MariaDB l'a gardé mais désactivé par défaut depuis 10.1.7. Ne perdez pas de temps à le configurer — les alternatives modernes sont plus efficaces : OPcache (cache PHP), Memcached (cache applicatif), ou LSCache (cache full-page).
  • L'audit révèle les vrais coupables — pas besoin de deviner
  • Concentrez-vous sur les requêtes fréquentes, pas les plus lentes
  • Une requête de 50ms × 10 000 exécutions = 500s de CPU gaspillé

3. Création d'index optimisés

En résumé : Un index, c'est un raccourci pour trouver des données plus vite. Sans index, MySQL doit parcourir toute la table (parfois des millions de lignes) pour trouver ce qu'il cherche. Avec un bon index, il trouve instantanément. 📚 L'index, c'est le catalogue qui vous dit "Les livres de cuisine sont au rayon 7, étagère 3". Sans catalogue, vous devriez parcourir chaque étagère.
Complexité : ★★★★★ Avancée Impact : ★★★★★ Très élevé

Une fois les requêtes problématiques identifiées, on analyse leur plan d'exécution avec EXPLAIN.

Analyser une requête avec EXPLAIN

# Exemple avec une requête identifiée comme fréquente
mysql votre_base -e "EXPLAIN SELECT rate, reviews_nb
FROM ps_steavisgarantis_average_rating
WHERE product_id = 12345 AND id_lang = 1;"
Type Signification
ALL Full table scan - mauvais, à corriger
ref Utilise un index - bon
const Accès direct - optimal

Créer un covering index

Un covering index inclut toutes les colonnes de la requête. MySQL n'a plus besoin d'accéder à la table, il lit uniquement l'index.

# Pour la requête : SELECT rate, reviews_nb WHERE product_id = X AND id_lang = Y
# On crée un index qui couvre product_id, id_lang ET les colonnes SELECT

mysql votre_base -e "CREATE INDEX idx_perf_rating
ON ps_steavisgarantis_average_rating(product_id, id_lang, rate, reviews_nb);"

# Vérifier que l'index est utilisé (doit afficher "Using index")
mysql votre_base -e "EXPLAIN SELECT rate, reviews_nb
FROM ps_steavisgarantis_average_rating
WHERE product_id = 12345 AND id_lang = 1;"
Résultat : EXPLAIN doit maintenant afficher type: ref (ou range/const selon la requête) avec Extra: Using index au lieu de type: ALL. Note : type: index = full index scan, ce n'est pas optimal.

Mettre à jour les statistiques

# Après création d'index, analyser les tables
mysql votre_base -e "ANALYZE TABLE ps_steavisgarantis_average_rating,
ps_product, ps_product_lang, ps_specific_price;"
  • Un bon index = requête 100× plus rapide (de 500ms à 5ms)
  • Créez des index uniquement sur les requêtes identifiées dans l'audit
  • Vérifiez toujours avec EXPLAIN que l'index est bien utilisé

4. Nettoyage des tables PrestaShop

En résumé : PrestaShop stocke énormément de données "au cas où" : logs d'erreurs, pages introuvables, statistiques de connexion... Au fil du temps, ces tables grossissent et ralentissent tout le système. 🧹 C'est comme faire le ménage dans un entrepôt. Plus il y a de cartons inutiles entassés, plus il est difficile de circuler.
Complexité : ★★☆☆☆ Facile Impact : ★★★☆☆ Moyen

Identifier les tables volumineuses

mysql votre_base -e "SELECT table_name,
    ROUND(data_length/1024/1024,2) as data_mb,
    table_rows
FROM information_schema.tables
WHERE table_schema='votre_base'
ORDER BY data_length DESC
LIMIT 15;"

Tables à nettoyer régulièrement

Table Contenu Action
ps_log Logs applicatifs PrestaShop Garder 30 jours max
ps_pagenotfound Erreurs 404 Vider complètement
ps_connections Connexions visiteurs Garder 90 jours max 
# Nettoyer les logs de plus de 30 jours
mysql votre_base -e "DELETE FROM ps_log
WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);"

# Vider la table des erreurs 404
mysql votre_base -e "TRUNCATE TABLE ps_pagenotfound;"

# Récupérer l'espace disque
mysql votre_base -e "OPTIMIZE TABLE ps_log, ps_pagenotfound;"
🖱️ Alternative sans ligne de commande : Utilisez phpMyAdmin (disponible dans votre cPanel/Plesk) pour exécuter ces requêtes SQL. Copiez simplement les commandes entre guillemets dans l'onglet "SQL".
  • PrestaShop accumule des données inutiles qui ralentissent MySQL
  • Un nettoyage mensuel peut libérer plusieurs Go et accélérer les requêtes
  • Automatisez avec une tâche CRON pour ne plus y penser

5. Réglages de performance PrestaShop

En résumé : PrestaShop possède des réglages intégrés qui peuvent doubler la vitesse de votre site sans toucher au serveur. Le plus important : dire à PrestaShop de ne pas vérifier à chaque visite si les fichiers ont changé.
Complexité : ★☆☆☆☆ Très facile Impact : ★★★★☆ Élevé

Paramètres avancés → Performances

Paramètre Valeur recommandée Explication
Mode debug Non Le mode debug ralentit fortement le site
Recompiler les templates Jamais recompiler En production, les templates ne changent pas
Cache Oui Active le système de cache PrestaShop
Combinaison CCC Tout activer Combine et minifie CSS/JS
Important : L'option "Jamais recompiler les templates" est cruciale. En mode "Si les fichiers ont été modifiés", Smarty vérifie chaque fichier à chaque requête, ce qui génère beaucoup d'I/O inutiles.

CCC : Combine, Compress, Cache

Dans la section CCC, activez :

  • Smart cache pour CSS : Oui
  • Smart cache pour JavaScript : Oui
  • Minification HTML : Oui (si disponible)
  • Compression des images (AVIF/WebP) : Oui si supporté

Note sur les "Serveurs de média"

Cette option PrestaShop est obsolète depuis HTTP/2. Elle servait à paralléliser les téléchargements via plusieurs sous-domaines. Avec HTTP/2 (supporté par LiteSpeed), le multiplexing rend cette technique inutile. Laissez ces champs vides.

Conseil : Pour de meilleures performances, privilégiez un hébergement avec LiteSpeed plutôt qu'Apache. LiteSpeed offre un cache intégré (LSCache) très performant avec PrestaShop et consomme moins de ressources.
  • Ces réglages sont gratuits et immédiats — aucune compétence technique requise
  • "Jamais recompiler" = gain immédiat de 10-20% sur chaque requête
  • Activez tout sauf les "Serveurs de média" (obsolètes avec HTTP/2)

PHP6. Installation et configuration d'OPcache

En résumé : PHP est le langage qui fait tourner PrestaShop. OPcache garde la traduction du code PHP en mémoire pour ne pas la refaire à chaque fois. C'est l'optimisation avec le meilleur rapport effort/gain. 🧠 Imaginez un interprète qui traduit un discours. Sans OPcache, il retraduit chaque phrase depuis le début à chaque fois. Avec OPcache, il mémorise les traductions déjà faites.
Complexité : ★★☆☆☆ Moyenne Impact : ★★★★★ Très élevé

OPcache met en cache le bytecode PHP compilé. C'est l'optimisation avec le meilleur rapport effort/gain.

Vérifier si OPcache est installé

php -m | grep -i opcache

Installation (cPanel/CloudLinux)

# Installer OPcache pour PHP 8.1
yum install -y ea-php81-php-opcache

# Redémarrer le serveur web
systemctl restart lsws

Configuration optimale

[opcache]
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.revalidate_freq=2
opcache.validate_timestamps=1
  • OPcache = gain immédiat de 30 à 60% sur le temps de génération PHP
  • Pas besoin de toucher au code PrestaShop
  • Si vous ne faites qu'une seule optimisation, faites celle-ci

Memcached7. Installation et configuration de Memcached

En résumé : Memcached est une mémoire ultra-rapide qui stocke les données fréquemment demandées. Au lieu d'interroger MySQL à chaque fois (ce qui prend du temps), PrestaShop regarde d'abord dans Memcached. Si l'info y est, c'est instantané.
Complexité : ★★★☆☆ Moyenne (accès serveur) Impact : ★★★☆☆ Variable selon charge

Memcached stocke les objets PHP et résultats de requêtes en mémoire, réduisant la charge sur MySQL.

Impact variable : L'effet de Memcached dépend de votre configuration. Sur un site avec LSCache actif, la plupart des pages sont servies sans PHP → Memcached est peu sollicité. L'impact se mesure surtout sur les pages dynamiques (panier, checkout, compte). À tester avant/après pour évaluer le gain réel.
💡 Memcached vs Redis — Lequel choisir ?
Memcached Redis
Complexité Simple, peu de config Plus polyvalent, plus de paramètres
Persistance Non (volatile) Oui (optionnel)
Structures Clé/valeur uniquement Listes, sets, hashes...
Pour PrestaShop Supporté nativement (intégré au core) Nécessite un module tiers

Verdict : Ce guide utilise Memcached car il est supporté nativement par PrestaShop (option dans Paramètres avancés > Performances). Redis nécessite un module tiers (ex: "Redis Cache" sur Addons) et une configuration supplémentaire. Pour un site PrestaShop standard, Memcached suffit largement. Redis est pertinent si vous avez d'autres applications qui l'utilisent déjà (Laravel, file de jobs, sessions partagées, etc.).

Note PrestaShop 8 : Dans les options de cache de PrestaShop 8, choisissez "Memcached via PHP::Memcached" (avec un 'd' à la fin). C'est l'extension moderne, plus performante que l'ancienne "Memcache".

Installation

# Installer Memcached et l'extension PHP
yum install -y memcached ea-php81-php-memcached

# Démarrer et activer le service
systemctl enable memcached
systemctl start memcached

# Redémarrer LiteSpeed
systemctl restart lsws

Configuration de Memcached

Éditez /etc/sysconfig/memcached pour allouer plus de mémoire :

# Passer de 64MB à 512MB
CACHESIZE="512"
# Redémarrer Memcached
systemctl restart memcached

# Vérifier que ça fonctionne
echo "stats" | nc localhost 11211 | head -5

Configuration dans PrestaShop

  1. Allez dans Paramètres avancés > Performances
  2. Section Cache : activez-le
  3. Choisissez Memcached via PHP::Memcached
  4. Ajoutez un serveur :
    • Serveur : 127.0.0.1
    • Port : 11211
    • Poids : 1
  5. Enregistrez
Si l'option Memcached n'apparaît pas : Videz le cache PrestaShop (rm -rf var/cache/*) et rafraîchissez la page.
🖱️ Pas d'accès SSH ? Demandez à votre hébergeur d'installer et configurer Memcached pour vous. Sur les hébergements mutualisés type o2switch, Memcached est souvent préinstallé — il suffit de l'activer dans PrestaShop.
  • Memcached stocke les sessions et objets PHP en RAM (plus rapide que la base)
  • Réduit la charge MySQL de 20-40% sur les pages dynamiques
  • Configuration simple : juste quelques clics dans l'admin PrestaShop

LiteSpeed8. Pourquoi choisir un serveur LiteSpeed

En résumé : LiteSpeed est un serveur web conçu pour la performance. Il intègre un système de cache très puissant appelé LSCache qui peut transformer les performances de votre boutique.
Complexité : ★★☆☆☆ Choix hébergeur Impact : ★★★★★ Très élevé

LiteSpeed vs Apache : les différences clés

Critère Apache LiteSpeed
Consommation mémoire Élevée (fork par connexion) Faible (event-driven)
Visiteurs simultanés Limité par la RAM Milliers sans problème
Cache intégré Non (nécessite Varnish) Oui (LSCache)
Compatibilité .htaccess Native 100% compatible
HTTP/3 & QUIC Non Oui
Prix Gratuit Inclus chez la plupart des hébergeurs cPanel

LSCache : le cache intégré de LiteSpeed

LSCache est le vrai atout de LiteSpeed pour PrestaShop. Il met en cache les pages entières au niveau du serveur, avant même que PHP ne soit exécuté.

Résultat concret : Une page qui met 800ms à se générer avec PHP est servie en 20-50ms depuis LSCache. C'est 15 à 40 fois plus rapide.

Installer le module LSCache pour PrestaShop

  1. Téléchargez le module officiel sur litespeedtech.com
  2. Installez-le via le back-office PrestaShop (Modules → Ajouter un module)
  3. Configurez les options de base :
    • Enable LiteSpeed Cache : Oui
    • Public Cache TTL : 86400 (24h)
    • Private Cache TTL : 1800 (30 min)

Vérifier que LSCache fonctionne

# Dans le terminal, vérifier les headers HTTP
curl -I https://votre-site.com/ | grep -i x-litespeed-cache

# Vous devez voir :
# X-LiteSpeed-Cache: hit    (page servie depuis le cache)
# X-LiteSpeed-Cache: miss   (page générée puis mise en cache)

Pages publiques vs pages dynamiques

LSCache ne peut pas tout cacher. Comprendre quelles pages sont cachées est essentiel :

Type de page Exemples Cachée par LSCache ? Goulot d'étranglement réel
Pages publiques Accueil, catégories, fiches produits, CMS ✅ Oui Aucun si cache actif (50-100ms)
Pages semi-dynamiques Recherche, filtres, pagination ⚠️ Partiel MySQL (requêtes de recherche)
Pages privées Mon compte, historique commandes ❌ Non Bootstrap + MySQL
Pages transactionnelles Panier, checkout, paiement ❌ Non Bootstrap + modules paiement
Ajax/API Ajout panier, mise à jour quantité ❌ Non PHP + hooks modules
💡 Règle d'or : Si votre page publique n'est pas servie depuis le cache, c'est que votre stratégie de cache est mal configurée — pas que votre serveur est trop faible. Vérifiez vos règles d'exclusion et les cookies qui invalident le cache.

Variations de cache : les pièges à éviter

LSCache crée des variations de cache selon différents critères. Trop de variations = cache inefficace :

Critère de variation Comportement Impact sur le cache
Langue 1 version cachée par langue Acceptable (nécessaire)
Devise 1 version cachée par devise Acceptable (nécessaire)
Groupe client 1 version par groupe (grossiste, particulier...) ⚠️ Attention si > 3 groupes
Cookies tracking Peut créer 1 version par visiteur ! ❌ Critique — exclure ces cookies du cache
Paramètres GET ?utm_source, ?gclid créent des variations ❌ Configurer LSCache pour ignorer ces paramètres 
# Vérifier les variations de cache dans les headers
curl -I "https://votre-site.com/" | grep -i "vary"

# "Vary: Accept-Encoding" → Normal
# "Vary: Cookie" → ⚠️ Peut fragmenter le cache
Purge du cache : LSCache se purge automatiquement quand vous modifiez un produit/catégorie. Si vous avez un doute, purgez manuellement via le module LSCache dans l'admin PrestaShop. La commande curl -X PURGE ne fonctionne que si la méthode PURGE est autorisée dans votre configuration LiteSpeed (désactivée par défaut sur certains hébergeurs).
Comment passer à LiteSpeed ? Si votre hébergeur utilise cPanel, demandez-leur d'activer LiteSpeed (souvent gratuit ou inclus). Sinon, envisagez de migrer vers un hébergeur qui le propose : o2switch, PlanetHoster, Infomaniak, etc.

Complémentarité avec les autres optimisations

LiteSpeed et LSCache ne remplacent pas les autres optimisations, ils les complètent :

  • OPcache accélère l'exécution PHP → LSCache évite d'exécuter PHP du tout
  • Memcached accélère les requêtes MySQL → LSCache évite de faire les requêtes du tout
  • Les index MySQL restent utiles pour les pages dynamiques (panier, compte client, checkout)
⚠️ LSCache = pages publiques uniquement !
LSCache ne met PAS en cache : panier, checkout, compte client, pages avec paramètres GET uniques, et la première visite après purge.

Ces pages passent par le pipeline complet : PHP bootstrap → hooks modules → requêtes MySQL → Smarty.
C'est pourquoi toutes les autres optimisations restent indispensables (OPcache, index MySQL, audit modules).
  • LiteSpeed + LSCache = TTFB < 100ms sur les pages publiques (visiteurs non connectés)
  • Fonctionne automatiquement, pas de code à modifier
  • Les pages panier/checkout restent dynamiques → gardez les autres optimisations

9. Audit et nettoyage des modules

En résumé : Les modules actifs consomment des ressources à chaque requête (PHP, hooks, SQL). Les modules désactivés créent une dette technique. Un audit régulier permet d'identifier et désinstaller les modules inutiles.
Complexité : ★★☆☆☆ Facile Impact : ★★★★☆ Élevé

Le coût caché du bootstrap PrestaShop

Avant même d'exécuter la moindre logique métier, PrestaShop doit :

  • Charger 100-300 fichiers PHP (classes, controllers, config — varie selon les modules)
  • Initialiser l'autoloader Composer
  • Lire la configuration en base (plusieurs dizaines de requêtes SQL)
  • Instancier les modules actifs et vérifier la table des hooks
  • Construire le contexte (langue, devise, client, panier)

Coût du bootstrap (varie selon CPU, I/O, OPcache, nombre de modules) :

  • Avec OPcache chaud : 30-150ms (VPS/dédié) à 100-300ms (mutualisé)
  • Sans OPcache : 200-700ms (recompilation PHP à chaque requête)
  • Page en cache LSCache : bootstrap non exécuté — réponse directe du serveur web

Pour mesurer votre bootstrap réel : activez _PS_DEBUG_PROFILING_ temporairement et consultez le rapport en bas de page.

Coût runtime vs dette technique :
• Modules actifs = coût à chaque requête (chargés, hooks exécutés)
• Modules désactivés = pas de coût runtime, mais dette possible : crons orphelins, tables en base, overrides résiduels, assets scannés, entrées autoload selon implémentation

Le coût runtime vient des modules actifs. Les modules désactivés coûtent surtout en dette (crons, tables, overrides), pas en exécution directe.

Pourquoi désinstaller et pas seulement désactiver ?

Un module désactivé conserve :

  • Ses fichiers sur le serveur (espace disque, inclus dans les scans)
  • Ses tables dans la base de données
  • Ses entrées dans la configuration PrestaShop
  • Potentiellement des tâches cron actives qui continuent de s'exécuter
  • Des hooks enregistrés que PrestaShop vérifie à chaque chargement
Cas réel : Un module de statistiques "désactivé" qui continue d'enregistrer chaque visite en base de données, ou un module d'import qui vérifie toutes les heures si un fichier existe. Désactiver ne suffit pas !
Action Fichiers PHP Tables SQL Hooks Crons
Désactiver Restent Restent Retirés Peuvent subsister
Désinstaller Restent (sauf si supprimés) Supprimées (généralement) Retirés Supprimés
Désinstaller + supprimer Supprimés Supprimées Retirés Supprimés
Modules désactivés : Les hooks ne sont pas exécutés, mais les fichiers restent, les tables aussi. C'est de la dette technique. Si vous n'utilisez plus un module, désinstallez-le complètement.

Comment auditer vos modules

  1. Allez dans Modules → Module Manager
  2. Filtrez par "Modules installés"
  3. Pour chaque module, posez-vous la question : "Est-ce que je l'utilise vraiment ?"
  4. Vérifiez les modules désactivés : si désactivé depuis longtemps → désinstallez

Modules souvent inutiles à supprimer

Module Problème Alternative
Statistiques PrestaShop (natifs) Requêtes SQL lourdes, calculs en temps réel Google Analytics / Matomo
Modules de paiement inactifs Hooks inutiles au checkout Désinstaller complètement
Sliders / Carrousels lourds JavaScript bloquant, images non optimisées Image statique ou CSS uniquement
Modules SEO redondants Plusieurs modules qui font la même chose Un seul module SEO bien configuré
ps_eventbus / ps_accounts Appels HTTP synchrones vers les serveurs PrestaShop Désactiver si vous n'utilisez pas PrestaShop Metrics
Modules de partage social Scripts externes, tracking tiers Simples liens HTML vers les réseaux

Identifier les modules lents

Activez le mode debug temporairement pour voir le temps d'exécution par hook :

# Dans config/defines.inc.php, temporairement :
define('_PS_MODE_DEV_', true);
define('_PS_DEBUG_PROFILING_', true);

# Rechargez une page front-office
# En bas de page, vous verrez le temps passé dans chaque hook/module
# Identifiez les modules qui prennent > 50ms

# IMPORTANT : Remettez à false après le test !
define('_PS_MODE_DEV_', false);
define('_PS_DEBUG_PROFILING_', false);
Avant de désinstaller : Faites une sauvegarde de la base de données. Certains modules suppriment leurs données à la désinstallation (ce qui est normal), mais mieux vaut pouvoir revenir en arrière.

🔬 Audit de code : overrides et modules personnalisés

Si vous avez des modules développés sur mesure ou des overrides, ils peuvent contenir des problèmes de performance invisibles.

Où chercher les problèmes

# Lister tous les overrides
ls -la override/classes/
ls -la override/controllers/

# Trouver les modules avec overrides
find modules/ -name "*.php" -path "*/override/*" -type f

# Vérifier les hooks sur le panier
mysql votre_base -e "SELECT h.name, m.name
FROM ps_hook h
JOIN ps_hook_module hm ON h.id_hook = hm.id_hook
JOIN ps_module m ON hm.id_module = m.id_module
WHERE h.name LIKE '%cart%' OR h.name LIKE '%Cart%'
ORDER BY h.name;"

Anti-patterns courants à corriger

❌ Anti-pattern Problème ✅ Solution
Db::getInstance()->executeS() dans une boucle N+1 queries Une seule requête avec IN() ou JOIN
Product::getProducts() répété Même requête exécutée plusieurs fois Mettre en cache dans une variable static
Appels HTTP synchrones (cURL, file_get_contents) Bloque l'exécution, timeout possible Appels asynchrones ou en cron
SELECT * au lieu de colonnes spécifiques Charge des données inutiles Sélectionner uniquement les colonnes nécessaires
Pas de LIMIT sur les requêtes Peut charger des millions de lignes Toujours paginer avec LIMIT
Calculs complexes dans les hooks fréquents Exécuté à chaque requête Précalculer et stocker en BDD ou cache

Exemple de correction : pattern N+1 → Batch query

// ❌ Mauvais : N+1 requêtes
foreach ($product_ids as $id) {
    $product = new Product($id);
    $names[] = $product->name;
}

// ✅ Bon : 1 seule requête
$sql = 'SELECT id_product, name FROM '._DB_PREFIX_.'product_lang
        WHERE id_product IN ('.implode(',', array_map('intval', $product_ids)).')
        AND id_lang = '.(int)$id_lang;
$products = Db::getInstance()->executeS($sql);

Exemple de correction : éviter getProducts() répété

// ❌ Mauvais : appelé plusieurs fois
public function hookDisplayHome() {
    $products = Product::getProducts($id_lang, 0, 10, 'id_product', 'ASC');
    // ...
}

// ✅ Bon : cache statique
private static $cachedProducts = null;

public function hookDisplayHome() {
    if (self::$cachedProducts === null) {
        self::$cachedProducts = Product::getProducts($id_lang, 0, 10, 'id_product', 'ASC');
    }
    $products = self::$cachedProducts;
    // ...
}
  • Les modules sont souvent les vrais coupables des lenteurs PrestaShop
  • Désactivez/supprimez tout ce qui n'est pas utilisé
  • 1 module mal codé peut annuler toutes vos autres optimisations

Cloudflare10. Cloudflare : CDN gratuit et protection anti-bots

En résumé : Cloudflare est un service gratuit qui met en cache les fichiers statiques sur ses serveurs dans le monde entier, et bloque les robots malveillants avant qu'ils n'atteignent votre serveur.
Complexité : ★★★☆☆ Moyenne Impact : ★★★★☆ Élevé

Ce que Cloudflare offre gratuitement

  • CDN mondial : vos fichiers statiques servis depuis 330+ datacenters dans 120+ pays
  • SSL gratuit : HTTPS automatique
  • Protection DDoS : blocage des attaques basiques
  • Bot Fight Mode : détection et blocage des robots malveillants
  • Minification : compression HTML/CSS/JS automatique
  • Brotli : compression moderne activée par défaut

Configuration recommandée pour PrestaShop

Dans le dashboard Cloudflare :

  1. SSL/TLS → Mode : Full (strict)
  2. Speed → Optimization → Activer Auto Minify (HTML, CSS, JS)
  3. Speed → Optimization → Activer Brotli
  4. Caching → Configuration → Browser Cache TTL : 1 mois
  5. Security → Bots → Activer Bot Fight Mode

Bot Fight Mode : soulager votre serveur

Le Bot Fight Mode bloque automatiquement les robots malveillants (scrapers, spammeurs, scanners de vulnérabilités). Selon le Cloudflare Radar Year in Review 2025, les bots représentent ~53% des requêtes HTML :

  • ~44% de bots non-IA (scrapers, SEO, scanners...)
  • ~9% de bots IA (Googlebot 4.5%, GPTBot, Bingbot...)
  • ~47% seulement de trafic humain réel

Autrement dit, plus de la moitié des requêtes sur votre serveur peuvent venir de robots. Bloquer les bots malveillants libère des ressources pour vos vrais clients.

Gain potentiel : En activant Bot Fight Mode, vous pouvez réduire significativement la charge serveur. L'impact réel dépend de votre site — vérifiez vos stats dans Cloudflare → Security → Events pour mesurer la part de trafic bloqué.

Règles de pare-feu recommandées

Bot Fight Mode peut potentiellement bloquer certains services légitimes (API de paiement, flux Google...). Surveillez vos logs les premiers jours et créez des règles d'exception si nécessaire :

À surveiller : Vérifiez que vos callbacks de paiement et flux Google Merchant continuent de fonctionner après activation. Dans notre cas, aucun problème n'a été constaté, mais chaque configuration est différente.

1. Autoriser les callbacks de paiement

Dans Security → WAF → Custom Rules, créez une règle :

Nom : Autoriser API Paiement
Si : (http.request.uri.path contains "/module/") and (http.request.uri.path contains "paiement" or http.request.uri.path contains "payment" or http.request.uri.path contains "cmcic" or http.request.uri.path contains "paypal" or http.request.uri.path contains "stripe")
Action : Skip (All remaining custom rules, Rate limiting, Bot Fight Mode)

2. Autoriser Google Merchant Center

Pour que Google puisse accéder à vos flux produits :

Nom : Autoriser Google Merchant
Si : (cf.client.bot) and (http.request.uri.path contains "/flux" or http.request.uri.path contains "/feed" or http.request.uri.path contains "/export" or http.request.uri.path contains ".xml")
Action : Skip (Bot Fight Mode)

3. Autoriser les bots légitimes (SEO)

Nom : Autoriser bots SEO
Si : (cf.verified_bot_category in {"Search Engine Crawler" "Search Engine Optimization" "Feed Fetcher"})
Action : Allow

Vérifier que tout fonctionne

# Vérifier que Cloudflare est actif
curl -I https://votre-site.com/ | grep -i cf-ray

# Vérifier que Brotli est activé
curl -sI -H "Accept-Encoding: br" https://votre-site.com/ | grep -i content-encoding
# Doit afficher : content-encoding: br
🖱️ Vérifier sans ligne de commande :
  • analyse-seo.net — Vérifie les headers HTTP dont Cloudflare et compression
  • SSL Labs — Test complet de votre certificat SSL/TLS
  • Votre navigateur : F12 → Réseau → cliquez sur une requête → Headers pour voir les en-têtes

🚨 Checklist OBLIGATOIRE après tout changement cache/CDN/WAF

Après activation de LSCache, Cloudflare, ou modification de règles WAF, testez immédiatement :

  1. 1 achat complet (CB ou PayPal) → vérifiez que le paiement passe et la commande est créée
  2. 1 ajout panier + changement quantité → vérifiez que le panier se met à jour
  3. 1 connexion / création compte → vérifiez que le login fonctionne
  4. 1 flux Merchant Center / sitemap.xml → vérifiez l'accès (Google Search Console, Merchant Center)
  5. Logs crawl → vérifiez que Googlebot et bots légitimes ne sont pas bloqués (Security → Events)

⚠️ Si vous ne testez pas ça, vous pouvez perdre des ventes sans le voir.
Une règle WAF mal configurée = paiements bloqués silencieusement, panier vide sans explication, flux Google inaccessible.

→ Testez en navigation privée + mobile après chaque modification.

  • Cloudflare gratuit = CDN mondial + protection DDoS + compression Brotli
  • Configuration en 10 minutes, pas besoin de toucher au code
  • Attention : testez toujours un achat complet après activation

11. Résultats et maintenance

📗 Partie 1 — Optimisations serveur appliquées

  • Index MySQL : covering index créé sur les requêtes fréquentes
  • Tables nettoyées : ps_log, ps_pagenotfound
  • PrestaShop : templates en "jamais recompiler", CCC activé
  • OPcache : installé et configuré (256MB, 20000 fichiers)
  • Memcached : installé et configuré (512MB)
  • LiteSpeed + LSCache : cache serveur activé
  • Modules : audit et suppression des modules inutilisés
  • Cloudflare : CDN + Bot Fight Mode

📘 Partie 2 — Optimisations frontend appliquées

  • Images : conversion WebP + lazy loading activé
  • CSS/JS : CCC + minification + defer
  • Core Web Vitals : LCP, INP, CLS optimisés
  • Compression : Brotli activé via LiteSpeed/Cloudflare

Vérification post-optimisation

Après avoir appliqué toutes les optimisations, vérifiez ces métriques :

# OPcache actif
php -i | grep "opcache.enable"

# Memcached fonctionne
echo "stats" | nc localhost 11211 | grep "bytes"

# MySQL buffer pool hit ratio
mysql -e "SELECT
    ROUND((1 - (
        (SELECT VARIABLE_VALUE FROM performance_schema.global_status
         WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads') /
        (SELECT VARIABLE_VALUE FROM performance_schema.global_status
         WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests')
    )) * 100, 2) AS hit_ratio_percent;"

# TTFB page d'accueil (cache chaud)
curl -w "TTFB: %{time_starttransfer}s\n" -o /dev/null -s https://votre-site.com/
# Objectif : < 200ms

# TTFB page produit (cache contourné)
curl -w "TTFB: %{time_starttransfer}s\n" -o /dev/null -s "https://votre-site.com/un-produit?nocache=$(date +%s)"
# Objectif : < 500ms

# Vérifier LSCache
curl -sI https://votre-site.com/ | grep -i x-litespeed-cache
# Objectif : hit
🖱️ Vérifier sans ligne de commande :
  • analyse-seo.net — TTFB, headers LSCache, compression, Core Web Vitals en un clic
  • GTmetrix — Cascade de chargement détaillée + historique
  • phpMyAdmin — Exécutez les requêtes SQL dans l'onglet "SQL" de votre base
  • cPanel → Metrics → Visitors — Surveillez le trafic et les erreurs sans commandes

Métriques à surveiller

Métrique Objectif Comment vérifier
TTFB (cache HIT) < 100ms curl ou GTmetrix / analyse-seo.net
TTFB (cache MISS) < 500ms curl ?nocache ou WebPageTest
Buffer Pool Hit Ratio > 99% phpMyAdmin → SQL (section 2)
Slow queries Minimal phpMyAdmin ou cPanel → MySQL
Load average < nb CPU cPanel → Server Status
⚠️ Serveur récemment redémarré : Les métriques (Buffer Pool Hit Ratio notamment) peuvent être faussées juste après un redémarrage. Attendez plusieurs milliers de requêtes avant d'interpréter les ratios.
Résultat attendu : Avec ces optimisations, vous devriez constater une amélioration significative du temps de réponse et une meilleure stabilité sous charge. Le site sera plus réactif pour les visiteurs et les administrateurs.

Maintenance régulière

# Nettoyage mensuel des logs PrestaShop (le 1er à 3h)
0 3 1 * * mysql votre_base -e "DELETE FROM ps_log WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);"

# Nettoyage hebdomadaire des 404 (dimanche à 4h)
0 4 * * 0 mysql votre_base -e "TRUNCATE TABLE ps_pagenotfound;"

📋 Ordre recommandé pour optimiser votre PrestaShop

Suivez cet ordre pour un maximum d'efficacité avec un minimum de risques :

  1. Réglages PrestaShop (section 5) Impact : ★★★★☆
    Commencez par là : c'est gratuit, sans risque, et souvent le gain est immédiat. Accessible depuis le back-office.
  2. Cloudflare (section 10) Impact : ★★★★☆
    Gratuit, CDN mondial + Bot Fight Mode pour bloquer le trafic de bots malveillants. N'oubliez pas les règles pour vos API !
  3. LiteSpeed + LSCache (section 8) Impact : ★★★★★
    Si possible, passez sur un serveur LiteSpeed. Le cache intégré peut diviser les temps de chargement par 10 ou plus.
  4. OPcache (section 6) Impact : ★★★★★
    Si vous avez accès au serveur, installez OPcache immédiatement. C'est l'optimisation avec le meilleur rapport effort/résultat.
  5. Audit des modules (section 9) Impact : ★★★★☆
    Désinstallez les modules inutilisés. Les modules actifs consomment des ressources à chaque requête.
  6. Nettoyage des tables (section 4) Impact : ★★★☆☆
    Facile à faire et libère de l'espace. Faites une sauvegarde avant par précaution.
  7. Diagnostic + Audit MySQL (sections 1-2) Impact : ★★★★☆
    Si le site est encore lent après les étapes précédentes, lancez un audit pour identifier les vraies causes.
  8. Création d'index (section 3) Impact : ★★★★★
    À faire uniquement après l'audit, sur les requêtes identifiées comme problématiques.
  9. Memcached (section 7) Impact : ★★★★☆
    La cerise sur le gâteau. À installer une fois que tout le reste est optimisé.

📘 Puis, Partie 2 — Frontend

  1. Images WebP + lazy loading (section 12) Impact : ★★★★★
    Le plus gros gain frontend. WebP = ~25-34% plus léger que JPEG.
  2. Core Web Vitals (section 13) Impact : ★★★★☆
    Important pour l'expérience utilisateur et les signaux Google indirects.
  3. Score PageSpeed (section 14) Impact : ★★★☆☆
    Un score > 80 mobile suffit si le TTFB est < 200ms et l'UX fluide.

💡 Conseil : Faites une modification à la fois et mesurez l'impact avant de passer à la suivante.

  • Priorité absolue : OPcache + LSCache = 80% des gains
  • Ensuite : Index MySQL sur les requêtes lentes identifiées
  • Maintenance : Nettoyez les tables logs et surveillez vos modules
  • Objectif atteint ? TTFB < 200ms → passez à la partie 2

📘 Partie 2 — Optimisation PageSpeed

Maintenant que votre serveur répond en moins de 200ms, optimisons le rendu frontend.

12. Optimisation des images (WebP, AVIF, lazy loading)

En résumé : Les images représentent en moyenne ~50% du poids d'une page web. WebP offre une compression 25-34% supérieure à JPEG.
Complexité : ★★☆☆☆ Facile Impact : ★★★★★ Très élevé

Formats d'images : comparatif

Format Compression Transparence Support Usage
JPEG Bonne ❌ Non 100% Photos (fallback)
PNG Moyenne ✅ Oui 100% Logos uniquement
WebP Très bonne (-30%) ✅ Oui 97% ✅ À utiliser partout
AVIF Excellente (-50%) ✅ Oui 92% Si supporté

Activer WebP dans PrestaShop 8+

  1. Allez dans Paramètres de la boutique → Trafic & SEO → Images
  2. Activez "Générer des images au format WebP"
  3. Régénérez les miniatures : Paramètres avancés → Performances → Regénérer les miniatures
PrestaShop 1.6 / 1.7 : Utilisez un module comme "WebP Image Generator" ou "Image Optimizer Pro" depuis la marketplace Addons.

Lazy loading : charger les images à la demande

Le lazy loading retarde le chargement des images hors écran. Seules les images visibles sont chargées immédiatement.

<!-- Méthode native HTML (moderne) -->
<img src="produit.webp" alt="Produit" loading="lazy" />

<!-- PrestaShop 8+ : activé par défaut sur les listes produits -->
<!-- PrestaShop 1.7 : module requis ou modification thème -->

Outils de compression d'images

  • TinyPNG / TinyJPG — Compression en ligne gratuite (500 images/mois)
  • Squoosh.app — Outil Google, comparaison temps réel, gratuit
  • ImageOptim (Mac) / FileOptimizer (Windows) — Compression locale
  • Modules PrestaShop — "Kraken Image Optimizer", "reSmush.it"
Gain typique : Passer de JPEG à WebP (~25-34% plus léger) + lazy loading réduit significativement le temps de chargement, surtout sur mobile.

13. Optimisation CSS/JS et Core Web Vitals

En résumé : Les fichiers CSS et JavaScript peuvent bloquer l'affichage. Google mesure cela avec les Core Web Vitals.
Complexité : ★★★★☆ Avancée Impact : ★★★★☆ Élevé

Les 3 Core Web Vitals (2024+)

Métrique Mesure ✅ Bon ⚠️ À améliorer ❌ Mauvais
LCP
Largest Contentful Paint		 Temps d'affichage du plus grand élément visible ≤ 2.5s 2.5s - 4s > 4s
INP
Interaction to Next Paint		 Réactivité aux clics/taps ≤ 200ms 200ms - 500ms > 500ms
CLS
Cumulative Layout Shift		 Stabilité visuelle (éléments qui "sautent") ≤ 0.1 0.1 - 0.25 > 0.25

Optimisations CSS

1. Activer CCC dans PrestaShop

Déjà couvert en section 5 : combine et minifie les fichiers CSS/JS.

2. CSS Critique (Critical CSS)

Le CSS critique contient uniquement les styles nécessaires pour afficher le contenu visible sans scroll. Il est injecté directement dans le HTML.

<!-- Dans le <head>, AVANT les fichiers CSS externes -->
<style>
  /* CSS critique : header, menu, premier écran */
  .header { ... }
  .hero { ... }
</style>

<!-- CSS complet chargé en différé -->
<link rel="preload" href="theme.css" as="style" onload="this.rel='stylesheet'">
Modules PrestaShop : "Critical CSS Pro", "PageSpeed Optimizer" génèrent automatiquement le CSS critique.

Optimisations JavaScript

1. Defer et Async

<!-- Bloquant (mauvais) -->
<script src="script.js"></script>

<!-- Async : charge en parallèle, exécute dès que prêt (pour scripts indépendants) -->
<script src="analytics.js" async></script>

<!-- Defer : charge en parallèle, exécute après le HTML (recommandé) -->
<script src="theme.js" defer></script>

2. Supprimer le JavaScript inutilisé

  • Désinstallez les modules qui ajoutent du JS non utilisé (cf. section 9)
  • Évitez les sliders/carrousels lourds en JavaScript
  • Préférez les animations CSS aux animations JS

Éviter le CLS (décalages de mise en page)

  • Dimensions des images : toujours spécifier width et height
  • Espaces réservés : réserver l'espace pour les pubs, embeds
  • Polices web : utiliser font-display: swap
/* Éviter le flash de texte invisible (FOIT) */
@font-face {
  font-family: 'MaPolice';
  src: url('mapolice.woff2') format('woff2');
  font-display: swap; /* Affiche le texte immédiatement avec une police système */
}

14. Mesurer et améliorer son score PageSpeed

En résumé : PageSpeed Insights est l'outil officiel de Google pour mesurer les performances frontend. Un bon score améliore l'expérience utilisateur.
Complexité : ★★☆☆☆ Facile Impact : ★★★☆☆ Moyen

Outils de mesure

Interpréter son score PageSpeed

Score Interprétation Action
90-100 Excellent Maintenez ce niveau
50-89 Correct, améliorable Optimisez les points signalés
0-49 Problématique Priorité haute
Attention au piège : Ne cherchez pas le 100/100 à tout prix ! Un site peut avoir un score de 60 et être perçu comme rapide par les utilisateurs, tandis qu'un site à 95 peut sembler lent si le serveur rame. Concentrez-vous d'abord sur le ressenti utilisateur.

Checklist rapide PageSpeed

  • ✅ Images en WebP avec lazy loading
  • ✅ CCC activé dans PrestaShop (CSS/JS combinés et minifiés)
  • ✅ Dimensions des images spécifiées (évite le CLS)
  • ✅ Polices web avec font-display: swap
  • ✅ Scripts tiers en async/defer
  • ✅ Cache navigateur configuré (Cloudflare ou .htaccess)
  • ✅ Compression Brotli ou Gzip activée

Brotli : compression moderne

Brotli est un algorithme de compression développé par Google. Selon les benchmarks officiels, il offre une compression ~15-25% supérieure à Gzip pour les fichiers texte (HTML, CSS, JS). Il est activé par défaut sur LiteSpeed et Cloudflare.

# Vérifier si Brotli est actif
curl -I -H "Accept-Encoding: br" https://votre-site.com/ | grep -i content-encoding

# Résultat attendu :
content-encoding: br
Résumé Partie 2 : Si vous avez appliqué la Partie 1 (TTFB < 200ms) et la Partie 2 (images WebP, lazy loading, CCC), votre site devrait atteindre un score PageSpeed de 80+ sur mobile et 90+ sur desktop, avec une excellente expérience utilisateur.

❌ Optimisations inutiles ou surcotées

En résumé : Certaines "optimisations" populaires n'ont aucun impact réel, ou pire, font perdre du temps. Les identifier vous évitera de gaspiller des heures sur des micro-gains inexistants.

Ce qui NE sert à RIEN (ou presque)

❌ "Optimisation" Pourquoi c'est inutile ✅ Ce qu'il faut faire à la place
PHP 8.1 → 8.2/8.3 sans OPcache Gain mineur (~5-10%). Sans OPcache, PHP recompile tout à chaque requête. Installer OPcache d'abord
Activer Redis/Memcached sans audit SQL Vous cachez des requêtes lentes. Le problème reste. Audit MySQL + index, PUIS Memcached
Augmenter la RAM serveur sans index MySQL utilisera plus de RAM pour faire des full scan. Créer les index manquants d'abord
Micro-optimiser Smarty alors que MySQL rame Smarty = 20-100ms. MySQL sans index = 500-2000ms. Optimiser MySQL en priorité
CDN sans cache serveur Le CDN cache les assets statiques, pas le HTML. Si le serveur met 2s à répondre, le CDN ne change rien. LSCache d'abord, CDN ensuite
Compresser les images avec un TTFB de 3s L'utilisateur attend 3s AVANT de voir quoi que ce soit. TTFB < 500ms d'abord, images ensuite
Serveurs média PrestaShop Obsolète avec HTTP/2 (multiplexing). Laisser vide, utiliser un vrai CDN si besoin
Désactiver les modules au lieu de désinstaller Le code reste sur le serveur, les tables et crons peuvent subsister. Désinstaller complètement
Viser 100/100 PageSpeed Un score de 85 avec TTFB 50ms est mieux qu'un 100 avec TTFB 800ms. Prioriser le ressenti utilisateur réel
La règle d'or : Si vous n'avez pas MESURÉ le problème, n'optimisez pas au hasard. Utilisez le slow query log et curl pour identifier où part le temps AVANT d'agir.

🏁 Quand s'arrêter ? Les seuils de "suffisamment rapide"

En résumé : L'optimisation a des rendements décroissants. Passer de 3s à 500ms change tout. Passer de 100ms à 50ms ne change rien pour l'utilisateur.

Seuils cibles : quand c'est "assez bien"

Métrique 🎯 Objectif "suffisant" Au-delà = rendements décroissants
TTFB < 200ms En dessous, les gains deviennent marginaux pour l'expérience perçue
Temps total (HTML) < 500ms Suffisant pour une excellente expérience utilisateur
Load average < nb CPU Si stable à 0.5 avec 2 CPU, inutile d'optimiser plus
Buffer pool hit ratio > 99% À 99.5%, pas besoin de viser 99.9%
Score PageSpeed mobile > 80 La différence 80 vs 95 n'impacte pas significativement l'UX ni les signaux Google
LCP < 2.5s C'est le seuil Google "Good". En dessous, c'est du bonus.

Signaux qu'il est temps d'arrêter

  • ✅ TTFB < 150ms de façon stable → Mission accomplie côté serveur
  • ✅ Load average < 1 même en pic de trafic → Le serveur n'est pas le goulot
  • ✅ Slow query log vide pendant un test de charge → MySQL est optimisé
  • ✅ PageSpeed > 80 mobile → Bon pour l'UX et les signaux Google indirects
  • ✅ Les utilisateurs ne se plaignent plus → C'est ça le vrai KPI
Le vrai objectif : Que vos visiteurs perçoivent le site comme "rapide". Pas d'avoir des métriques parfaites. Un site à 200ms de TTFB avec un bon design sera perçu plus rapide qu'un site à 80ms avec un loader qui bloque l'écran 2 secondes.

Après l'optimisation : maintenance

Une fois les seuils atteints, passez en mode maintenance :

  • 📅 Mensuel : Nettoyage ps_log, ps_pagenotfound
  • 📅 À chaque nouveau module : Tester l'impact sur le TTFB
  • 📅 Trimestriel : Vérifier le slow query log
  • 📅 Annuel : Revoir la stack (versions PHP, PrestaShop)

Cas pratique : Traquer un problème de performance avec des logs

Parfois, les outils classiques (slow query log, profilers) ne suffisent pas à identifier un goulot d'étranglement. La solution : instrumenter le code avec des logs de timing précis. Voici un cas réel où l'ajout au panier prenait 2 secondes.

Le symptôme

L'ajout au panier via POST /panier prenait systématiquement 2.1 secondes. Aucune requête SQL lente visible, le serveur n'était pas surchargé. Le problème était invisible.

Étape 1 : Créer une classe de logging légère

On crée un utilitaire minimaliste qui mesure le temps entre deux points :

// modules/cartperflog.php
class CartPerfLog
{
    private static $startTimes = [];
    private static $logs = [];
    private static $globalStart = null;
    private static $logFile = '/tmp/cart_perf.log';

    public static function start($name)
    {
        if (self::$globalStart === null) {
            self::$globalStart = microtime(true);
        }
        self::$startTimes[$name] = microtime(true);
        $elapsed = round((microtime(true) - self::$globalStart) * 1000, 2);
        file_put_contents(self::$logFile, "[+{$elapsed}ms] START: {$name}\n", FILE_APPEND);
    }

    public static function end($name)
    {
        if (!isset(self::$startTimes[$name])) return;
        $duration = round((microtime(true) - self::$startTimes[$name]) * 1000, 2);
        $elapsed = round((microtime(true) - self::$globalStart) * 1000, 2);
        file_put_contents(self::$logFile, "[+{$elapsed}ms] END: {$name} ({$duration}ms)\n", FILE_APPEND);
        self::$logs[$name] = $duration;
    }

    public static function summary()
    {
        $total = round((microtime(true) - self::$globalStart) * 1000, 2);
        arsort(self::$logs);
        file_put_contents(self::$logFile, "\nTOP 10 plus lents:\n", FILE_APPEND);
        $i = 0;
        foreach (self::$logs as $name => $duration) {
            if ($i++ >= 10) break;
            $pct = round(($duration / $total) * 100, 1);
            file_put_contents(self::$logFile, "  {$duration}ms ({$pct}%) - {$name}\n", FILE_APPEND);
        }
    }
}

Étape 2 : Instrumenter le code suspect

On ajoute des logs à chaque étape potentiellement lente. Pour le panier, on crée un override de CartController :

// override/controllers/front/CartController.php
require_once _PS_MODULE_DIR_ . 'cartperflog.php';

class CartController extends CartControllerCore
{
    protected function processChangeProductInCart()
    {
        CartPerfLog::start('processChangeProductInCart()');

        CartPerfLog::start('validation');
        // ... code de validation ...
        CartPerfLog::end('validation');

        CartPerfLog::start('updateQty [CRITICAL]');
        $this->context->cart->updateQty(...);
        CartPerfLog::end('updateQty [CRITICAL]');

        CartPerfLog::end('processChangeProductInCart()');
        CartPerfLog::summary();
    }
}

Étape 3 : Affiner par itérations

Le premier run montre que updateQty() prend 741ms. On instrumente alors Cart::updateQty() :

// Résultat après instrumentation de updateQty() :
[+85ms]  START: this->update() [SAVE]
[+718ms] END: this->update() [SAVE] (633ms)  ← 633ms !

Le problème est dans $this->update(). On continue à creuser :

// On découvre que ObjectModel::update() déclenche des hooks.
// Modules enregistrés sur actionObjectCartUpdateAfter :
// - ps_eventbus
// - nxtalwishlist
// - alma

Étape 4 : Le coupable identifié

En désactivant ps_eventbus temporairement :

Métrique Avant Après Gain
update() [SAVE] 633ms 4.65ms -628ms
TOTAL /panier 2177ms 374ms -1800ms
Le coupable : ps_eventbus
Ce module de PrestaShop fait des appels HTTP synchrones vers les serveurs PrestaShop Marketplace à chaque modification du panier. Si vous n'utilisez pas PrestaShop Metrics/Marketplace, désactivez-le.

Méthodologie résumée

  1. Créer un logger léger - avec start/end et timestamps
  2. Instrumenter large - d'abord les grandes sections (controller, hooks)
  3. Affiner progressivement - zoom sur la section lente, ajouter plus de logs
  4. Identifier les hooks - vérifier quels modules sont enregistrés : SELECT h.name, m.name FROM ps_hook h JOIN ps_hook_module hm... WHERE h.name LIKE '%Cart%'
  5. Tester par élimination - désactiver temporairement les suspects
  6. Nettoyer - retirer les logs de debug une fois le problème résolu
Cette technique fonctionne pour tout : hooks lents, modules problématiques, requêtes cachées, appels API synchrones. L'investissement de 30 minutes pour instrumenter le code peut révéler des problèmes invisibles autrement.

Conclusion

L'optimisation de PrestaShop n'est pas une science exacte. La clé est de mesurer avant d'optimiser. L'audit MySQL en temps réel permet d'identifier les vrais problèmes plutôt que d'appliquer des optimisations génériques qui n'auront peut-être aucun impact sur votre configuration spécifique.

📗 Partie 1 — Serveur (faire EN PREMIER) :

  1. Configurez PrestaShop - "Jamais recompiler", CCC activé, mode debug désactivé
  2. Activez Cloudflare - CDN gratuit + Bot Fight Mode (bloque les bots malveillants)
  3. Passez à LiteSpeed + LSCache - Le plus gros gain potentiel (×20 à ×40 plus rapide)
  4. Installez OPcache - Gain immédiat sur l'exécution PHP
  5. Désinstallez les modules inutilisés - Les modules actifs consomment des ressources
  6. Utilisez le slow query log - Pour identifier les vraies requêtes problématiques
  7. Créez des covering index - Pour les requêtes identifiées comme fréquentes
  8. Configurez Memcached - Pour réduire la charge MySQL
  9. Nettoyez régulièrement - PrestaShop accumule beaucoup de données inutiles

📘 Partie 2 — Frontend (faire ENSUITE) :

  1. Convertissez en WebP - ~25-34% plus léger que JPEG
  2. Activez le lazy loading - Ne charge que les images visibles
  3. Optimisez les Core Web Vitals - LCP < 2.5s, INP < 200ms, CLS < 0.1
  4. Vérifiez avec PageSpeed - Score > 80 mobile suffit si TTFB < 200ms

Testez toujours les modifications sur un environnement de staging avant de les appliquer en production.

  • Commencez par mesurer avant d'optimiser (TTFB, slow queries)
  • Concentrez-vous sur 3 leviers : OPcache, LSCache, index MySQL
  • Objectif : TTFB < 200ms, PageSpeed > 80
  • Arrêtez-vous quand vos visiteurs perçoivent le site comme rapide

Cet article reflète notre manière de travailler chez Energiedin : partir du serveur, comprendre les contraintes techniques réelles, et ne pas confondre indicateurs marketing et performance vécue.

La vitesse PrestaShop ne se corrige pas avec un plugin, mais avec une compréhension complète de la stack.

Questions fréquentes

Pourquoi optimiser la vitesse de votre site PrestaShop ?
Parce que la vitesse a un impact direct sur le chiffre d'affaires, le SEO et l'expérience utilisateur. Un site rapide convertit mieux, réduit le taux de rebond et est favorisé par Google dans les résultats de recherche.
Un bon score PageSpeed garantit-il un site rapide ?
Non. PageSpeed mesure surtout l'optimisation frontend (images, CSS, JavaScript), mais ne reflète pas toujours la vitesse réelle du serveur. Sur PrestaShop, un site peut avoir un bon score PageSpeed tout en restant lent si le serveur ou la base de données sont mal optimisés.
Qu'est-ce que le TTFB et pourquoi est-il crucial sur PrestaShop ?
Le TTFB (Time To First Byte) correspond au temps que met le serveur à générer la page HTML. Sur PrestaShop, un TTFB élevé indique souvent un problème d'hébergement, de base de données, de modules ou de cache serveur.
Faut-il optimiser le serveur ou PageSpeed en premier ?
Il faut toujours optimiser le serveur en premier. Si le serveur met plusieurs secondes à répondre, les optimisations PageSpeed (images, CSS, JS) auront peu d'impact. Le backend est la fondation de la performance.
Quelles sont les principales causes de lenteur sur PrestaShop ?
Les causes les plus fréquentes sont : un hébergement sous-dimensionné ou mal configuré, trop de modules actifs, des requêtes MySQL non optimisées, l'absence de cache serveur, et des hooks exécutés inutilement sur toutes les pages.
Redis ou Memcached sont-ils vraiment utiles sur PrestaShop ?
Oui, lorsqu'ils sont bien configurés. Redis ou Memcached permettent de réduire la charge MySQL et d'accélérer les pages dynamiques. Mal configurés, ils peuvent toutefois dégrader les performances.
Un CDN est-il indispensable pour un site PrestaShop ?
Non. Un CDN est utile dans certains cas (trafic international, serveur éloigné, beaucoup de ressources statiques), mais un serveur bien optimisé apporte souvent plus de gains qu'un CDN mal configuré.
Combien de modules peut supporter un site PrestaShop performant ?
Il n'existe pas de nombre fixe. Ce n'est pas la quantité mais l'impact des modules qui compte. Certains modules ralentissent fortement PrestaShop en ajoutant des requêtes ou des traitements inutiles.
Optimiser la vitesse améliore-t-il réellement le SEO ?
Oui. Google prend en compte la vitesse, les Core Web Vitals et l'expérience utilisateur. Un site plus rapide est mieux crawlable, mieux classé et offre de meilleures performances SEO globales.
À quelle fréquence faut-il auditer la vitesse d'un site PrestaShop ?
Idéalement après chaque mise à jour majeure, ajout de module ou changement d'hébergement, et au minimum une fois par an pour anticiper les ralentissements.

Découvrez nos créations

Fruits de collaborations authentiques !

105 réalisations

SOUDURE.PROSite E-commerce / SEO / Google ADSDéveloppement et SEO de la multinationale allemande au Maroc. 2Site vitrine AdidasSEO DecathlonMotion Video PGESite vitrine MA doucheSite E-commerce Fleur MarocSite vitrine ed realisations logo 35 newSEO ed realisations logo 07 newSEO YVEs RocherMotion Video ed realisations logo ResineAnimauxSEO Mister PrépaMotion Video Auto PlugSite vitrine ceosmagBlog EnergieDin SEOMotion Video Les verrieres de parisSite vitrine OnglerieMotion Video Groupe LGESite vitrine Objectif ASTBlog AmouddouSite vitrine Verriere FRANCESite vitrine ed realisations logo DecoMundoSEO AREX transportsSite vitrine Cabinet ouladSite vitrine Le ComptoirSite E-commerce Eco LogementSite vitrine Access ModaSite E-commerce Le Grand EcoloSite vitrine Brico DiscountSite E-commerce Top EnergieSite vitrine AFRISite vitrine SelmayaSite vitrine Antheor ParisSite vitrine lenidMise en relation LeimanSite E-commerce Automatic IDSite vitrine SOUDURE.PROSite E-commerce / SEO / Google ADSDéveloppement et SEO de la multinationale allemande au Maroc. Fleurs Maroc VideoMotion Video Grossiste OrientSite E-commerce ProdmerSite vitrine Best DemenageurSite vitrine conf mustMise en relation UberdemMotion Video COSSASite vitrine cherche un profMise en relation Bam And WowMotion Video DocPCSite vitrine EnergieDin Amp ClassiqueMotion Video Dom AudioSite vitrine leader formationMise en relation EnergieDin FleursMaroc 8MarsMotion Video HajjencySite vitrine Muslim HolidaysMotion Video EnergieDin FleursMaroc Saint ValentinMotion Video Tanger PrestigeSite vitrine Hyatt PlaceSEO OmanMotion Video PFM elfirdousSite vitrine SANI franceSite vitrine Anmoggar N Jazz Promo VideoMotion Video AntalyaMotion Video YLA StudioSite vitrine JP outilageSite vitrine DedizBlog ElectroplanetSEO MB l'agenceSite vitrine LesVerrièreDeParisMotion Video start in block chaineSite vitrine JELOUTOUSite vitrine NewGen PartnersSite vitrine ClimabelSite vitrine SynthechimSite vitrine FemodestSite vitrine Fréquence auditionSite vitrine Top CollecteSite vitrine Clickngo AgadirSite vitrine SygecomSite E-commerce REDSite vitrine CasanurseSite vitrine AccessModaSEO Antheor ParisSEO Atelier AfdalSEO Best déménageurSEO climabel seoSEO conjonctoure seoSEO debouchage seoSEO demenager seoSEO E3 cortex seoSEO free surf seoSEO ed realisations logo 26SEO frigotec seoSEO ed realisations logo 27SEO khaleej seoSEO LG seoSEO ed realisations logo 34SEO ed realisations logo 32SEO ed realisations logo 30SEO ed realisations logo 33SEO planete seoSEO prepa seoSEO serrurier seoSEO speak seoSEO tizuzaf seoSEO top energie seoSEO ubdem seoSEO

Nos réalisations

Aucune réalisation ne correspond à cette catégorie.