Optimisation Prestashop : Objectif Performances

Mis à jour le 28 juillet 2026

Une boutique PrestaShop avec un thème du marché et une vingtaine de modules peut facilement afficher 5 secondes de chargement sur mobile : assez pour perdre la moitié de vos visiteurs avant même qu'ils voient un produit.

Voici les vrais leviers pour en sortir, du serveur jusqu'au thème, avec les chiffres qui permettent de mesurer chaque gain.

L'hébergement : la fondation de tout

Avant d'installer un module de cache ou de toucher au thème, votre hébergement détermine votre plafond de performance. C'est la couche la plus impactante, et la plus souvent négligée.

Mutualisé, VPS ou serveur dédié ?

PrestaShop ne doit pas tourner sur un mutualisé : TTFB entre 600 ms et 2 000 ms, PHP-FPM et OPcache non configurables, pics de latence aléatoires sous charge. Les ressources partagées plafonnent les performances quelle que soit la qualité du thème ou des modules.

• VPS avec configuration dédiée (SSD NVMe + PHP-FPM + OPcache) : TTFB entre 80 ms et 200 ms. Le minimum pour une boutique sérieuse, à partir de 20 €/mois.
• Serveur dédié : TTFB inférieur à 80 ms, ressources exclusives, configuration entièrement maîtrisée. Recommandé au-delà de 5 000 références ou 500 commandes/jour.

Cloudflare (CDN gratuit) se place devant votre serveur, VPS ou dédié, pour mettre en cache les assets statiques au plus près de vos visiteurs et absorber les pics de trafic. C'est un complément systématique, pas un substitut à un bon hébergement.

Pour mesurer le temps de réponse de votre serveur sans outil tiers, l'outil d'analyse gratuit disponible sur ce site affiche directement le temps de réponse HTTP en millisecondes, avec un diagnostic clair sur ce qu'il faut corriger.

Apache, Nginx ou LiteSpeed ?

Le serveur web qui fait tourner PrestaShop a un impact direct sur les performances, notamment pour la gestion des fichiers statiques (CSS, JS, images) et les connexions simultanées.

• Apache : le plus répandu sur mutualisé. Fiable, mais moins performant sous charge. Compatible avec le .htaccess natif de PrestaShop sans configuration supplémentaire. TTFB moyen sur benchmarks : référence à 100%.
• Nginx : architecture événementielle, bien meilleure gestion des connexions simultanées, jusqu'à 3x plus rapide qu'Apache pour les fichiers statiques. Nécessite de traduire les règles .htaccess en configuration nginx.conf. TTFB réduit de 15 à 30% par rapport à Apache.
• LiteSpeed : le plus performant des trois, surtout combiné au cache LiteSpeed (LSCACHE). Compatible nativement avec le .htaccess comme Apache. Sur certaines configurations, les gains de chargement atteignent 40 à 60% par rapport à Apache. LiteSpeed s'installe en licence sur un VPS (licence WebAdmin gratuite disponible jusqu'à 2 Go de RAM) : c'est la configuration à privilégier.

Si vous avez le choix de votre environnement serveur, LiteSpeed + OPcache + Redis est la combinaison qui donnera les meilleurs résultats sur PrestaShop.

Configuration serveur : PHP, cache et compression

La version de PHP : un gain immédiat et gratuit

Migrer vers une version de PHP récente est l'une des optimisations les plus simples et les plus impactantes. Les benchmarks sont sans appel (voir le guide complet des versions PHP compatibles PrestaShop) :

• PHP 5.6 : encore présent sur certains hébergements anciens avec PrestaShop 1.6. Performances de référence.
• PHP 7.4 : gain moyen de 40 à 50% de vitesse d'exécution par rapport à PHP 5.6 sur PrestaShop. Le minimum acceptable aujourd'hui.
• PHP 8.1 : compatible PrestaShop 8.x. Gain de 15 à 25% supplémentaire par rapport à PHP 7.4 grâce au JIT compiler et aux améliorations de l'engine Zend. C'est la version à cibler.
• PHP 8.2 / 8.3 : compatible avec PrestaShop 8.1+. Gain marginal par rapport à PHP 8.1 (5 à 10%), mais améliore la gestion mémoire sur les catalogues volumineux.

OPcache : ne jamais s'en passer

PHP recompile ses fichiers à chaque requête par défaut. OPcache stocke le bytecode compilé en mémoire pour éviter cette recompilation. Sur PrestaShop, qui charge des dizaines de classes PHP à chaque page, l'impact est massif.

Configuration recommandée dans php.ini :

• opcache.enable=1
• opcache.memory_consumption=256 (minimum 128 Mo, idéalement 256 Mo)
• opcache.max_accelerated_files=20000 (PrestaShop génère beaucoup de fichiers de cache)
• opcache.revalidate_freq=60 (ou 0 en production si vous videz le cache manuellement)

Sans OPcache, vous pouvez perdre 30 à 50% des performances PHP. C'est non négociable.

Redis ou Memcached pour les sessions et le cache

PrestaShop supporte nativement Redis et Memcached pour stocker les sessions et le cache en mémoire vive plutôt que sur disque. Sur un VPS, ajouter Redis permet de réduire significativement les accès disque, surtout sous charge. Le gain sur le TTFB est typiquement de 10 à 20% supplémentaires sur un site déjà bien configuré.

GZIP et Brotli

La compression des réponses HTTP réduit le volume transféré entre le serveur et le navigateur. Sur PrestaShop :

• GZIP : réduit le poids des fichiers HTML, CSS, JS de 60 à 80%. Activé par défaut sur la plupart des serveurs, mais à vérifier.
• Brotli : algorithme plus récent, 15 à 25% plus efficace que GZIP sur les fichiers texte. Disponible sur Nginx et LiteSpeed, à activer si votre hébergeur le supporte.

Vérifiez la présence du header Content-Encoding: br ou Content-Encoding: gzip dans les DevTools de votre navigateur pour confirmer que la compression est active.

HTTP/2 et HTTP/3

HTTP/2 permet le multiplexage des requêtes (plusieurs fichiers chargés en parallèle sur une seule connexion), ce qui améliore considérablement le chargement des pages avec de nombreux assets CSS et JS. HTTP/3 (basé sur QUIC) va encore plus loin, surtout sur mobile. Vérifiez que votre hébergeur supporte au minimum HTTP/2.

PrestaShop : cache natif et CCC

Le cache Smarty

PrestaShop utilise Smarty comme moteur de templates. Le cache Smarty évite de recompiler les fichiers .tpl à chaque requête. En production, il doit être activé en mode "Compilation de fichier" avec la mise en cache activée. Attention : un cache mal configuré ou non vidé après une modification de thème peut afficher des données obsolètes ou provoquer des erreurs 500.

CCC : Combine, Compress, Cache

Le module natif CCC de PrestaShop (Configuration avancée des performances) permet de :

• Combiner les CSS : réduit le nombre de requêtes HTTP liées aux feuilles de style
• Combiner les JavaScript : même principe, mais à manier avec précaution. Certains thèmes ou modules présentent des dépendances JS qui cassent si l'ordre est modifié
• Minifier le HTML : supprime les espaces et commentaires inutiles du code source
• Utiliser le CDN : possible de définir un domaine CDN pour servir les assets depuis un réseau de distribution

Dans la pratique, activer le CCC sur un thème mal codé provoque souvent des bugs visuels ou fonctionnels, car les scripts sont combinés dans le mauvais ordre. C'est précisément le problème des thèmes "tout-en-un" du marché.

PrestaShop 1.6, 1.7 ou 8 : quelle différence de performance ?

La version de PrestaShop a un impact direct sur les performances brutes :

• PrestaShop 1.6 : architecture plus ancienne, moins de fonctionnalités natives mais moins lourde. Compatible PHP 7.4 maximum. Encore très répandu, mais en fin de vie officielle depuis 2022.
• PrestaShop 1.7 : introduction de Webpack et du thème Starter Theme, mais aussi de couches d'abstraction supplémentaires qui ajoutent de la latence. Nécessite une configuration serveur soignée pour performer.
• PrestaShop 8 : compatible PHP 8.1+, support natif des performances améliorées, meilleure gestion du cache. C'est la version cible pour un projet neuf ou une refonte.

Migrer de PrestaShop 1.6 à 8 peut sembler comme un gain de performance automatique, mais ce n'est pas le cas si le thème et les modules ne sont pas optimisés en conséquence. La version de PrestaShop seule ne suffit pas.

Le thème : la cause n°1 des sites lents

Dans 80% des boutiques PrestaShop que j'audite, le thème est le principal coupable des mauvaises performances. Pas l'hébergement, pas les modules : le thème.

L'anatomie d'un thème qui plombe votre score

Les thèmes populaires vendus sur ThemeForest, PrestaShop Addons ou d'autres marketplaces cumulent systématiquement les mêmes défauts :

• Bibliothèques JavaScript massives : jQuery (90 Ko), Slick Slider, Bootstrap JS complet, AOS animations, Magnific Popup, Select2... Il n'est pas rare de compter 15 à 25 fichiers JS différents, représentant 500 Ko à 1,5 Mo de JavaScript chargé en render-blocking.
• CSS surdimensionné : des thèmes all-in-one embarquent des centaines de variantes de composants jamais utilisés. Un CSS de 800 Ko pour une boutique qui en utilise 80 Ko est courant.
• Polices Google Fonts en double : plusieurs versions d'une même police (Regular, Bold, Italic) chargées en priorité haute, bloquant le rendu.
• Requêtes vers des domaines tiers : widgets réseaux sociaux, scripts de tracking mal positionnés, iframes chargées immédiatement même hors viewport.
• Pas de lazy loading natif : toutes les images chargées au démarrage, même celles invisibles à l'écran.

Un thème standard du marché génère facilement plusieurs centaines de Ko de JavaScript inutile et des dizaines de requêtes HTTP supplémentaires par rapport à un thème conçu pour la performance.

Un thème rapide : ce que ça signifie concrètement

Un thème conçu pour la performance repose sur des principes fondamentaux que les thèmes génériques ignorent :

• Zéro JavaScript inutile : uniquement le code nécessaire à la fonctionnalité. Pas de carousel si vous n'en avez pas besoin, pas de librairie de 200 Ko pour faire un menu déroulant qu'on peut coder en 20 lignes.
• CSS critique inline : le CSS nécessaire au rendu "above the fold" est injecté directement dans le <head>, le reste chargé en différé.
• Fonts système ou font display: swap : zéro blocage du rendu par les polices.
• Images en WebP avec lazy loading : nativement intégré dans les templates .tpl.
• Pas de dépendances tierces en chargement synchrone : tous les scripts analytics et tracking chargés en async ou defer.

Résultat sur des boutiques que j'ai recodées de zéro : score PageSpeed Mobile de 85 à 97/100, TTFB sous 150 ms, LCP inférieur à 1,5 seconde. Des chiffres impossibles à atteindre avec un thème du marché, quelle que soit la configuration serveur.

Les modules qui plombent vos performances

PrestaShop charge tous les modules actifs à chaque requête, même ceux qui ne sont pas utilisés sur la page en cours. Un module mal développé peut ajouter 100 à 500 ms au TTFB à lui seul.

Les catégories de modules à surveiller

• Modules de chat en direct (Tidio, Zendesk, LiveChat) : chargent des scripts tiers lourds en priorité haute. Configurer impérativement en chargement différé (defer) ou lazy.
• Modules de personnalisation / recommandations : génèrent des requêtes SQL complexes sur chaque page. Un module de "Produits récemment vus" mal codé peut exécuter 10 à 20 requêtes supplémentaires.
• Modules de tracking avancé (pixels Facebook, GA4 étendu, Klaviyo) : chaque pixel mal configuré est un script synchrone qui bloque le rendu.
• Modules d'avis clients (Trustpilot widget, Avis Vérifiés) : charger le widget en iframe dès le départ est une erreur. Il doit être initialisé après le chargement de la page.
• Modules de comparaison de produits et listes de souhaits : souvent codés avec des appels AJAX non optimisés à chaque hover ou interaction.

Comment identifier les modules problématiques

La méthode la plus efficace est d'utiliser le mode debug de PrestaShop combiné à un profiler SQL. Dans config/defines.inc.php, activer _PS_MODE_DEV_ affiche le nombre de requêtes SQL et le temps d'exécution par module. Un module qui génère plus de 10 requêtes SQL sur une page de catégorie mérite une investigation.

Autre approche : désactiver les modules un par un en mesurant le TTFB à chaque étape via WebPageTest ou GTmetrix. En 30 minutes, vous identifiez souvent 2 ou 3 modules responsables de 60% du ralentissement.

Images et médias

Les images représentent en moyenne 50 à 70% du poids total d'une page e-commerce. C'est le levier avec le meilleur ratio effort/gain sur une boutique existante.

WebP : le format incontournable

Le format WebP offre une réduction de taille de 25 à 35% par rapport au JPEG pour une qualité visuelle identique, et de 50 à 80% par rapport au PNG pour les images avec transparence. PrestaShop 1.7.7+ supporte nativement la génération en WebP via le back-office (Paramètres avancés, Images). Sur PrestaShop 1.6 ou versions antérieures, des modules tiers permettent la conversion.

Un catalogue de 500 produits avec des images moyennes de 150 Ko en JPEG devient 95 Ko en WebP. Sur une page catégorie affichant 20 produits, c'est 1,1 Mo de moins à transférer.

Lazy loading

Depuis HTML5, l'attribut loading="lazy" sur les balises <img> permet au navigateur de ne charger les images que lorsqu'elles approchent du viewport. Natif, sans JavaScript, sans module. Sur PrestaShop, cela implique de modifier les templates .tpl du thème pour ajouter cet attribut, ce que très peu de thèmes du marché font correctement.

Tailles d'images adaptées

PrestaShop génère plusieurs déclinaisons de chaque image (thumbnail, home, medium, large, scene). Un problème fréquent : des images de 1200x1200 px servies dans un conteneur affiché en 300x300 px. Le navigateur charge 4x plus de pixels que nécessaire. La configuration des formats d'image dans le back-office PrestaShop et l'utilisation de l'attribut srcset dans les templates sont essentiels pour corriger ce problème.

Google PageSpeed et Core Web Vitals

Depuis 2021, les Core Web Vitals sont un signal de classement officiel pour Google. Sur mobile, un mauvais score peut vous faire perdre plusieurs positions sur des requêtes concurrentielles. Voici ce que Google mesure et les seuils à atteindre.

LCP : Largest Contentful Paint

Le LCP mesure le temps d'affichage du plus grand élément visible dans le viewport (généralement l'image principale du produit ou le hero banner). Les seuils :

• Bon : moins de 2,5 secondes
• À améliorer : entre 2,5 et 4 secondes
• Mauvais : plus de 4 secondes

Sur PrestaShop, le LCP est souvent dégradé par l'image principale du produit non préchargée (<link rel="preload">), ou par un TTFB serveur trop élevé. L'image LCP doit être explicitement priorisée avec fetchpriority="high" et ne surtout pas être en lazy loading.

INP : Interaction to Next Paint

L'INP (qui a remplacé le FID en mars 2024) mesure la réactivité de la page aux interactions utilisateur (clic, frappe clavier). Les seuils :

• Bon : moins de 200 ms
• À améliorer : entre 200 et 500 ms
• Mauvais : plus de 500 ms

Sur PrestaShop, l'INP est principalement dégradé par l'excès de JavaScript sur le thread principal. Les thèmes avec des dizaines de librairies JS bloquent le thread et retardent la réponse aux clics. C'est le point le plus difficile à corriger sans toucher au code du thème.

CLS : Cumulative Layout Shift

Le CLS mesure l'instabilité visuelle de la page pendant son chargement (éléments qui bougent parce que des images ou polices se chargent après le texte). Le seuil :

• Bon : moins de 0,1
• À améliorer : entre 0,1 et 0,25
• Mauvais : plus de 0,25

Sur PrestaShop, le CLS vient souvent des images sans dimensions explicites dans les balises <img> (attributs width et height manquants), des bannières promotionnelles injectées par des modules après le chargement de la page, ou des polices qui provoquent un FOUT (Flash Of Unstyled Text).

Objectifs réalistes par type de projet

• Thème du marché optimisé (serveur + images) : PageSpeed Mobile 45 à 65/100. Difficile d'aller plus loin sans toucher au code.
• Thème custom conçu pour la performance : PageSpeed Mobile 85 à 97/100. LCP inférieur à 2 secondes, INP inférieur à 100 ms, CLS inférieur à 0,05.

La refonte : la solution radicale

Toutes les optimisations décrites dans ce guide s'empilent sur un thème existant. Chaque couche apporte un gain marginal, mais vous restez limité par l'architecture de votre thème. Passer d'un score de 45 à 60 est possible avec des mois d'efforts. Passer de 45 à 90 demande une refonte.

J'ai refondu des boutiques PrestaShop avec des thèmes issus du marché qui plafonnaient à 35/100 sur mobile malgré un hébergement VPS correctement configuré. Après la refonte avec un thème sur-mesure, les scores sont montés à 91/100 sur mobile, avec un LCP de 1,2 seconde et un CLS à 0,01. Ce sont des chiffres que vous ne pouvez pas obtenir autrement.

La refonte de thème, c'est aussi l'occasion de :

• Supprimer les modules inutiles qui ont été accumulés au fil des années
• Recoder les fonctionnalités spécifiques à votre métier en natif, sans dépendance externe
• Repartir sur une architecture HTML/CSS propre, accessible et compatible avec les futurs modules
• Intégrer nativement les bonnes pratiques images (WebP, srcset, lazy loading, preload)
• Obtenir un code maintenable que vous pouvez faire évoluer sans casser les performances

Si votre boutique stagne malgré vos efforts d'optimisation, ou si votre score PageSpeed Mobile est inférieur à 50/100, une refonte de thème est probablement l'investissement le plus rentable que vous puissiez faire sur votre e-commerce. Consultez le guide sur le coût d'une boutique PrestaShop pour avoir une idée des budgets.

Mes prestations performance :

• Refonte de Thème PrestaShop sur-mesure : thème conçu sans JS inutile, optimisé Core Web Vitals dès le départ, adapté à votre catalogue et votre charte graphique.
• Audit de performance : analyse complète du stack serveur, du thème et des modules pour identifier précisément vos freins et prioriser les actions.
• Accompagnement mensuel : suivi des métriques Core Web Vitals, corrections au fil de l'eau, optimisations progressives.

Votre boutique mérite mieux qu'un score à 40/100 sur mobile. Discutons de votre projet.