Optimiser la vitesse PrestaShop : guide complet pour accélérer votre boutique

Votre boutique PrestaShop met plus de trois secondes à charger. Vous le savez parce que vous l'ouvrez depuis votre téléphone, et vous attendez. Vos clients aussi attendent. Sauf qu'eux, ils partent : au-delà de trois secondes, plus de la moitié des visiteurs mobiles abandonnent.

Vous vous reconnaîtrez probablement dans un de ces cas :

• Le back-office met dix secondes à ouvrir une commande, et vous avez pris l'habitude de faire autre chose pendant le chargement.
• Les fiches produits et les pages catégories rament sur mobile, alors que la page d'accueil passe correctement.
• Tout allait bien il y a un an. Rien n'a changé, sauf les quelques modules installés depuis.
• Votre trafic organique baisse sans raison apparente, et vous avez déjà retravaillé vos fiches produits.

Le problème, c'est rarement PrestaShop en lui-même. C'est ce qu'on a empilé dessus. Et la bonne nouvelle, c'est qu'une bonne partie de ce qui ralentit votre boutique se corrige depuis votre back-office, sans écrire une ligne de code.

Ce guide va du plus simple au plus lourd : vous identifiez d'abord votre symptôme, vous appliquez ce que vous pouvez faire seul, et vous saurez exactement à quel moment il faut passer la main.

D'où vient la lenteur de votre boutique : le diagnostic

Autonome

Avant de toucher quoi que ce soit, il faut mesurer. Optimiser sans diagnostic, c'est chercher une fuite sans savoir où elle se trouve. Commencez par situer votre symptôme :

Les outils du diagnostic front-office

Je travaille sous Firefox : l'inspecteur réseau fait tout le travail de fond, et PageSpeed Insights prend le relais quand j'ai besoin de l'audit Lighthouse et des données de terrain. Si vous êtes sous Chrome, vous avez Lighthouse directement dans les DevTools.

Dans l'inspecteur réseau, lisez toujours dans le même ordre :

1. Le TTFB sur la requête du document. C'est le temps que met le serveur à répondre. Il conditionne tout le reste.
2. La taille des ressources, et en particulier le JavaScript. Triez par poids décroissant.
3. L'origine de ces ressources. C'est l'étape que personne ne fait, et c'est la plus rentable. Pour chaque gros fichier, posez-vous une seule question : pourquoi est-il chargé sur cette page ?

Dans neuf cas sur dix, la réponse est un module tiers. Un exemple que je rencontre souvent : le module Boxtal, utile uniquement sur la page de commande au moment de choisir le transporteur, charge son SDK JavaScript très lourd sur toutes les pages du front. Votre visiteur télécharge un outil de transporteur pour consulter votre page d'accueil.

Ce genre de découverte est plutôt simple : l'inspecteur vous donne le nom du module coupable. En revanche, restreindre son chargement à la seule page concernée demande un filtre fin dans le code, et là il faut des compétences techniques.

Les seuils qui doivent vous alerter

Sur PrestaShop, le TTFB se lit avec des repères propres à la plateforme :

• 200 à 300 ms : excellent. En pratique, ce niveau n'est atteignable qu'avec Varnish.
• 600 à 800 ms : encore correct. Rien d'alarmant sur une boutique en production.
• Plus d'1 seconde : anormal. Il y a un problème côté serveur, cache ou base de données.

Les trois autres métriques à surveiller, côté visiteur :

• LCP (Largest Contentful Paint) : le temps d'affichage du plus grand élément visible. Google recommande moins de 2,5 secondes.
• INP (Interaction to Next Paint) : la réactivité aux clics. Seuil recommandé, 200 ms maximum.
• CLS (Cumulative Layout Shift) : la stabilité visuelle pendant le chargement.

Back-office lent : le mode debug

Technique

Pour le back-office, le diagnostic passe par le mode debug de PrestaShop, qui expose le profileur Symfony. À ne jamais activer en production, même rapidement : uniquement sur un serveur de staging, ou en local.

Deux choses à regarder, dans cet ordre :

1. Le taux de cache hit. Il doit dépasser 90 %. Ce n'est pas toujours le cas, et en dessous, le problème est un serveur mal réglé, typiquement OPcache absent ou mal dimensionné.
2. Le nombre de requêtes SQL. Il est souvent très élevé sur certaines pages, et c'est normal : une page de commande ou la page des modules génèrent beaucoup de requêtes. Ce qui compte, c'est qu'il chute au second chargement de la page. S'il reste identique, le cache ne fait pas son travail.

C'est ce second point qui trompe le plus de monde : on regarde un nombre de requêtes énorme et on conclut à une base mal conçue, alors que le vrai défaut est un cache inopérant.

Bots malveillants : la cause qu'on ne soupçonne pas toujours

Technique

Avant d'optimiser quoi que ce soit, écartez ce cas. Je l'ai rencontré au moins cinq fois, et il est systématiquement diagnostiqué à côté : la boutique devient subitement très lente, sans rapport avec votre trafic réel. On accuse l'hébergeur, on ajoute du cache, on compresse les images. Rien n'y fait, parce que le problème n'est pas la boutique, c'est ce qu'on lui envoie.

Des bots parcourent massivement votre front-office et saturent le serveur. Leur cible favorite est le module ps_facetedsearch, la navigation à facettes : il accepte de concaténer les paramètres dans l'URL, et chaque combinaison produit une requête SQL complexe. Multipliez par des milliers d'appels par minute, et MySQL s'effondre.

La signature ne trompe pas. En SSH, htop ou top montrent le processeur saturé par mysqld. Si vous voyez ça, vous y êtes quasiment à coup sûr. Confirmez avec les logs d'accès, souvent access.log, en tail -f : vous verrez défiler des URLs de navigation à facettes avec des chaînes de paramètres à rallonge.

Sur le blocage, ne comptez pas sur le Bot Fight Mode de Cloudflare seul : c'est un bon début, mais il ne suffit pratiquement jamais. Il faut presque toujours écrire des règles de filtrage plus fines derrière. Et si vous n'expédiez aucune commande dans un pays, bloquez-le entièrement : dans tous les cas que j'ai traités, le spam venait de Chine ou du Brésil.

C'est le seul cas de ce guide où optimiser la boutique ne sert à rien. Le filtrage se fait avant PrestaShop, et il demande un accès serveur.

Cache PrestaShop : le réglage le plus rentable

Autonome

Ces trois réglages sont le plus souvent déjà corrects sur une boutique en production. Vérifiez-les quand même, ça prend deux minutes : sur un site repris à une agence, la compilation des templates est parfois restée en mode développement, et c'est une perte sèche.

Optimiser les images de votre boutique

Autonome

Vous n'avez pas à redimensionner vos images avant de les téléverser : PrestaShop gère déjà cela. Il génère automatiquement les déclinaisons dont votre thème a besoin, aux dimensions définies par ses types d'images.

Le vrai levier est donc le WebP, généré nativement par PrestaShop 8 et 9. Le reste relève de la vérification : des types d'images surdimensionnés par rapport à ce que le thème affiche réellement, ou une qualité laissée à 90 alors que 80 ne se voit pas.

Le lazy loading, lui, n'est pas votre travail. Tout thème moderne et correctement conçu le gère, Hummingbird compris. S'il ne le fait pas, il faut intervenir dans le thème, ce qui est plus technique.

Nettoyer la base de données PrestaShop

Autonome

Une base jamais purgée finit par peser plusieurs gigaoctets, en accumulant des années de logs, de sessions visiteurs et de paniers abandonnés. Les ralentissements ne sont qu'une conséquence possible parmi d'autres : les sauvegardes deviennent lourdes à produire comme à restaurer, et vous pouvez finir par atteindre les limites imposées par votre hébergeur. Je l'ai déjà vu arriver.

Attention à ne pas confondre nettoyage et suppression aveugle : ps_cart contient aussi les paniers rattachés à des commandes réelles. Filtrez sur les paniers sans commande associée, et gardez les données de l'année en cours.

Plus d'information sur la documentation officielle

Les tables de la navigation à facettes sont un cas à part. J'ai déjà vu ps_layered_filter_block, qui met en cache les blocs de filtres, atteindre plusieurs gigaoctets ; ps_layered_price_index peut grossir aussi. Et ça ne se règle pas en purgeant à la main : la page de configuration du module ps_facetedsearch expose les tâches cron d'indexation. C'est là qu'il faut les mettre en place, pour que ces tables se reconstruisent proprement au lieu de gonfler indéfiniment.

Automatiser le nettoyage

Ce ménage tous les six mois, en pratique, personne ne le fait. C'est pour ça que j'ai développé awdbcleaner, un module open-source qui purge la base automatiquement via une tâche cron en CLI. Le README détaille l'installation et la configuration.

Un article dédié suivra prochainement.

Modules PrestaShop : le vrai coupable des ralentissements

Technique

Chaque module ajoute du code PHP, des requêtes SQL, du CSS et du JavaScript. Un seul module PrestaShop mal conçu suffit à annuler toutes les autres optimisations, et c'est le poste où je trouve le plus de marge en audit.

Vous pouvez identifier les coupables seul, avec l'inspecteur réseau. Ce qui demande un développeur, c'est la suite : conditionner le chargement d'un module à la seule page où il sert, sans casser sa mise à jour. C'est un travail de filtre sur les hooks, et c'est exactement le genre d'intervention qui transforme un diagnostic en gain réel.

Vous avez trouvé le module coupable mais pas la solution ? Parlons-en.

Thème PrestaShop et performance front-end

Technique

Un thème surchargé de scripts, d'animations et de polices web plombe le score mobile, même sur un bon hébergement.

Partir du thème Hummingbird donne un socle technique propre. C'est la bonne base pour un thème sur mesure performant, qu'on personnalise ensuite sans sacrifier la vitesse.

Et comme à peine la moitié des sites passe l'évaluation Core Web Vitals, y arriver reste un avantage concurrentiel concret plutôt qu'une simple case à cocher.

Hébergement PrestaShop : la limite structurelle

Accompagné

Si vous avez appliqué tout ce qui précède et que votre TTFB reste au-dessus d'une seconde, vous avez atteint la limite de votre hébergement. Aucune optimisation front ne rattrape un serveur qui met plusieurs secondes à générer le HTML.

C'est le plus gros gain restant, mais ce n'est plus un réglage : c'est une migration, avec une bascule DNS, une remise en place du cache et des tests. Le choix d'un hébergement adapté à PrestaShop se prépare, et c'est typiquement le moment de se faire accompagner.

C'est aussi à ce stade que je travaille en local avec DDEV : une copie complète et exacte de la production, avec les URLs réécrites, le var/cache vidé et le .htaccess rechargé. Ça permet de tout tester indépendamment du serveur, sans jamais risquer de toucher à la boutique en ligne.

5 erreurs fréquentes qui plombent la vitesse de votre PrestaShop

Après des dizaines d'audits sur des boutiques en production, voici les cinq erreurs que je retrouve le plus souvent.

Par où commencer : le plan selon votre TTFB

Mesurez d'abord. Tout le reste découle de ce chiffre, et suivre la mauvaise branche revient à repeindre une façade posée sur des fondations fissurées.

Mesurez après chaque étape, pas seulement à la fin : c'est le seul moyen de quantifier le gain et de repérer un effet de bord avant qu'il n'arrive en production.

Ce que la lenteur vous coûte vraiment

Depuis 2021, Google intègre les Core Web Vitals dans ses critères de classement. Un site lent est donc doublement pénalisé : il convertit moins, et il est moins visible. C'est ce qui rend l'arbitrage simple : sur une année, le manque à gagner dépasse presque toujours le coût de l'intervention.

Votre boutique freine votre croissance ? Discutons de votre projet.

Vos questions les plus fréquentes sur l'optimisation de la vitesse PrestaShop

Quel score PageSpeed viser pour PrestaShop ?

Sur mobile, visez un score supérieur à 70. Atteindre 100 est quasiment impossible avec une boutique PrestaShop en production, à cause des scripts tiers et des modules nécessaires. Ce qui compte vraiment, ce sont les Core Web Vitals en données de terrain. Un score de 75 avec un LCP sous 2,5 secondes vaut mieux qu'un 90 obtenu sur une page quasi vide.

Faut-il installer un module de cache PrestaShop ?

Je le déconseille. Ces modules paraissent séduisants parce qu'ils promettent un gain sans configuration serveur, mais ils embarquent presque toujours de lourds overrides qui compliquent les mises à jour, pour un gain faible. Réglez d'abord le cache natif et le serveur : une boutique correctement optimisée n'a pas besoin de ce type de module. Si vous avez réellement besoin d'un cache de page complète, la bonne réponse est Varnish, Redis ou encore Memcached.

Combien coûte une optimisation de performance PrestaShop ?

Cela dépend de l'état de la boutique. Un audit de performance suivi d'optimisations ciblées (cache, images, base de données, modules) représente généralement entre 1 000 et 3 000 euros. Pour des interventions plus lourdes impliquant un changement d'hébergement ou une refonte du thème, le budget monte en conséquence. L'investissement est rentabilisé rapidement par le gain en conversion.

La migration vers PrestaShop 8 ou 9 améliore-t-elle la vitesse ?

Oui, à condition de ne pas migrer à l'identique les anciens modules et l'ancien thème. Le gain vient du support de PHP 8.x, des optimisations Symfony et du thème Hummingbird. Migrer en conservant un thème obsolète et des modules incompatibles risque de produire l'effet inverse. La migration doit être pensée comme une remise à plat technique.

Peut-on optimiser la vitesse du back-office PrestaShop ?

Le back-office lent est un problème très courant, souvent lié à une base de données saturée et à des modules d'administration gourmands. Le nettoyage des tables ps_log, ps_connections et ps_cart, combiné à la désactivation des modules de statistiques internes, suffit généralement à rendre le back-office réactif.

En résumé