Analyse de la performance d'un site web sous PrestaShop

L'analyse de la performance d'un site web sous PrestaShop commence par trois mesures : le temps de chargement, la réactivité de la page quand le client agit et la stabilité de l'affichage. Ce guide présente les indicateurs à suivre, la lecture des tâches longues et des recalculs de style, puis la validation des corrections côté PHP, SQL et hébergement.

Quels indicateurs mesurer sur une boutique PrestaShop ?

Les principaux indicateurs mesurent trois aspects de l'expérience utilisateur : la vitesse d'affichage, la réponse aux actions et la stabilité de la page. Chaque indicateur a ses propres seuils. Il faut aussi savoir d'où viennent les données : de vrais visiteurs ou d'un test en laboratoire.

Chargement, réactivité et stabilité visuelle

Le LCP mesure le temps d'affichage du plus grand élément visible, souvent l'image principale d'une fiche produit. Le FCP mesure le moment où le premier contenu apparaît. Le TTFB mesure le délai avant le premier octet envoyé par le serveur : PageSpeed Insights considère qu'il est bon jusqu'à 800 ms.

L'INP mesure la réactivité à chaque interaction, pendant toute la durée de vie de la page. Le CLS mesure les déplacements inattendus du contenu. Ces trois Core Web Vitals s'évaluent au 75e percentile, séparément sur mobile et sur ordinateur. En complément, le TBT mesure en laboratoire le blocage causé par les tâches longues, mais il ne remplace pas l'INP mesuré chez les visiteurs.

Données réelles et outils de diagnostic

PageSpeed Insights présente côte à côte les données réelles de CrUX, collectées auprès des visiteurs Chrome, et les mesures de laboratoire de Lighthouse. Une mesure de laboratoire sert à reproduire un problème. Elle ne décrit pas l'expérience de tous les visiteurs. Les données CrUX portent sur une fenêtre glissante de 28 jours, et leur API historique fournit des relevés hebdomadaires sur les 40 dernières périodes.

Une fois le problème repéré dans ces outils d'analyse, les outils de développement du navigateur permettent d'en trouver la cause : traces CPU, requêtes réseau, DOM et styles. Leur panneau de surveillance affiche aussi la mémoire JavaScript, le nombre de nœuds DOM, les mises en page et les recalculs de style.

Périmètre d'un audit comparable

Un audit de boutique porte sur les parcours qui comptent pour la vente : accueil, catégorie, recherche, fiche produit, panier et paiement, ainsi que les pages de contenu ou de compte client si le diagnostic en a besoin. Pour comparer deux mesures dans le temps, notez à chaque fois les conditions de test suivantes :

• Page et parcours : l'URL testée et le scénario reproduit.
• Environnement : la version de PrestaShop, l'appareil et le réseau.
• État du cache : le cache est-il déjà rempli ou vient-il d'être vidé ?
• Contexte client : client connecté ou non, et nombre de produits affichés.

L'audit technique de Prestashop France by Studio Web Design contrôle les modules, les serveurs, les redirections, les images et la vitesse. Son audit SEO de boutique PrestaShop examine aussi la vitesse de chargement et établit un plan d'action adapté à la boutique. Ce travail peut se prolonger avec l'accompagnement en référencement naturel PrestaShop.

Comment repérer les tâches longues du fil principal ?

Le fil principal du navigateur exécute le JavaScript, calcule les styles et dessine la page. Quand une seule tâche l'occupe trop longtemps, la page ne réagit plus aux clics. Repérer ces tâches longues est donc la première étape pour améliorer la réactivité d'une boutique.

Reconnaître un blocage pendant une interaction

Une tâche est dite longue dès qu'elle occupe le fil principal pendant au moins 50 ms. Toute la durée au-delà de 50 ms compte comme temps bloquant. À 60 Hz, le navigateur dispose d'environ 16,7 ms pour afficher chaque image : au-delà, l'affichage peut saccader. Sur une boutique, reproduisez en priorité ces actions :

• Le changement de déclinaison sur une fiche produit.
• L'utilisation des filtres d'une page catégorie.
• L'ajout au panier et la recherche.

Pendant une tâche longue, le navigateur peut retarder la réponse à une action du client. C'est pourquoi le diagnostic doit porter sur l'interaction lente elle-même : un simple test de chargement de la page ne révèle pas ces blocages.

Lire une trace dans le panneau Performance

Une fois l'interaction reproduite, enregistrez une trace dans le panneau Performance du navigateur, puis isolez la tâche longue. La vue ascendante et l'arbre des appels montrent alors les fonctions qui prennent le plus de temps. Avant d'accuser le thème ou un module, séparez dans la trace le temps passé dans les scripts du temps passé à calculer les styles, à mettre en page et à peindre.

L'API des images d'animation longues (Long Animation Frames) complète cette lecture : elle indique quels scripts sont liés à une image dont le rendu dépasse 50 ms. Elle révèle ainsi des blocages que la seule liste des tâches longues explique mal.

Relier le coût aux scripts exécutés

Un script qui parcourt plusieurs fois une liste de produits, change des classes et provoque des recalculs de style peut bloquer le fil principal. La taille du fichier JavaScript ne suffit donc pas à juger ce coût. La méthode `querySelectorAll()`, qui renvoie une liste fixe des éléments trouvés, coûte selon le nombre d'appels, la zone de la page interrogée, le nombre d'éléments et son usage dans une boucle.

Quand la trace montre que le temps est perdu dans le navigateur, cherchez la cause dans le script ou le rendu concerné. Si elle montre au contraire une attente de réponse du serveur, il faut examiner les autres couches de la boutique.

Produits recommandés

Audit SEO PrestaShop | Analyse Complète de Votre Boutique E-commerce

36,00 € 66,00 €

Comment diagnostiquer les recalculs de style coûteux ?

Un recalcul de style se produit quand le navigateur doit revoir quelles règles CSS s'appliquent aux éléments de la page. Ces événements apparaissent dans la trace sous le nom « Recalculate Style ». Pour analyser les performances CSS, il faut d'abord savoir ce qui les déclenche, puis quels sélecteurs coûtent le plus.

Repérer ce qui déclenche les recalculs

Un recalcul peut être déclenché par l'ajout ou le retrait d'un élément, par un changement de classe ou d'identifiant, ou par une interaction qui modifie un état comme `:hover`. Le navigateur cherche alors les règles applicables, puis calcule les styles qui en résultent. Si ce travail dure longtemps, il peut dégrader l'INP. Quand une liste de produits est modifiée plusieurs fois de suite, la trace permet de vérifier si ce sont ces recalculs, et non le chargement du CSS, qui ralentissent l'interaction.

Examiner les statistiques des sélecteurs

Chrome DevTools permet d'activer les statistiques de sélecteurs au moment d'enregistrer une trace de performance. Pour chaque sélecteur, elles indiquent le temps écoulé en millisecondes, le nombre de tentatives de correspondance, les correspondances trouvées, les échecs passés par le « chemin lent » et la feuille de style d'origine.

Examinez en priorité les sélecteurs qui prennent beaucoup de temps, ceux qui sont testés très souvent, ceux qui correspondent rarement à un élément et ceux qui cumulent beaucoup d'échecs sur le chemin lent. Un sélecteur long n'est pas pour autant un problème : seuls ces chiffres montrent son coût réel.

Corriger le coût CSS mesuré

Une fois les règles coûteuses identifiées, la correction suit un ordre précis : retirer les règles inutiles, limiter les relations entre éléments du DOM et les modifications répétées, puis mesurer l'effet d'une simplification des sélecteurs.

Quand la structure du thème le permet, un sélecteur simple peut remplacer une longue chaîne de descendants. Cette simplification facilite la maintenance, mais son gain de performance doit être vérifié dans les recalculs.

Minifier une feuille CSS réduit le poids du fichier téléchargé, mais ne supprime pas les recalculs déclenchés par les modifications du DOM. Ce sont deux problèmes différents : une feuille volumineuse ou bloquante peut retarder l'affichage et le LCP, même si les recalculs sont rapides.

Comment corriger et valider les gains de performance ?

Quand la lenteur ne vient pas du navigateur, le diagnostic passe au serveur. Il faut alors examiner les modules, le code PHP, les requêtes SQL, le cache, les tâches planifiées et l'hébergement. Chaque optimisation doit ensuite être validée par une nouvelle mesure, prise dans les mêmes conditions que la première.

Profiler les modules, PHP et SQL

Un problème de performance sur un site e-commerce peut venir d'un module branché sur un hook, c'est-à-dire un point d'accroche où PrestaShop exécute le code des modules. Prestashop France by Studio Web Design vérifie les modules installés pour repérer ceux qui sont obsolètes ou mal réglés. Quatre points sont à contrôler :

• Les modules : absence de cache, ou exécution sur trop de pages, y compris des pages critiques.
• Le code PHP : les fonctions les plus lentes, leur nombre d'appels et leur mémoire, mesurés avec un profileur ciblé.
• Les boucles : du travail répété inutilement à chaque tour, ou une requête lancée à chaque itération.
• Les requêtes SQL : leur fréquence, leur durée, les lignes examinées, les index et le plan donné par `EXPLAIN`.

La fréquence d'une requête compte autant que sa durée. Une requête SQL de 20 ms exécutée 1 000 fois de suite représente 20 s au total. Le temps d'une requête prise isolément ne permet donc pas de juger son vrai coût.

Contrôler le cache, les traitements et l'hébergement

Mesurez une même page dans trois situations : avec le cache déjà rempli, juste après une invalidation et avec un cache vide. Un cache efficace peut masquer un traitement lent qui ne s'exécute que lorsque le cache doit être reconstruit.

Les tâches planifiées (imports, indexations, génération de fichiers) peuvent aussi se chevaucher. Une tâche qui dure 8 min et se lance toutes les 5 min démarre avant la fin de la précédente si rien ne l'en empêche. Relevez la durée et la fréquence de chaque tâche pour décider s'il faut bloquer ces chevauchements ou traiter des lots plus petits.

Un test de charge montre comment PHP-FPM, la base SQL, le CPU et la mémoire réagissent quand le trafic simultané augmente. Sur ce point, la différence se joue sur la configuration serveur. Prestashop France by Studio Web Design propose un hébergement PrestaShop sur serveur dédié : les ressources y sont réservées à un seul client, contrairement à un hébergement mutualisé.

Comparer les mesures et vérifier la boutique

La documentation PrestaShop recommande de procéder en trois temps : une mesure de référence, une seule modification identifiable, puis une nouvelle mesure. En rejouant la même URL et le même scénario dans des conditions comparables, vous pouvez comparer les traces avant et après la correction.

Une préproduction, c'est-à-dire une copie de la boutique proche de la version en ligne, permet de profiler et de tester un correctif avant de le déployer. Vérifiez en priorité le panier, le paiement, l'administration et les imports ou exports.

Un gain visible tout de suite en laboratoire n'apparaît que progressivement dans les données de terrain, qui couvrent 28 jours. Après une correction CSS ou JavaScript, contrôlez aussi les autres pages, la navigation au clavier, la visibilité du focus et le bon fonctionnement des composants interactifs.