Boutique PrestaShop lente : quoi mesurer avant de corriger ?

Une boutique « lente » recouvre trois plaintes différentes : une page qui tarde à s’afficher, un bouton qui tarde à répondre, un back-office qui traîne. Chacune a ses mesures et ses causes. Ce guide donne l’ordre dans lequel mesurer, les seuils que Google publie, et ce qu’un prestataire doit vous montrer avant et après son intervention.

Affichage, interaction ou back-office : nommer la lenteur

« Le site est lent » ne suffit pas à reproduire un problème : notez la page, l’action et le moment. Ouverture d’une catégorie, recherche d’un produit, ajout au panier, enregistrement d’une commande : chaque cas oriente vers une piste différente. Précisez l’appareil, mobile ou ordinateur, et si la lenteur est permanente ou liée à certaines heures.

Une page peut s’afficher vite et réagir lentement à un clic. Inversement, une image volumineuse retarde l’affichage sans expliquer un calcul de livraison trop long.

Le back-office se traite à part. Vos clients ne le voient pas, mais votre équipe y passe ses journées : notez l’écran concerné, liste des commandes ou fiche produit, et l’action qui tarde.

Les seuils de Google, lus à la source

Google publie trois mesures de l’expérience sur une page, les Core Web Vitals, avec un seuil pour chacune : 2,5 secondes pour l’affichage, 200 millisecondes pour la réaction à une action, 0,1 pour la stabilité de la mise en page. Une quatrième mesure, le temps de réponse du serveur, sert au diagnostic.

Ces seuils ne s’appliquent pas à un chargement isolé. Google les évalue au 75e centile : une page est jugée bonne quand les trois quarts de ses chargements atteignent l’objectif, sur mobile d’un côté et sur ordinateur de l’autre.

Le temps de réponse du serveur n’est pas un Core Web Vital. On lit souvent qu’il doit rester sous 200 millisecondes : la référence de Google, web.dev, indique 0,8 seconde, et précise qu’un site n’a pas à atteindre ce seuil s’il obtient de bons résultats sur les trois mesures principales.

Données réelles ou test de laboratoire ?

Un test lancé depuis un outil simule une visite ; les données réelles décrivent ce que vos clients ont vécu. Lisez d’abord les données réelles, et servez-vous du test pour chercher la cause.

PageSpeed Insights, l’outil gratuit de Google, affiche les deux pour une adresse donnée. Les données réelles proviennent des utilisateurs de Chrome sur les 28 derniers jours. Le test de laboratoire charge la page dans des conditions fixes : sur mobile, un téléphone de milieu de gamme et un réseau mobile simulés. Google le juge utile pour déboguer, et prévient qu’il peut ne pas refléter les blocages réels.

Une boutique peu visitée n’a pas toujours assez de données réelles. PageSpeed Insights se rabat alors sur l’ensemble du site, ou n’affiche que le test de laboratoire. Dans ce cas, répétez ce test sur les mêmes pages : un passage isolé ne prouve rien.

La Search Console complète le relevé. Son rapport Core Web Vitals s’appuie lui aussi sur des données d’utilisation réelles et classe vos pages, par groupes d’adresses similaires, en « Médiocre », « Amélioration nécessaire » ou « Bon », sur mobile et sur ordinateur.

Si les trois mesures sont bonnes sur les données réelles, la lenteur dont on se plaint est ailleurs : une action précise, le back-office, ou l’appareil de la personne qui la signale. Le score sur 100 de l’outil reste un indicateur ; il ne remplace pas l’examen des parcours qui comptent pour votre commerce.

Trouver ce qui ralentit : l’outil de debug de PrestaShop

Quand le serveur répond lentement, PrestaShop sait montrer où le temps passe : son outil de debug affiche, sous chaque page, des informations de performance.

Sur PrestaShop 9.2, il s’active depuis le menu Paramètres avancés › Performances, panneau « Mode debug », option « Outil de debug ». La documentation de PrestaShop demande de laisser ce profileur désactivé en production : faites le relevé sur une copie de la boutique.

Cherchez-y d’abord ce que la documentation de PrestaShop recommande de contrôler : les modules. Certains ralentissent la boutique, surtout lorsqu’ils sont branchés sur les pages essentielles du site, et elle conseille de les mesurer un par un. Elle cite quatre défauts : une consommation excessive de ressources, l’absence de cache, l’excès de cache et un module actif sur trop de pages.

Avant ce relevé, vérifiez sur le même écran les deux réglages que la documentation attend d’une boutique en production : le cache de Smarty, le moteur de gabarits de PrestaShop, est activé, et le mode debug est désactivé. Si le relevé désigne un empilement de modules, la question devient celle du module standard ou sur mesure.

Corriger une chose à la fois, puis remesurer

Changer l’hébergement, activer plusieurs caches et retirer des modules le même jour empêche de savoir ce qui a servi. Établissez un état initial, puis ne changez qu’une chose avant de mesurer à nouveau.

Gardez les mêmes pages d’un relevé à l’autre : l’accueil, une catégorie, une fiche produit et le panier couvrent l’essentiel d’un parcours d’achat. Gardez aussi le même outil et le même appareil simulé, sans quoi deux chiffres ne se comparent pas.

Les pistes à examiner sont connues : médias, scripts, traitements de modules, requêtes, appels à des services externes. L’ordre dans lequel les traiter vient de vos relevés, pas d’une liste universelle de réglages.

Ce qu’un prestataire doit vous montrer

Avant l’intervention, un relevé des mesures sur des pages nommées ; après, le même relevé. Sans ce couple, une amélioration ne se démontre pas. Demandez que le compte rendu contienne :

• les pages et les parcours mesurés, sur mobile et sur ordinateur
• l’outil utilisé, et la nature des chiffres : données réelles ou test de laboratoire
• les valeurs avant l’intervention
• chaque changement effectué, avec sa date
• les valeurs après, relevées dans les mêmes conditions

Les données réelles de Google portent sur 28 jours : l’effet complet d’une correction n’y apparaît qu’au bout de ce délai. Une amélioration technique se démontre bien avant, et sans conclure à une hausse des ventes, qui dépend aussi du trafic, des campagnes et de la saison.

Prévoyez enfin un suivi : un nouveau module, une campagne ou la croissance du catalogue modifient le comportement d’une boutique après l’optimisation. Notre prestation d’optimisation des performances PrestaShop suit cette logique : mesurer, trouver la cause, corriger, mesurer à nouveau.

Questions fréquentes