Optimisation PrestaShop : comment accélérer votre boutique étape par étape

Sommaire

• La vitesse, c’est du chiffre d’affaires : chaque seconde de chargement supplémentaire réduit le taux de conversion de 7 %. Sur une boutique à 20 000 visites/mois, ça représente des milliers d’euros perdus chaque mois.
• Les 3 leviers qui changent tout : l’hébergement (souvent sous-dimensionné), le cache PrestaShop (souvent mal configuré), et les images (rarement optimisées). Ces trois points seuls peuvent faire gagner 20 à 40 points de score PageSpeed.
• Ce que ça change concrètement : un meilleur score Core Web Vitals = un meilleur classement Google + moins d’abandons = plus de ventes, sans toucher à votre catalogue ni à vos prix.

Pourquoi la vitesse PrestaShop impacte directement vos ventes

Un PrestaShop lent ne fait pas que frustrer vos visiteurs. Il vous coûte de l’argent, chaque jour, silencieusement.

Core Web Vitals : LCP, CLS, INP expliqués simplement

Google mesure la qualité de votre boutique via trois métriques appelées Core Web Vitals. Pas besoin d’être développeur pour les comprendre :

LCP (Largest Contentful Paint) : Le temps avant que l’élément principal de la page (souvent l’image produit ou la bannière) soit visible. Objectif : moins de 2,5 secondes. Au-delà, Google considère votre page comme lente.

CLS (Cumulative Layout Shift) : La stabilité visuelle de votre page pendant le chargement. Vous avez déjà cliqué sur un bouton qui s’est déplacé au dernier moment ? C’est un mauvais CLS. Objectif : score inférieur à 0,1.

INP (Interaction to Next Paint) : La réactivité de votre site aux clics et aux interactions. Remplace le FID depuis mars 2024. Objectif : moins de 200 millisecondes.

Ces trois métriques sont mesurées sur de vraies sessions utilisateurs via Chrome. Google évalue le 75e percentile de vos chargements : autrement dit, 75 % de vos visiteurs doivent avoir une bonne expérience pour que votre site soit considéré comme performant.

-1 seconde de chargement = combien de ventes perdues ?

Les chiffres sont clairs et documentés :

• -7 % de conversions par seconde de chargement supplémentaire
• Une page qui passe de 4 à 2 secondes peut gagner +14 % de conversions
• Amazon a calculé que 100 ms de latence = -1 % de ventes

Exemple concret : une boutique avec 20 000 visiteurs/mois, un taux de conversion de 2 % et un panier moyen de 80 € perd potentiellement 4 800 € de CA par mois si elle charge en 4 secondes au lieu de 2. Soit plus de 57 000 € par an.

Impact SEO : ce que Google mesure vraiment

Google intègre les Core Web Vitals dans son algorithme de classement depuis 2021, et leur poids n’a fait qu’augmenter. La règle est simple : à contenu équivalent, la page la plus rapide gagne.

Mais l’impact SEO va au-delà du classement direct. Un site lent génère un taux de rebond élevé : et ce signal comportemental est détecté par les algorithmes. Les visiteurs qui repartent en 3 secondes sans interagir envoient un signal négatif fort à Google.

Seules 28 % des boutiques PrestaShop passent les trois Core Web Vitals simultanément, contre 52 % pour Shopify. La bonne nouvelle : PrestaShop est hautement optimisable. Avec la bonne configuration, vous pouvez atteindre des scores mobiles de 85+ et des temps de chargement inférieurs à 2 secondes.

Diagnostic : comment mesurer les performances de votre PrestaShop

Avant d’optimiser quoi que ce soit, il faut mesurer. Voici les trois outils à utiliser, dans l’ordre.

Google PageSpeed Insights : lire les résultats sans être dev

PageSpeed Insights est le point de départ. Entrez l’URL de votre boutique et vous obtenez deux scores : mobile et desktop.

Lisez toujours le score mobile en premier. C’est lui que Google utilise pour le classement (mobile-first indexing). Un score desktop de 90 avec un score mobile de 35, c’est un problème.

Ce que vous devez regarder en priorité :

• LCP : si c’est une image, elle doit être préchargée et en WebP
• Total Blocking Time (TBT) : révèle les scripts JS qui bloquent le rendu
• Opportunities : la liste des optimisations avec leur gain estimé en secondes

À relativiser avant de paniquer : PageSpeed Insights affiche en réalité deux types d’informations. D’un côté, il y a les données issues des vrais visiteurs : Google observe comment votre site se charge réellement chez les internautes, puis fait une moyenne sur 28 jours. Ce sont les mêmes signaux que vous pouvez retrouver dans la Google Search Console, rubrique Expérience > Core Web Vitals. De l’autre, il y a un test automatique lancé au moment où vous cliquez sur “Analyser” : Google recharge une seule page dans des conditions volontairement difficiles, avec un téléphone peu puissant, une connexion mobile lente et aucun cache déjà préparé. C’est pour cela qu’un score mobile peut paraître sévère, même si vos clients ne vivent pas toujours une expérience aussi mauvaise. Sur une boutique PrestaShop, un score mobile autour de 50-60 peut déjà être une base correcte, surtout si les Core Web Vitals réels progressent. L’objectif n’est pas de supprimer toutes les recommandations, mais de traiter celles qui ont un impact réel sur vos pages importantes : accueil, catégories, fiches produits et panier.

PrestaShop Profiler : l’outil interne méconnu

C’est l’outil le plus puissant pour diagnostiquer une boutique lente : et le moins connu des marchands.

Le Profiler natif de PrestaShop s’active via le back-office à partir de PrestaShop 8, dans Paramètres avancés > Performance > Outil de debug. Sur PrestaShop 1.7, ce réglage n’est pas disponible d’origine dans le back-office : il faut intervenir dans un fichier du site pour l’activer proprement. Une fois activé, il affiche en bas de chaque page le détail complet : toutes les requêtes SQL exécutées, le temps d’exécution de chaque hook, et la consommation mémoire.

Attention : l’Outil de debug lié au profiling n’est pas le mode debug classique. Le mode debug affiche les erreurs PHP. Le profiling, lui, analyse les performances : ce sont deux usages distincts.

Ce que vous cherchez dans le Profiler :

• La section initContent : si elle est anormalement longue, un module ou une requête SQL est en cause
• Les requêtes SQL dupliquées : signe d’un module mal codé
• Les hooks surchargés : trop de modules accrochés sur displayHeader

Désactivez le Profiler dès que vous avez fini votre diagnostic. Ne le laissez jamais actif en production.

GTmetrix et WebPageTest : quand les utiliser

GTmetrix est utile pour obtenir une analyse visuelle détaillée avec une chronologie de chargement (waterfall). Il identifie précisément quelles ressources bloquent le rendu.

WebPageTest est l’outil des experts. Il permet de tester depuis différentes localisations géographiques, de simuler différentes connexions (3G, 4G), et de comparer des versions avant/après. Indispensable pour valider qu’une optimisation a bien eu l’effet attendu.

Pour un diagnostic rapide : PageSpeed Insights suffit. Pour un audit approfondi : combinez les trois.

Les 6 optimisations à fort impact (classées par priorité)

Voici les optimisations classées par rapport impact / effort. Commencez par le haut.

1. L’hébergement : la base que tout le monde néglige

C’est le levier le plus sous-estimé. Un hébergement mutualisé partage les ressources CPU, RAM et I/O avec d’autres sites. Si votre voisin de serveur reçoit un pic de trafic, votre boutique ralentit : sans que vous puissiez rien y faire.

Configuration minimale recommandée pour une boutique PrestaShop en production :

• VPS (pas d’hébergement mutualisé)
• Au moins 4 Go de RAM
• SSD NVMe (pas SATA)
• PHP 8.1 ou supérieur avec OPcache activé
• Serveur LiteSpeed ou Nginx (plus rapides qu’Apache pour le PHP)

PHP 8.1+ apporte des gains de performance significatifs par rapport aux versions antérieures. Si votre boutique tourne encore sur PHP 7.x, c’est votre première priorité.

Si vous n’êtes pas à l’aise pour évaluer votre infrastructure serveur, c’est exactement le type d’intervention qu’un freelance spécialisé en maintenance PrestaShop peut prendre en charge rapidement.

2. Le cache : activer et bien configurer

PrestaShop intègre un système de cache natif puissant, accessible dans Paramètres avancés > Performance. Deux niveaux à configurer :

Le CCC (Combine, Compress, Cache) : Combine et minifie vos fichiers CSS et JS en un seul fichier, réduit le nombre de requêtes HTTP et compresse les assets. À activer impérativement. Dans les tests d’A2 Hosting, activer le CCC et le cache Smarty a divisé par deux le temps de chargement d’une boutique PrestaShop par défaut.

Paramètres CCC à activer :

• Smart cache pour les feuilles de style
• Smart cache pour le code JavaScript
• Optimisation Apache (ajoute des directives .htaccess pour le cache navigateur)

Le cache serveur : Dans le menu natif de PrestaShop, les options proposées sont généralement Memcached, APC ou Xcache selon l’environnement serveur. Redis n’apparaît pas dans cette liste par défaut : il peut exister via une configuration serveur spécifique, un module ou une architecture plus avancée, mais ce n’est pas une option native visible dans Paramètres avancés > Performance. Pour une boutique TPE/PME, commencez par CCC, Smarty, OPcache côté PHP et, si disponible, Memcached plutôt que de chercher Redis à tout prix.

Règle d’or : videz toujours le cache après une modification de thème ou de module. Un cache périmé peut afficher d’anciennes données à vos clients.

3. Les images : compression et passage au WebP

Les images sont la première cause de mauvais LCP. Sur 84 % des pages produit, l’image principale est l’élément LCP. Si elle n’est pas optimisée, votre score s’effondre.

Le passage au format WebP est non négociable en 2026. WebP offre une compression 25 à 35 % supérieure au JPEG pour une qualité visuelle identique. PrestaShop 8+ et PrestaShop 9 supportent nativement le WebP.

Actions concrètes :

• Convertir toutes les images existantes en WebP (module ou script batch)
• Ne jamais uploader une image de plus de 200 Ko pour une fiche produit
• Définir des dimensions explicites (width/height) dans le HTML pour éviter le CLS
• Activer le lazy loading pour les images hors écran

Des modules de conversion et de compression WebP existent sur le marketplace officiel PrestaShop. Pour les trouver, le plus simple est de chercher directement sur PrestaShop Addons.

4. Les modules : identifier ceux qui plombent le score

Les modules sont la première cause de lenteur sur PrestaShop. Chaque module actif s’accroche à des hooks et exécute du code à chaque chargement de page : même s’il n’affiche rien sur la page en question.

Le module qui plombe le plus souvent les performances ? Les modules de chat en direct mal configurés : ils bloquent le rendu de la page entière en chargeant leurs scripts de manière synchrone dans le <head>.

Méthode de diagnostic :

1. Activez le Profiler PrestaShop
2. Regardez les hooks displayHeader et actionFrontControllerSetMedia
3. Désactivez les modules suspects un par un et mesurez l’impact

Modules à surveiller en priorité :

• Chat en direct (Tidio, LiveChat, Zendesk) : toujours chargés en mode asynchrone
• Modules de statistiques tiers : souvent gourmands en requêtes SQL
• Modules de réassurance avec animations CSS lourdes
• Modules inutilisés mais actifs : désactivez-les, ne les laissez pas en veille

5. La base de données : nettoyage et indexation

Une base PrestaShop grossit avec le temps : logs, paniers abandonnés, sessions expirées, historique de recherche… Tout ça s’accumule et ralentit les requêtes.

Nettoyage à effectuer régulièrement :

• Logs : ps_log peut contenir des millions de lignes sur une boutique active
• Paniers abandonnés : la table ps_cart grossit vite
• Sessions : ps_connections et ps_guest s’accumulent
• Recherches : ps_search_word et ps_search_index à purger périodiquement

Depuis le back-office : Paramètres avancés > Base de données > Optimiser la base de données.

Pour aller plus loin, vérifiez que les index MySQL sont bien en place sur les colonnes fréquemment requêtées (id_product, id_category, id_customer). Un index manquant peut transformer une requête de 5 ms en une requête de 500 ms.

6. Le thème : ce qui ralentit sans qu’on le sache

Un thème mal conçu peut annuler tous vos efforts d’optimisation. Les problèmes les plus courants :

JavaScript chargé en synchrone dans le <head> : bloque tout le rendu jusqu’à ce que le script soit téléchargé et exécuté. Doit être chargé en defer ou async.

CSS non utilisé : les thèmes premium incluent souvent des centaines de lignes de CSS pour des fonctionnalités que vous n’utilisez pas. Ça alourdit inutilement chaque page.

Polices Google Fonts chargées depuis les serveurs Google : génère une requête externe supplémentaire. Hébergez vos polices localement.

Sliders et carrousels avec animations lourdes : souvent les premiers responsables d’un mauvais CLS et d’un TBT élevé.

Si vous êtes sur PrestaShop 9, le thème Hummingbird est construit avec Bootstrap 5, TypeScript et une approche mobile-first. Il est nativement optimisé pour les Core Web Vitals. Si vous êtes sur PS 1.7 ou PS 8 avec un thème custom vieillissant, un audit thème s’impose.

Les erreurs classiques qui font ramer une boutique PrestaShop

Ces erreurs reviennent sur presque toutes les boutiques que j’audite. Vérifiez-les une par une.

Modules inutilisés mais actifs : Un module désinstallé mais pas désactivé continue d’exécuter du code. Allez dans votre liste de modules et désactivez tout ce que vous n’utilisez pas activement. C’est gratuit et immédiat.

Images non compressées uploadées directement : Le back-office PrestaShop n’optimise pas les images à l’upload. Une photo de 4 Mo uploadée depuis un smartphone reste une photo de 4 Mo sur votre fiche produit. Mettez en place un workflow de compression avant upload (TinyPNG, Squoosh, ou un module dédié).

PHP obsolète : PHP 7.4 est en fin de vie depuis décembre 2022. PHP 8.0 depuis novembre 2023. Si votre boutique tourne encore sur ces versions, vous perdez des gains de performance significatifs et vous exposez à des failles de sécurité. La migration vers PHP 8.1 ou 8.2 est souvent la correction la plus rapide à fort impact.

Logs non purgés : La table ps_log peut atteindre plusieurs gigaoctets sur une boutique active de quelques années. Chaque requête qui touche cette table ralentit. Purgez-la régulièrement et configurez une rotation automatique.

Mode debug laissé actif en production : Ça arrive plus souvent qu’on ne le croit. Le mode debug désactive le cache et génère des logs supplémentaires. Vérifiez que _PS_MODE_DEV_ est bien à false dans votre fichier config/defines.inc.php.

Ces cinq erreurs sont aussi au cœur de ce que couvre un bon contrat de maintenance PrestaShop : la surveillance régulière évite qu’elles s’accumulent silencieusement.

Ce que j’optimise en priorité chez mes clients

Voici mon ordre d’intervention réel, après 15 ans sur des boutiques de toutes tailles.

Étape 1 : Audit rapide (30 min) : PageSpeed Insights sur la home, une fiche produit et la page panier. Je note les scores mobiles et les trois principales opportunités identifiées. C’est là que je vois si le problème est côté serveur, images, ou modules.

Étape 2 : Hébergement et PHP : Si la boutique tourne sur un mutualisé ou PHP < 8.1, je commence par là. C’est le seul levier qui améliore toutes les pages en même temps, sans toucher au code.

Étape 3 : Cache et CCC : Activation et configuration complète. Résultat quasi immédiat sur le score. Sur une boutique non configurée, c’est souvent +15 à +25 points de score mobile en une heure.

Étape 4 : Images : Conversion en WebP + compression des images existantes. C’est long sur un gros catalogue, mais l’impact sur le LCP est spectaculaire.

Étape 5 : Audit modules : Profiler activé, identification des modules lents, désactivation ou remplacement. C’est là que je trouve le plus souvent les gains cachés.

Étape 6 : Thème et JS : Chargement différé des scripts non critiques, suppression du CSS inutilisé, hébergement local des polices.

Mon avis tranché : la majorité des marchands s’attaquent au mauvais levier en premier parce que PrestaShop leur est souvent vendu comme une somme de modules, de thèmes et de fonctionnalités visibles. Ils cherchent donc le problème dans ce qu’ils voient : le slider, le module de chat, la fiche produit. En réalité, les gains les plus solides viennent souvent de ce qui ne se voit pas : hébergement, version PHP, cache, base de données et qualité du thème. Cela révèle une chose simple : une boutique PrestaShop performante ne se vend pas seulement comme un assemblage de modules, elle se construit comme un système technique cohérent.

Sur les boutiques que j’optimise, les gains les plus rapides viennent généralement d’un trio très concret : hébergement plus sain, cache correctement configuré et images enfin maîtrisées. Le score PageSpeed mobile peut parfois gagner 15 à 25 points en une intervention courte, mais le vrai objectif reste la fluidité ressentie par l’utilisateur et la stabilité des Core Web Vitals dans le temps.

Cas concret anonymisé : une boutique mode d’environ 800 références cumulait hébergement mutualisé, PHP vieillissant, cache absent, images JPEG trop lourdes et module de chat bloquant. Après migration serveur, mise à jour PHP, configuration CCC, conversion WebP et nettoyage des scripts bloquants, le site est devenu nettement plus stable et exploitable, sans changer son catalogue ni sa stratégie commerciale.

Quand faire appel à un freelance PrestaShop ?

Certaines optimisations sont accessibles à tout marchand motivé : activer le CCC, purger les logs, désactiver des modules inutiles. D’autres nécessitent des compétences techniques.

Faites appel à un développeur si :

• Votre score PageSpeed mobile est inférieur à 40 et les optimisations basiques n’ont rien changé
• Vous avez des erreurs SQL dans le Profiler que vous ne savez pas interpréter
• Vous devez migrer votre hébergement ou votre version de PHP
• Votre thème custom génère du JS bloquant et vous ne savez pas où intervenir
• Vous préparez une période de fort trafic (Black Friday, soldes) et vous voulez être sûr de tenir la charge

Ce qui nécessite obligatoirement un dev :

• Optimisation des requêtes SQL (ajout d’index, réécriture de requêtes)
• Mise en place ou réglage d’un cache serveur avancé, comme Memcached, Varnish ou Redis si l’hébergement le permet réellement
• Audit et correction du code d’un module tiers
• Migration vers PrestaShop 8 ou 9 : qui s’accompagne souvent d’une refonte des optimisations

Si vous envisagez une migration, consultez d’abord notre guide sur la migration PrestaShop 1.7 vers 8 : les gains de performance sont significatifs, mais la migration elle-même doit être préparée.

Pour un audit ou une intervention directe sur votre boutique, consultez la page freelance PrestaShop.

Mon avis d’expert

Quel est le pire hébergement que vous ayez rencontré sur une boutique cliente, et quel gain avez-vous obtenu après migration ?

Le cas le plus parlant était une boutique sur un hébergement OVH sous-dimensionné, avec une base de données trop limitée qu’il fallait purger en permanence pour éviter les ralentissements. Après migration chez o2switch, les problèmes récurrents de performance de ce type ont disparu : la boutique avait enfin une base serveur plus saine et plus prévisible.

Comment identifiez-vous en moins de 10 minutes le module responsable d’une lenteur ?

Je commence par activer le profiling PrestaShop, puis je croise les informations avec les logs PrestaShop et les logs serveur. En regardant les hooks coûteux, les requêtes SQL répétées et les erreurs récentes, on repère souvent très vite le module ou la zone responsable.

Quel score PageSpeed mobile minimum recommandez-vous avant de lancer une campagne publicitaire ?

Je recommande au minimum 50-60 sur mobile avant d’envoyer du trafic payant important vers une boutique. Ce n’est pas un score parfait, mais c’est souvent le seuil minimal pour éviter de payer des clics qui se perdent à cause d’une expérience trop lente.

FAQ