PrestaShop lent : diagnostiquer PageSpeed avant de lancer une refonte

Un score PageSpeed rouge ne prouve pas qu’il faut changer de plateforme. Il prouve qu’il faut diagnostiquer. La lenteur peut venir du serveur, du thème, des images, des scripts marketing, des modules ou d’une combinaison.

La mauvaise réponse est une refonte lancée sur un seul test de page d’accueil.

Mesurez le terrain et le laboratoire

Les données de laboratoire reproduisent un scénario contrôlé. Les données terrain décrivent l’expérience réelle des visiteurs. Utilisez les deux.

Suivez les Core Web Vitals :

• LCP : vitesse d’affichage du contenu principal ;
• INP : réactivité après interaction ;
• CLS : stabilité visuelle.

Ajoutez TTFB, poids de page, nombre de requêtes, erreurs JavaScript et temps des API critiques.

Testez les pages qui vendent

Créez un panel :

1. accueil ;
2. catégorie lourde ;
3. fiche simple ;
4. fiche avec beaucoup de variantes ;
5. recherche ;
6. panier ;
7. checkout ;
8. page éditoriale.

Testez mobile et desktop, connecté et non connecté si nécessaire. Une moyenne globale peut cacher un checkout lent ou une famille produit défaillante.

Isolez la couche responsable

Serveur

Regardez le TTFB, la charge, les requêtes SQL lentes, le cache et les appels externes. Si le HTML arrive tard, optimiser uniquement les images ne suffira pas.

Front-end

Mesurez JavaScript, CSS, polices, images et décalages de mise en page. Identifiez les bundles et composants qui bloquent l’affichage.

Scripts tiers

Tag manager, chat, avis, personnalisation, publicité et A/B testing peuvent représenter une part majeure du coût. Chaque script doit avoir un propriétaire et une valeur mesurée.

Catalogue

Les filtres, variantes et règles de prix peuvent déclencher des traitements lourds. Testez les cas complexes, pas uniquement le produit de démonstration.

Modules

Désactivez sur un environnement de test, jamais directement en production. Comparez avant/après et documentez les dépendances.

Décider : corriger ou replatformer

Corrigez si les causes sont localisées, si l’équipe maîtrise le socle et si la roadmap reste compatible.

Comparez un changement de plateforme si :

• les lenteurs viennent de plusieurs couches non maîtrisées ;
• chaque optimisation casse une autre fonction ;
• le monitoring est absent ;
• les scripts et modules n’ont plus de propriétaire ;
• la prochaine montée de version impose déjà une refonte large.

Ce qu’on voit sur le terrain

La vitesse devient un argument commercial facile parce qu’elle produit un chiffre. Mais un score sans trafic, conversion ni type de page est une donnée incomplète.

Le bon diagnostic aboutit à une liste d’actions chiffrées : supprimer, différer, mettre en cache, réécrire, superviser ou migrer.

Reliez ce travail à l’audit en 37 contrôles et à la grille mise à jour ou migration.

Plan de test sur sept jours

• J1 : récupérer données terrain et analytics ;
• J2 : constituer le panel de pages ;
• J3 : mesurer serveur et front ;
• J4 : analyser scripts tiers ;
• J5 : tester modules et catalogue en préproduction ;
• J6 : estimer coûts et gains ;
• J7 : décider des actions et du monitoring.

FAQ

PageSpeed 100 est-il nécessaire ?

Non. Visez une expérience stable et rapide sur les pages commerciales, avec des métriques terrain satisfaisantes.

Un CDN règle-t-il tout ?

Il accélère certains contenus et rapproche la distribution, mais ne corrige pas un traitement serveur lent ou trop de JavaScript.

Faut-il changer de thème ?

Seulement si les mesures montrent qu’il contribue fortement au problème et si son remplacement coûte moins qu’une correction durable.

Combien de pages tester ?

Un panel de huit à douze pages représentatives est un bon départ, puis élargissez selon les anomalies.

Vous voulez savoir si votre lenteur justifie vraiment une refonte ? Réservez un diagnostic performance.