Un client se plaint que « le site est lent », mais sans méthode un audit performance PrestaShop part dans tous les sens. Voici un processus reproductible en 6 étapes — du diagnostic chiffré jusqu'au plan d'action priorisé — pour livrer un audit qui tient la route face au client comme face à Google.
Pourquoi une méthode plutôt qu'une liste d'astuces
La plupart des audits performance échouent pour la même raison : ils empilent des optimisations sans jamais mesurer l'impact réel. On active un cache, on minifie du CSS, on installe un module « speed » — et trois jours plus tard le client ne voit aucune différence sur son ressenti ni sur ses Core Web Vitals.
Un audit sérieux suit un cycle simple : mesurer → hiérarchiser → corriger → re-mesurer. L'objectif n'est pas de tout optimiser, mais d'identifier les 2-3 goulets d'étranglement qui pèsent réellement, puis de prouver le gain par des chiffres avant/après.
Étape 1 — Définir le périmètre et les pages témoins
Auditer « le site » entier n'a pas de sens : une boutique PrestaShop a des typologies de pages très différentes. Sélectionnez un échantillon représentatif et figez-le pour toute la durée de l'audit.
- Page d'accueil : souvent la plus lourde (sliders, modules, blocs dynamiques)
- Fiche produit : la page qui convertit, prioritaire pour le LCP
- Page catégorie avec facettes : pagination et filtres, lourde en SQL
- Tunnel de commande : non cachable, révèle la vraie perf PHP/SQL
Notez l'URL exacte de chaque page témoin. Toutes les mesures avant/après devront porter sur ces mêmes URLs, sinon la comparaison ne vaut rien.
Étape 2 — Mesurer l'existant (le baseline)
Aucune optimisation ne commence avant d'avoir un baseline chiffré. On distingue deux familles de mesures complémentaires : les données lab (synthétiques, reproductibles) et les données field (vrais utilisateurs).
Données lab
- Lighthouse (mode incognito, throttling mobile) : score global et détail LCP / CLS / TBT
- WebPageTest : waterfall complet, TTFB, Start Render — indispensable pour comprendre où le temps part
- Chrome DevTools → Performance : long tasks JS, layout shifts
Données field
Le lab ment parfois : un serveur peu chargé au moment du test masque un TTFB réel élevé en heure de pointe. Récupérez les données terrain :
- Google Search Console → Core Web Vitals : la source qui compte pour le ranking
- CrUX (Chrome User Experience Report) : p75 réel sur 28 jours
Automatisez la capture du TTFB sur vos pages témoins pour pouvoir comparer objectivement :
# Mesure TTFB sur les pages témoins
for url in \
"https://boutique.com/" \
"https://boutique.com/categorie/12-chaussures" \
"https://boutique.com/produit/45-sneaker.html"; do
echo "=== $url ==="
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s | Total: %{time_total}s\n" "$url"
done
Consignez tout dans un tableau baseline. C'est ce document qui justifiera vos recommandations et prouvera le gain final.
Étape 3 — Profiler le back-end PrestaShop
Sur PrestaShop, l'essentiel du temps « invisible » se joue côté serveur : PHP, SQL et cache. Le profiler natif est votre meilleur allié.
Activer le Debug Profiling
Dans config/defines.inc.php sur un environnement de pré-production (jamais en prod) :
<?php
define('_PS_DEBUG_PROFILING_', true);
Chaque page affiche alors le temps de chargement, le nombre de requêtes SQL, les requêtes les plus lentes et la consommation mémoire. Repérez immédiatement :
- Un nombre de requêtes SQL anormal (> 200 sur une fiche produit = problème N+1)
- Les requêtes lentes (souvent dans des modules tiers ou des overrides)
- Les hooks qui consomment le plus de temps d'exécution
Isoler un hook ou un override coûteux
Quand le profiler pointe un hook lent, mesurez-le précisément avec le Stopwatch de Symfony plutôt que de deviner :
<?php
declare(strict_types=1);
use Symfony\Component\Stopwatch\Stopwatch;
final class PerformanceProbe
{
private Stopwatch $stopwatch;
public function __construct()
{
$this->stopwatch = new Stopwatch();
}
/**
* Mesure la durée d'un callable et log si le seuil est dépassé.
*
* @param callable $callback Le traitement à profiler
* @param int $thresholdMs Seuil d'alerte en millisecondes
*/
public function measure(string $label, callable $callback, int $thresholdMs = 100): mixed
{
$this->stopwatch->start($label);
$result = $callback();
$event = $this->stopwatch->stop($label);
if ($event->getDuration() > $thresholdMs) {
PrestaShopLogger::addLog(
sprintf('%s lent : %dms', $label, $event->getDuration()),
2
);
}
return $result;
}
}
Étape 4 — Auditer le front-end et les Core Web Vitals
Une fois le serveur profilé, attaquez le rendu navigateur. Trois métriques structurent l'analyse, chacune avec ses causes typiques sur PrestaShop.
LCP — Largest Contentful Paint
Sur une fiche produit, le LCP est presque toujours l'image principale. Causes fréquentes :
- Image produit non dimensionnée ou servie en trop grand format
- Absence de
fetchpriority="high"sur l'image LCP - Lazy loading appliqué par erreur à l'image au-dessus de la ligne de flottaison
CLS — Cumulative Layout Shift
- Images sans attributs
width/height - Bannières de cookies ou modules injectés après le chargement
- Web fonts qui provoquent un FOUT sans
font-display: swap
INP — Interaction to Next Paint
Remplace le FID depuis 2024. Sur PrestaShop, l'INP souffre surtout du JavaScript des modules tiers et de jQuery chargé en bloc. Identifiez les long tasks dans l'onglet Performance, puis différez ce qui n'est pas critique :
<!-- Scripts non critiques : defer pour ne pas bloquer le rendu -->
<script src="/modules/monmodule/views/js/widget.js" defer></script>
<!-- Tracking : chargement après interaction ou idle -->
<script>
window.addEventListener('load', () => {
requestIdleCallback(() => loadAnalytics());
});
</script>
Étape 5 — Hiérarchiser : la matrice impact / effort
C'est l'étape qui distingue un audit professionnel d'une simple liste. Chaque problème détecté est classé selon deux axes : son impact sur la performance perçue et l'effort de correction.
- Impact fort / effort faible → quick wins, à faire en premier (ex : activer OPcache, ajouter
fetchpriority) - Impact fort / effort élevé → chantiers planifiés (ex : refonte d'un module N+1, cache HTTP Nginx)
- Impact faible / effort faible → à faire si le temps le permet
- Impact faible / effort élevé → à écarter, c'est de la sur-ingénierie
Pour chaque ligne, chiffrez le gain attendu en vous appuyant sur le baseline : « corriger les 180 requêtes SQL de la fiche produit → TTFB estimé de 1,2 s à 0,3 s ». Un client signe un plan d'action chiffré, pas une intention.
Étape 6 — Corriger, re-mesurer, documenter
Appliquez les optimisations une par une, ou par lot cohérent, et re-mesurez après chaque lot sur les mêmes pages témoins. Cette discipline a deux vertus : elle prouve le gain réel et elle isole une éventuelle régression.
Reprenez votre tableau baseline et ajoutez une colonne « après » :
- TTFB fiche produit : 1 240 ms → 280 ms
- LCP mobile (field p75) : 4,1 s → 2,2 s
- Requêtes SQL fiche produit : 187 → 42
- Score Lighthouse mobile : 38 → 82
Ce delta chiffré est le livrable qui a de la valeur. Les CWV terrain (Search Console, CrUX) mettent ~28 jours à refléter les changements : prévenez le client que le ranking suivra avec ce décalage.
Checklist d'audit performance PrestaShop
- Périmètre : 4 pages témoins figées (accueil, produit, catégorie, tunnel)
- Baseline : mesures lab (Lighthouse, WebPageTest) + field (Search Console, CrUX)
- Back-end : profiler PrestaShop activé, requêtes SQL et hooks lents identifiés
- Front-end : LCP, CLS et INP analysés avec leurs causes
- Priorisation : matrice impact/effort avec gain chiffré par item
- Validation : re-mesure sur les pages témoins, tableau avant/après
- Hygiène : profiling et debug désactivés en production
Conclusion
Un audit performance PrestaShop n'est pas une affaire de talent mais de méthode : un périmètre clair, un baseline chiffré, un profiling sérieux, une priorisation par impact/effort, puis une re-mesure qui prouve le gain. C'est ce cadre qui transforme une plainte floue (« le site est lent ») en un plan d'action défendable et en CWV qui passent au vert. Les leviers techniques — TTFB, LCP, lazy loading — viennent ensuite, une fois que vous savez précisément où agir.
Besoin d'un audit performance complet sur votre boutique PrestaShop ? Contactez-moi pour en discuter !
