Performance PrestaShop : Optimiser votre boutique

Ce qui ralentit un PrestaShop : serveur, code ou contenus ?

Avant de toucher au moindre réglage, il faut savoir une chose : sur PrestaShop, la lenteur vient toujours de l’une de ces trois familles. Et elles ne se corrigent pas au même endroit, ni avec les mêmes outils.

Trois familles, et pourquoi savoir laquelle vous concerne

Le serveur, d’abord. C’est tout ce qui se passe avant même que la première image ne s’affiche : la version de PHP, le cache, la base de données, la puissance de la machine. Quand c’est le serveur qui coince, aucune optimisation d’image ne vous sauvera.

Le code, ensuite. Vos modules, votre thème, le nombre de requêtes SQL générées à chaque page. Un seul module mal codé peut ajouter une seconde entière à chaque chargement, sans que vous vous en doutiez.

Les contenus, enfin. Les images, les polices, les scripts tiers. C’est la partie la plus visible, souvent la plus simple à corriger, et paradoxalement celle sur laquelle tout le monde se jette en premier, alors qu’elle n’est pas toujours la coupable.

Ce que la lenteur vous coûte vraiment

Un rappel qui suffit à motiver le reste : une seconde de trop, c’est en moyenne 7 % de conversions en moins, et plus d’un visiteur mobile sur deux qui abandonne au-delà de trois secondes. Sur ce point, je ne vais pas m’étendre, on l’a détaillé chiffres à l’appui dans notre guide dédié au diagnostic d’un PrestaShop lent.

Ce qui nous intéresse ici, c’est l’action. Et pour agir juste, il faut d’abord parler des chiffres que Google surveille, parce qu’ils ne sortent pas de nulle part.

Les Core Web Vitals : d’où viennent les chiffres de Google

Quand un outil vous dit que votre LCP doit rester sous 2,5 secondes, vous vous demandez peut-être d’où sort ce chiffre précis. Pourquoi 2,5 et pas 3 ? La réponse tient dans quinze ans de travail des ingénieurs qui font tourner le web, et c’est une histoire qu’aucun guide PrestaShop ne raconte. Elle mérite deux minutes, parce qu’elle change la façon dont vous lirez vos scores.

Quinze ans de mesure de la performance web

Tout commence en 2007. Un ingénieur de Yahoo, Steve Souders, publie « High Performance Web Sites » et pose quatorze règles qui font encore autorité aujourd’hui. Dans la foulée, il crée YSlow, le premier outil grand public pour noter la vitesse d’une page. C’est l’acte de naissance de la discipline.

Souders rejoint ensuite Google, qui reprend le flambeau et l’industrialise : PageSpeed Insights, puis Lighthouse, deviennent les outils de référence. Mais le vrai tournant, c’est début 2020, quand l’équipe Chrome introduit les Core Web Vitals, trois métriques censées résumer l’expérience réelle d’un visiteur : le LCP pour le chargement, le FID pour la réactivité, le CLS pour la stabilité visuelle. L’année suivante, ces signaux deviennent un critère de classement dans Google.

Dernier acte, et pas des moindres. En mai 2022, l’équipe Chrome introduit une nouvelle métrique expérimentale, l’INP, jugée plus fidèle que le FID. Et le 12 mars 2024, l’INP remplace officiellement le FID parmi les Core Web Vitals. Autrement dit, les guides qui parlent encore de « LCP, FID, CLS » citent une métrique morte depuis deux ans. Petit test de fraîcheur au passage.

Les 4 seuils à connaître avant de toucher à quoi que ce soit

Voici la grille officielle. Gardez-la sous les yeux : c’est elle qui vous dira si une optimisation vous a fait passer une ligne, ou seulement gagné un chiffre cosmétique.

Un chiffre à garder en tête pour relativiser vos scores : à peine un tiers des sites dans le monde atteignent le seuil des Core Web Vitals. Et la métrique qui coince le plus en 2026, c’est l’INP. Près de la moitié des sites échouent à se maintenir sous 200 ms, surtout sur mobile, parce que c’est là que le JavaScript des modules fait le plus de dégâts. Si vous n’êtes pas dans le vert partout, vous êtes dans la norme, pas dans l’échec.

Savez-vous déjà où chercher ?

Avant d’attaquer les optimisations, posez-vous trois questions. Votre TTFB est-il au-dessus ou en dessous de 800 ms ? Avez-vous déjà identifié un module qui rame ? Votre base de données pèse-t-elle plusieurs gigaoctets ?

Si vous répondez « je ne sais pas » aux trois, ne lisez pas la suite tout de suite. Commencez par mesurer. La méthode complète, avec le profiler et l’arbre de décision serveur ou front-end, est dans notre guide de diagnostic d’un PrestaShop lent. Cet article-ci part du principe que vous savez déjà où ça coince, et qu’il est temps de corriger.

Côté serveur : les 5 optimisations qui font la différence

C’est ici que se joue l’essentiel de la performance. Le serveur, c’est tout ce qui se passe avant que le navigateur ne reçoive quoi que ce soit, et c’est presque toujours là que se cachent les plus grosses secondes perdues. Les cinq réglages qui suivent sont rangés du plus rentable au plus fin.

1. OPcache : le réglage gratuit que votre hébergeur a peut-être laissé désactivé

À chaque page, PHP recompile votre code avant de l’exécuter. OPcache garde cette compilation en mémoire et évite de tout refaire à chaque visite. C’est gratuit, c’est intégré à PHP, et sur une boutique où il était éteint, l’activer peut diviser le TTFB par deux.

Le hic, c’est qu’un hébergeur généraliste le laisse parfois désactivé, ou mal dimensionné. Vérifiez sa présence dans votre configuration PHP. Mon conseil : c’est le tout premier réflexe, avant même de penser à un module.

2. PHP 8.2 ou plus récent : jusqu’à 30 % de gain

Chaque version majeure de PHP est plus rapide que la précédente. Le passage de PHP 7.4 à PHP 8 apporte à lui seul jusqu’à 30 % de gain de vitesse, sans toucher à une ligne de votre code. PrestaShop 8 et 9 supportent jusqu’à PHP 8.5.

La seule précaution : vérifiez que vos modules suivent avant de monter en version. Un vieux module incompatible peut casser une page. Testez en préproduction, puis basculez.

3. Redis : sortir le cache du disque

Par défaut, PrestaShop peut mettre son cache sur le disque, ce qui est lent. Redis garde ce cache en mémoire vive, là où l’accès est quasi instantané. Sur une boutique lourde, on voit des temps de génération qui passent de 800 ms à 120 ms.

Redis a besoin d’être installé côté serveur, ce n’est pas un simple bouton dans le back-office. C’est le premier réglage de cette liste qui demande un vrai accès à la machine.

4. LiteSpeed ou Nginx : quitter Apache

Apache fait le travail, mais il encaisse mal les pics de trafic. Nginx tient mieux la charge, et LiteSpeed, couplé à son cache LSCache, est particulièrement efficace sur PrestaShop. Sur les gros catalogues, un cache serveur comme Varnish, placé devant PrestaShop, absorbe les pics de trafic et sert les pages déjà générées en quelques millisecondes. Selon la configuration, on récupère entre 20 et 100 millisecondes par page.

Là encore, on parle du socle logiciel du serveur. Ce n’est pas quelque chose que vous changez depuis votre interface d’administration.

5. MariaDB et le buffer pool InnoDB

C’est le réglage le plus technique de la liste, mais il compte sur un gros catalogue. MariaDB conserve un cache de requêtes que MySQL 8 a supprimé, ce qui peut faire une vraie différence. Et bien dimensionner le buffer pool InnoDB, la mémoire que la base réserve pour garder ses données sous la main, évite des allers-retours coûteux vers le disque.

Si ces mots ne vous parlent pas, c’est normal : c’est exactement le genre de réglage qu’on confie à quelqu’un qui l’a déjà fait cent fois.

Vous l’avez sûrement remarqué : sur ces cinq réglages, quatre demandent un accès au serveur. OPcache, la version de PHP, Redis, LiteSpeed. Ce sont précisément ceux qu’un marchand sur un hébergement mutualisé ne peut pas activer lui-même. Et c’est là que se trouve le plus gros du gain.

Côté code : 3 actions depuis votre back-office

Bonne nouvelle après la partie serveur : ces trois-là, vous pouvez les faire vous-même, sans accès à la machine. Elles se règlent depuis votre interface d’administration ou avec un accès FTP.

1. Couper la connexion à l’API Addons

Par défaut, votre back-office interroge régulièrement le serveur d’Addons de PrestaShop pour vérifier les mises à jour de modules. Quand ce serveur répond lentement, c’est votre administration qui rame, et parfois votre front-office avec. Couper ou espacer ces appels allège immédiatement la charge.

2. Un module désactivé n’est pas un module supprimé

C’est une confusion qui coûte cher. Quand vous désactivez un module, il reste installé : ses fichiers sont chargés, ses points d’accroche restent enregistrés, ses éventuels overrides restent en place. Il continue de peser, discrètement.

La règle est simple : un module dont vous ne vous servez plus, on ne le désactive pas, on le désinstalle proprement. Ce qu’on voit chez nos clients, c’est des boutiques qui traînent une dizaine de modules « éteints » depuis des années, et qui gagnent en fluidité rien qu’en faisant le ménage.

3. Le CCC, sauf si vous êtes déjà en HTTP/2

Le CCC (Combine, Compress, Cache), dans les paramètres de performance de PrestaShop, regroupe vos fichiers CSS et JavaScript pour réduire le nombre de requêtes. Sur un serveur en HTTP/1.1, c’est un vrai gain.

Mais attention à la nuance que presque personne ne mentionne : si votre serveur est déjà en HTTP/2, qui gère très bien les requêtes multiples en parallèle, regrouper les fichiers peut n’apporter aucun gain, voire ralentir. Testez avant et après, ne l’activez pas les yeux fermés.

Pour aller plus loin sur l’identification d’un module qui plombe vos pages, notre guide de diagnostic détaille l’usage du profiler pas à pas.

Côté contenus : 5 actions sur vos pages

La partie la plus visible, et souvent la plus accessible. C’est ce que voit le navigateur de votre visiteur, et c’est là que se jouent le LCP et une bonne partie de l’INP.

1. WebP et AVIF : le format que PrestaShop 9 gère nativement

Vos images sont probablement le poste le plus lourd de vos pages. Le WebP et l’AVIF pèsent bien moins que le JPEG ou le PNG, pour une qualité équivalente. C’est souvent le plus gros gain côté front pour le moins d’effort.

Un module de conversion suffit sur les versions récentes de PrestaShop 1.7 et 8. Et sur PrestaShop 9, le thème Hummingbird sert nativement le WebP et l’AVIF, sans aucun module. On y revient plus bas.

2. Le lazy loading, et l’image qu’il ne faut surtout pas différer

Le lazy loading retarde le chargement des images hors écran jusqu’à ce que le visiteur fasse défiler la page. Excellent pour la vitesse perçue. Sauf pour une image : celle qui constitue votre LCP, en général la grande image en haut de page.

Si vous appliquez le lazy loading à cette image-là, vous retardez justement l’élément que Google mesure, et vous dégradez votre score au lieu de l’améliorer. La règle : tout en lazy, sauf l’image principale au-dessus de la ligne de flottaison.

3. Vos polices Google : un problème de vitesse et un problème RGPD

Charger vos polices directement depuis les serveurs de Google ajoute une connexion externe qui ralentit l’affichage. En les hébergeant localement sur votre serveur, vous gagnez sur la vitesse. Et vous réglez au passage un second sujet, souvent oublié : appeler les polices Google à distance transmet l’adresse IP de vos visiteurs, ce qui pose une vraie question de conformité RGPD.

Deux problèmes, une seule action. C’est le genre de réglage propre qu’on aime : il fait d’une pierre deux coups. Le sujet est détaillé dans notre guide RGPD pour PrestaShop.

4. Un CDN, et pourquoi le prendre européen

Un CDN (réseau de diffusion de contenu) place des copies de vos fichiers statiques sur des serveurs répartis géographiquement, plus proches de vos visiteurs. Vos images et vos scripts arrivent plus vite, et votre serveur principal est soulagé.

Mon conseil : privilégiez un CDN européen. Pour les mêmes raisons de souveraineté et de conformité que pour les polices, faire transiter votre trafic par une infrastructure européenne est plus sain que de tout envoyer outre-Atlantique.

5. Filtrer les bots qui consomment votre serveur pour rien

Une part de votre charge serveur ne vient pas de clients, mais de robots : aspirateurs de contenu, scanners, bots d’IA qui explorent votre catalogue en boucle. Ils consomment des ressources sans jamais rien acheter. Filtrer ou limiter ces accès, au niveau du serveur ou avec une protection dédiée, rend de la respiration à votre boutique aux heures de pointe.

Les 4 fausses bonnes idées qui ralentissent au lieu d’accélérer

Après des centaines de boutiques passées entre nos mains, on voit toujours revenir les mêmes réflexes bien intentionnés qui font l’inverse de ce qu’on attend d’eux. Autant vous les épargner.

1. Le module « speed booster » qui promet tout

Il y a des modules de performance qui promettent d’accélérer votre boutique d’un clic. Le problème, c’est qu’un module ne peut agir que sur ce qui est à sa portée : la conversion d’images, un cache de pages, le lazy loading. Il ne peut pas activer OPcache, changer votre version de PHP, installer Redis ni remplacer Apache. Or ce sont justement les trois plus gros gains. Un module de performance de ce type traite les symptômes légers et laisse la vraie cause serveur intacte, tout en ajoutant du code. On en reparle dans la FAQ.

2. La minification agressive qui casse le tunnel de commande

Compresser à outrance le JavaScript peut sembler malin. Sauf que sur PrestaShop, certains scripts du tunnel de commande ou des modules de paiement supportent mal une minification trop poussée. Résultat : une page panier qui ne fonctionne plus, et des ventes perdues. Le gain de quelques kilo-octets ne vaut jamais un tunnel cassé.

3. Le preload posé sur tout

Le preload dit au navigateur de charger une ressource en priorité. Utile sur une ou deux ressources critiques. Mais si vous mettez tout en priorité, plus rien n’est prioritaire : vous saturez la bande passante au démarrage et vous ralentissez l’affichage. Le preload est un scalpel, pas un pinceau.

4. Le cache installé sur un site déjà malade

Poser un cache sur une boutique dont le vrai problème est un module qui génère 400 requêtes SQL, c’est mettre un pansement sur une fracture. Le cache masque le symptôme sur les pages en cache, mais dès qu’une page non mise en cache est demandée, la lenteur ressurgit. Diagnostiquez d’abord, mettez en cache ensuite.

PrestaShop 9 : vraiment plus rapide ?

La question revient sans cesse, et la réponse mérite d’être nuancée. Oui, PrestaShop 9 est plus rapide côté front, mais pas magiquement, et pas sur tout.

Ce que Hummingbird 2.0 change côté front

Depuis la version 9.1, sortie en mars 2026, le thème Hummingbird 2.0 remplace le vieux thème Classic par défaut. Et c’est une refonte complète, pensée pour la performance. Il repose sur Bootstrap 5 et TypeScript, sert nativement les images en WebP et AVIF, et charge jQuery de façon différée, ce qui améliore directement les Core Web Vitals, en particulier l’INP.

Le point important, souvent ignoré : le thème Classic fonctionne toujours sous PrestaShop 9, mais il ne bénéficie ni du pipeline WebP/AVIF ni des optimisations de Hummingbird. Autrement dit, migrer vers la 9 en restant sur Classic, c’est se priver de la moitié de l’intérêt.

Ce que la migration ne réglera pas

Soyons clairs : passer à PrestaShop 9 gagne côté contenus et front-office. Mais ça ne corrigera ni un hébergement mutualisé sous-dimensionné, ni un module tiers mal codé qui multiplie les requêtes SQL. Le socle serveur et le tri des modules restent à faire, version 9 ou pas.

Côté effort, l’ampleur dépend de votre point de départ. Une 8.x sans modules exotiques se migre en un après-midi. Une 1.7 chargée en modules demande une à deux semaines de tests. Une 1.6 avec refonte de thème, deux à six semaines. Ce n’est jamais l’installation qui prend du temps, c’est la vérification de chaque parcours.

Si la migration est à votre programme, on en parle en détail sur notre page dédiée à la migration PrestaShop.

La checklist des 13 optimisations

Toutes les optimisations de l’article dans un tableau. Rangées par famille, avec la difficulté, le coût et l’ordre de grandeur du gain. Cochez au fur et à mesure.

Par où commencer chez vous ?

Vous avez la liste des 13 optimisations. Reste la vraie question : lesquelles pèsent sur votre boutique ? Cet auto-diagnostic part de votre configuration — hébergement, version de PrestaShop, symptômes observés — et vous renvoie vos priorités en deux minutes. C’est une estimation, pas une mesure, mais elle vous dit par où attaquer.

Questions fréquentes