Optimiser la vitesse de PrestaShop : diagnostic complet et solutions

Introduction

Un site PrestaShop lent, c'est des clients qui partent, un taux de conversion qui s'effondre et un référencement qui plonge. Après plus de 10 ans d'interventions sur des boutiques PrestaShop de toutes tailles, je peux affirmer que les problèmes de performance ont presque toujours les mêmes origines : modules mal optimisés, requêtes SQL excessives, mauvaise configuration serveur ou assets front-end mal gérés.

Ce guide vous propose une méthodologie complète de diagnostic et de résolution, applicable de PrestaShop 1.7 à 8.x.

Étape 1 : Activer le mode Debug Profiling

Avant toute optimisation, il faut mesurer. PrestaShop intègre un outil de profiling natif qui affiche en bas de chaque page le détail de toutes les requêtes SQL, le temps d'exécution de chaque hook et la consommation mémoire.

Attention : Le mode Debug Profiling n'est pas le mode Debug classique. Le mode Debug affiche les erreurs PHP, tandis que le Profiling analyse les performances. Ce sont deux fonctionnalités distinctes.

Activation sécurisée (par IP)

Ne jamais activer le profiling pour tous les visiteurs en production. Modifiez le fichier config/defines.inc.php :

/* Debug profiling — restreint à votre IP */
if (!defined('_PS_DEBUG_PROFILING_')) {
    if ($_SERVER['REMOTE_ADDR'] === 'VOTRE_IP_PUBLIQUE') {
        define('_PS_DEBUG_PROFILING_', true);
    } else {
        define('_PS_DEBUG_PROFILING_', false);
    }
}

Récupérez votre IP publique via un service comme https://mon-ip.io/ et remplacez VOTRE_IP_PUBLIQUE.

Sur PrestaShop 8.x

La constante _PS_DEBUG_PROFILING_ fonctionne toujours de la même manière. Vous pouvez également utiliser la Symfony Debug Toolbar en activant le mode dev via le fichier .env :

APP_ENV=dev
APP_DEBUG=1

Mais pour l'analyse des requêtes SQL et des hooks, le profiling natif reste l'outil le plus adapté.

Lire les résultats

Une fois activé, scrollez tout en bas de la page. Vous verrez :

• **Le temps total** de génération de la page
• **Le nombre de requêtes SQL** et leur temps cumulé
• **Le détail de chaque requête** avec le temps d'exécution individuel
• **Les hooks** et le temps passé dans chaque module

Concentrez-vous sur la section initContent : c'est là que PrestaShop charge les données des modules et du thème. Si cette section est anormalement longue, le problème vient d'un module ou d'une requête mal optimisée.

Étape 2 : Identifier les modules problématiques

Les modules sont la première cause de lenteur sur PrestaShop. Voici la méthode systématique pour identifier les coupables.

La méthode d'isolation

1. **Désactivez tous les modules non essentiels** depuis le back-office
2. **Réactivez-les un par un**, en mesurant le temps de chargement à chaque réactivation
3. Quand le temps explose, vous avez trouvé le coupable

Les modules fréquemment en cause

• **Modules de panier abandonné** : ils créent souvent des tâches cron lourdes qui s'exécutent en arrière-plan et saturent la base de données
• **Modules de menu et de catégories** : si vous avez des centaines de catégories, un module qui les charge toutes à chaque page view génère des requêtes massives
• **Modules de carte Google Maps** : les appels API externes bloquent le rendu
• **La connexion à PrestaShop Addons** : l'API du marketplace peut être lente ou instable, ralentissant votre back-office

Désactiver la connexion PrestaShop Addons

Si votre back-office est lent, la connexion au marketplace Addons peut en être la cause. Pour la désactiver proprement, créez un override de la classe Tools :

// override/classes/Tools.php
class Tools extends ToolsCore
{
    public static function addonsRequest($request, $params = [])
    {
        // Désactive tous les appels API vers PrestaShop Addons
        return false;
    }
}

Sur PrestaShop 8.x, les overrides sont toujours supportés mais Symfony encourage l'utilisation de services. Pour cette modification spécifique, l'override reste la méthode la plus simple.

Après avoir placé le fichier, videz le cache PrestaShop depuis Paramètres avancés > Performances ou supprimez le contenu de var/cache/ (PS 8.x) ou cache/ (PS 1.7).

Désinstaller vs Désactiver

Un module simplement désactivé reste sur votre serveur. Son code est toujours accessible et peut représenter une faille de sécurité : un attaquant connaissant le nom du répertoire peut exploiter une vulnérabilité même si le module est désactivé.

Bonne pratique : Désinstallez les modules inutilisés ET supprimez leur répertoire dans /modules/. Vous pourrez toujours les retélécharger depuis votre compte PrestaShop Addons si nécessaire.

Étape 3 : Analyser les requêtes SQL

Le profiling vous montre chaque requête SQL. Voici les signaux d'alerte :

• **Plus de 200 requêtes** par page : c'est trop, un site bien optimisé tourne entre 50 et 150
• **Une requête qui retourne des milliers de lignes** : par exemple, une requête sur la table des catégories qui remonte 3 000+ résultats alors que vous n'en affichez que 10
• **Des requêtes dupliquées** : le même SELECT exécuté plusieurs fois par des modules différents

Requêtes sur les catégories

Un cas classique : un module de menu ou de filtre qui charge toutes les catégories à chaque page. Si votre boutique a des centaines de catégories, cette seule requête peut prendre plusieurs secondes.

Solution : désactivez le module en cause et remplacez-le par une alternative qui utilise le cache ou qui limite la profondeur de l'arbre catégoriel.

Tâches cron parasites

Certains modules créent des tâches cron qui s'exécutent trop fréquemment et surchargent la base de données. Vérifiez vos tâches cron :

crontab -e

Supprimez toute tâche cron associée à un module que vous avez désinstallé, puis redémarrez le service :

sudo service cron restart

Vérifiez également le module Cron tasks manager de PrestaShop dans le back-office et supprimez les tâches orphelines.

Étape 4 : Problèmes serveur et sécurité

Hébergement mutualisé vs dédié

Un hébergement mutualisé partage les ressources CPU, RAM et I/O avec d'autres sites. Si votre voisin subit un pic de trafic, votre boutique ralentit.

Recommandation : Pour une boutique PrestaShop en production, un VPS est le minimum. Un serveur dédié ou un VPS avec au moins 4 Go de RAM, un SSD NVMe et PHP 8.1+ avec OPcache activé fera une différence considérable.

Lenteurs aléatoires : penser aux attaques DDoS

Si les ralentissements sont aléatoires et imprévisibles, le problème n'est probablement pas lié aux requêtes SQL. Vérifiez les logs d'accès du serveur :

# Analyser les connexions par IP sur les dernières heures
awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -20

Si une IP concentre un nombre anormal de requêtes, vous subissez probablement une attaque par déni de service.

Solutions :

• Installez **fail2ban** pour bannir automatiquement les IP suspectes
• Utilisez **Cloudflare** comme proxy inverse (gratuit) pour filtrer le trafic malveillant
• Contactez votre hébergeur pour qu'il mette en place des règles de rate limiting

Étape 5 : Optimisation front-end

Gestion du JavaScript et jQuery

PrestaShop charge jQuery dans le footer par défaut (depuis la 1.7). Si un module ou le thème appelle du JavaScript jQuery dans le header, celui-ci s'exécute avant que jQuery soit disponible, générant des erreurs en console.

Dans Paramètres avancés > Performances > CCC :

• Décochez **"Déplacer le JavaScript à la fin"** si vous avez des erreurs jQuery
• Sur PrestaShop 1.7, désactivez la CCC (Concaténation, Compression et mise en Cache) si elle cause des conflits — elle est souvent plus nuisible qu'utile

Sur PrestaShop 8.x, la gestion des assets a été améliorée, mais le problème peut persister avec des modules tiers mal développés. Vérifiez toujours la console du navigateur (F12) pour détecter les erreurs JavaScript.

Optimisation des images

Les images sont souvent le premier facteur de poids d'une page e-commerce.

1. **Compressez vos images** avant l'upload avec un outil comme TinyPNG
2. **Utilisez le format WebP** au lieu du JPEG/PNG — gain de 25 à 35% en taille. Sur PrestaShop, un override d'`ImageManager` permet d'utiliser la bibliothèque GD en compression WebP
3. **Implémentez le lazy loading** : les images sous la ligne de flottaison ne se chargent que quand l'utilisateur scrolle

Fonts et icônes

• **Hébergez vos polices localement** au lieu d'appeler Google Fonts — vous éliminez un aller-retour réseau et vous gagnez en conformité RGPD
• **Remplacez les bibliothèques d'icônes** (Font Awesome, Material Icons) par des **SVG individuels**. Charger une police de 200 icônes quand vous n'en utilisez que 5, c'est du gaspillage pur

Core Web Vitals

Google mesure trois métriques essentielles :

MétriqueSignificationObjectif **FCP** (First Contentful Paint)Premier affichage de contenu< 1,8 s **LCP** (Largest Contentful Paint)Affichage du plus gros élément< 2,5 s **CLS** (Cumulative Layout Shift)Stabilité visuelle< 0,1

Utilisez Google PageSpeed Insights pour mesurer ces métriques. Un score mobile supérieur à 70 est un bon objectif pour une boutique PrestaShop.

Critical CSS

Pour améliorer le FCP, implémentez le Critical CSS : extrayez le CSS nécessaire au rendu au-dessus de la ligne de flottaison et injectez-le en inline dans le . Le reste du CSS se charge en asynchrone.

C'est un travail avancé qui donne les meilleurs résultats sur un thème développé from scratch. Sur un thème acheté, les gains sont plus limités car la structure CSS n'est pas conçue pour cette optimisation.

Étape 6 : Ne jamais modifier le cœur de PrestaShop

Règle fondamentale : on ne touche jamais aux fichiers du cœur de PrestaShop. Toute modification directe sera écrasée à la prochaine mise à jour.

Les deux mécanismes officiels :

1. **Les overrides** : placez vos fichiers dans le répertoire `/override/` en respectant l'arborescence. PrestaShop utilisera votre version à la place de l'originale
2. **Les modules** : pour toute fonctionnalité métier, développez un module qui s'accroche aux hooks de PrestaShop

Sur PrestaShop 8.x, les overrides sont toujours fonctionnels mais le framework Symfony offre des alternatives plus propres : décorateurs de services, event subscribers et extensions Twig.

Checklist récapitulative

• [ ] Activer le debug profiling (restreint par IP)
• [ ] Analyser les requêtes SQL : nombre, durée, doublons
• [ ] Identifier et désinstaller les modules lents ou inutilisés
• [ ] Supprimer les tâches cron orphelines
• [ ] Vérifier les logs d'accès pour détecter des attaques
• [ ] Passer sur un VPS ou dédié si hébergement mutualisé
• [ ] Installer Cloudflare et fail2ban
• [ ] Compresser les images et passer en WebP
• [ ] Héberger les fonts localement et utiliser des SVG
• [ ] Vérifier les erreurs JavaScript en console
• [ ] Mesurer les Core Web Vitals avec PageSpeed Insights