Site PrestaShop lent : diagnostic complet et optimisations serveur

Pourquoi votre PrestaShop est lent malgré un hébergement performant

Vous avez investi dans un hébergement que vous estimez correct, et pourtant votre boutique PrestaShop met plusieurs secondes à charger chaque page. C'est un scénario frustrant mais extrêmement courant. La puissance brute du serveur ne fait pas tout : une requête SQL mal construite par un module tiers peut annihiler les performances d'un serveur haut de gamme.

Avant de migrer vers un hébergement plus cher, il faut poser un diagnostic méthodique. Dans cet article, je détaille les causes réelles de lenteur et les optimisations concrètes qui transforment un PrestaShop poussif en boutique réactive.

Étape 1 : mesurer avant d'agir

La première erreur est de deviner la cause. Utilisez systématiquement des outils de mesure pour objectiver le problème :

• **Google PageSpeed Insights** : score mobile et desktop, avec les métriques Core Web Vitals (LCP, FID, CLS)
• **GTmetrix** : waterfall détaillé qui montre exactement quelles ressources bloquent le rendu
• **WebPageTest** : test depuis différentes localisations géographiques, avec filmstrip visuel
• **KeyCDN Performance Test** : temps de réponse serveur (TTFB) depuis plusieurs points de présence

Point critique : ne testez pas uniquement la page d'accueil. Les pages catégorie et produit sont souvent les plus lentes car elles exécutent davantage de requêtes SQL (filtres, déclinaisons, modules de cross-selling). Testez aussi les pages CMS si vous en avez beaucoup.

Interpréter le TTFB

Le Time To First Byte (TTFB) est votre premier indicateur. Il mesure le temps entre la requête du navigateur et le premier octet de la réponse serveur :

• **< 200 ms** : excellent
• **200-500 ms** : acceptable
• **> 500 ms** : problème côté serveur (PHP, SQL ou configuration)
• **> 1 s** : problème critique, probablement une requête SQL bloquante

Si votre TTFB est élevé, le problème est côté serveur (pas côté front-end). Inutile d'optimiser les images ou le CSS tant que le serveur met une seconde à répondre.

Étape 2 : identifier les requêtes SQL problématiques avec le debug profiling

La cause numéro un de lenteur sur PrestaShop est une requête SQL mal optimisée, généralement introduite par un module tiers. Le mode debug profiling intégré à PrestaShop permet de traquer ces requêtes.

Activer le profiling sur PrestaShop 1.6 / 1.7

Éditez le fichier config/defines.inc.php :

/* Debug only */
define('_PS_MODE_DEV_', true);
define('_PS_DEBUG_PROFILING_', true);

Sur PrestaShop 8.x

Le profiling passe désormais par le Symfony Profiler intégré. Activez le mode debug dans .env :

APP_DEBUG=1
APP_ENV=dev

Puis accédez à la barre de debug Symfony en bas de page. L'onglet Doctrine affiche toutes les requêtes SQL avec leur temps d'exécution.

Que chercher dans le profiling

Une fois le profiling activé, rechargez la page lente et examinez :

1. **Les requêtes > 100 ms** : ce sont vos goulots d'étranglement
2. **Les requêtes dupliquées** : un module qui exécute la même requête en boucle
3. **Le nombre total de requêtes** : au-delà de 200 requêtes par page, il y a un problème
4. **Les requêtes sans index** : repérables par un `EXPLAIN` montrant un `type: ALL` (full table scan)

-- Identifier les requêtes lentes dans le slow query log MySQL/MariaDB
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow-queries.log';

Astuce : désactivez les modules un par un et mesurez l'impact sur le TTFB. C'est la méthode la plus fiable pour isoler un module problématique.

Étape 3 : choisir le bon type d'hébergement

Un hébergement mutualisé impose des limites strictes sur la configuration PHP, et c'est souvent là que le bât blesse.

Pourquoi le mutualisé bride PrestaShop

Sur un hébergement mutualisé classique (type 1&1/IONOS, OVH Perso), vous subissez :

• **`max_execution_time`** bridé à 30 secondes (parfois moins)
• **`memory_limit`** plafonné à 128 Mo (PrestaShop en a besoin de 256 Mo minimum)
• **Pas d'accès à la configuration OPcache**
• **Pas de choix de version PHP** ou version imposée
• **Ressources CPU partagées** avec des centaines d'autres sites

La configuration VPS recommandée

Le minimum viable pour un PrestaShop performant est un VPS SSD. Voici la stack que je recommande en 2024-2026 :

ComposantRecommandationPourquoi OSUbuntu 22.04 LTS / Debian 12Stabilité, support long terme Serveur HTTPNginx (ou Apache + mod_pagespeed)Nginx consomme moins de RAM PHP8.1 ou 8.2 (avec OPcache + APCu)Requis pour PrestaShop 8.x Base de donnéesMariaDB 10.11 ou Percona ServerPercona offre de meilleures performances sur les jointures complexes RAM4 Go minimum2 Go pour PHP-FPM, 1 Go pour MariaDB, 1 Go pour l'OS StockageSSD NVMeLes I/O disque sont critiques pour les requêtes SQL

Configuration PHP optimale

Créez ou éditez votre fichier de configuration PHP-FPM :

; /etc/php/8.2/fpm/conf.d/99-prestashop.ini

max_execution_time = 300
memory_limit = 512M
upload_max_filesize = 20M
post_max_size = 20M

; OPcache — indispensable
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.revalidate_freq = 60
opcache.validate_timestamps = 0  ; mettre à 1 en dev

; Realpath cache
realpath_cache_size = 4096K
realpath_cache_ttl = 600

Point important : sur PrestaShop 8.x, la version PHP minimale est 7.2.5 mais PHP 8.1+ est vivement recommandé pour bénéficier des gains de performance natifs du moteur (JIT, optimisations internes).

Étape 4 : paralléliser le chargement des assets avec les media servers

PrestaShop intègre nativement une fonctionnalité méconnue mais puissante : les media servers. Le principe est simple mais l'impact est significatif.

Comment ça fonctionne

Les navigateurs limitent le nombre de connexions simultanées par domaine (typiquement 6 par domaine en HTTP/1.1). En répartissant vos fichiers statiques (images, CSS, JS) sur plusieurs sous-domaines, vous contournez cette limite.

Configuration dans PrestaShop

Rendez-vous dans Paramètres avancés > Performances > Serveurs de média :

Serveur de média 1 : media1.votredomaine.com
Serveur de média 2 : media2.votredomaine.com
Serveur de média 3 : media3.votredomaine.com

Configuration DNS et serveur

Créez des enregistrements CNAME pointant vers votre domaine principal :

media1.votredomaine.com  CNAME  votredomaine.com
media2.votredomaine.com  CNAME  votredomaine.com
media3.votredomaine.com  CNAME  votredomaine.com

Puis configurez votre serveur web pour répondre sur ces sous-domaines.

Les deux avantages concrets

1. **Parallélisation des requêtes** : le navigateur peut télécharger 18 fichiers simultanément (6 × 3 domaines) au lieu de 6
2. **Domaines sans cookie** : les sous-domaines de média ne transmettent pas les cookies de session, ce qui réduit la taille de chaque requête HTTP

Note pour PrestaShop 8.x et HTTP/2 : avec HTTP/2, le multiplexage rend les media servers moins nécessaires pour la parallélisation. Cependant, l'avantage "sans cookie" reste pertinent. Si votre serveur est en HTTP/2, un seul sous-domaine média suffit.

Étape 5 : aller plus loin avec Nginx pour les assets statiques

Pour les boutiques à fort trafic, une architecture avancée consiste à séparer le contenu statique du contenu dynamique :

• **Serveur principal (Apache ou PHP-FPM)** : traite les pages dynamiques
• **Serveur secondaire (Nginx pur)** : sert les images, CSS, JS et fonts

Nginx excelle dans la distribution de fichiers statiques grâce à son architecture événementielle. Un simple VPS Nginx peut servir des milliers de fichiers statiques par seconde avec une empreinte mémoire minimale.

# Configuration Nginx pour servir les assets statiques
server {
    listen 80;
    server_name media1.votredomaine.com;
    root /var/www/prestashop;

    # Cache navigateur agressif pour les assets
    location ~* \.(jpg|jpeg|png|webp|gif|ico|css|js|woff2|woff|ttf|svg)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
        add_header X-Content-Type-Options nosniff;
        access_log off;
    }

    # Compression Gzip
    gzip on;
    gzip_types text/css application/javascript image/svg+xml;
    gzip_min_length 1000;
}

Étape 6 : optimisations PrestaShop côté back-office

Dans Paramètres avancés > Performances, activez :

• **Cache Smarty** : "Oui" avec compilation en cas de modification
• **Concaténation CCC** : regrouper les fichiers CSS et JS
• **Cache de l'application** : activé (système de fichiers ou Redis si disponible)
• **Désactiver les modules non utilisés** : chaque module actif ajoute des hooks et potentiellement des requêtes SQL

Configuration du cache avec Redis (PrestaShop 8.x)

Sur PrestaShop 8.x, vous pouvez utiliser Redis comme backend de cache Symfony :

# app/config/parameters.php ou .env
REDIS_URL=redis://localhost:6379

Checklist de performance PrestaShop

Récapitulatif des actions à mener, par ordre de priorité :

1. ✅ Activer le profiling et identifier les requêtes SQL lentes
2. ✅ Migrer sur un VPS SSD si vous êtes en mutualisé
3. ✅ Configurer PHP correctement (OPcache, memory_limit, max_execution_time)
4. ✅ Activer la concaténation CSS/JS dans le back-office
5. ✅ Configurer les media servers (au moins un sous-domaine)
6. ✅ Optimiser les images (format WebP, compression)
7. ✅ Mettre en place un cache applicatif (Redis ou Memcached)
8. ✅ Désactiver les modules inutiles
9. ✅ Passer en HTTP/2 avec un certificat SSL
10. ✅ Surveiller régulièrement avec GTmetrix ou PageSpeed Insights