Audit de performance WooCommerce : ma méthode en 15 minutes

Quand je reçois une demande d’audit, je commence toujours par la même chose : 15 minutes d’analyse structurée qui me donnent une vision claire de l’état du site. Pas besoin d’accès admin pour cette première passe. Voici comment je procède. Cette méthode fait partie de mon service d’optimisation WooCommerce.

Minute 1-3 : les Core Web Vitals terrain

Je commence par les données réelles, pas les données de labo. Google met à disposition les métriques CrUX (Chrome User Experience Report) qui reflètent ce que vivent vos vrais visiteurs.

Outil : PageSpeed Insights

Je teste trois pages :

La homepage
Une page produit (la plus visitée si je la connais, sinon une au hasard)
La page catégorie principale

Ce qui m’intéresse en priorité :

LCP (Largest Contentful Paint) - Le temps avant que le contenu principal soit visible. Au-dessus de 2,5 secondes, il y a un problème. Sur un WooCommerce mal configuré, on voit régulièrement 4 à 6 secondes sur mobile.

INP (Interaction to Next Paint) - La réactivité aux clics. Au-dessus de 200ms, l’expérience est dégradée. Les scripts lourds (cart fragments, jQuery) sont souvent responsables.

CLS (Cumulative Layout Shift) - La stabilité visuelle. Les images sans dimensions et les polices qui se chargent tard font “sauter” la page.

Comme le rappelle le guide officiel de WooCommerce sur les Core Web Vitals (source : woocommerce.com), ces métriques influencent directement le référencement et les conversions.

Minute 3-7 : le waterfall de chargement

Outil : DevTools du navigateur (F12 → Network)

Je recharge une page produit et je regarde le waterfall. Ce qui m’alerte :

Nombre de requêtes. Plus de 80-100 requêtes sur une page produit, c’est trop. Chaque plugin ajoute ses fichiers CSS et JS - souvent sur toutes les pages, même quand ils ne servent pas.

Poids total. Au-dessus de 3 Mo sur mobile, c’est problématique. J’ai vu des boutiques à 8-10 Mo par page à cause de thèmes comme Elementor ou Divi qui chargent 200-400 Ko de leur propre framework.

admin-ajax.php et wc-ajax. Comme l’explique la documentation de WP Engine (source : wpengine.com), les requêtes admin-ajax sont non cacheables - chaque requête est traitée à neuf par PHP. Si je vois get_refreshed_fragments dans le waterfall, c’est que cart fragments est actif sur cette page. Sur un site à 10 000 visites/mois, ça représente ~300 000 requêtes serveur inutiles.

Scripts tiers. Google Analytics (gtag.js), Facebook Pixel, Hotjar - chacun ajoute 50-150 Ko. Si le site n’utilise pas Cloudflare Zaraz ou un équivalent server-side, ces scripts plombent le Total Blocking Time.

Google Fonts. Chaque famille de police = une requête bloquante vers les serveurs Google. Les polices système éliminent ce problème complètement.

Minute 7-10 : la base de données (si accès admin)

Outil : Query Monitor

Query Monitor est indispensable. Il affiche le nombre de requêtes SQL par page, le temps d’exécution, et surtout le plugin responsable de chaque requête.

Ce que je vérifie :

Les options autoloadées. Une requête SQL simple me donne le poids total :

SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload = 'yes';

Selon Kinsta (source : kinsta.com), la recommandation est de rester sous 800 Ko. Au-dessus de 1 Mo, c’est un problème. J’ai vu des sites WooCommerce à 5-10 Mo d’options autoloadées - souvent à cause de plugins désinstallés qui laissent leurs données derrière eux.

Les requêtes lentes. Query Monitor les identifie et montre quel plugin les génère. Les meta queries sur wp_postmeta sont les coupables habituels, surtout sur les catalogues avec des champs ACF.

Les transients expirés. Ils s’accumulent silencieusement dans wp_options et gonflent la table sans raison.

Minute 10-12 : le checkout

Je simule un parcours d’achat complet. Ce que je vérifie :

Le type de checkout. Shortcode legacy [woocommerce_checkout] ou checkout blocs ? Le legacy est plus lourd et moins performant - c’est souvent un quick win de migrer.

Le nombre de champs. Chaque champ inutile augmente le taux d’abandon. Selon le Baymard Institute, 22% des abandons sont dus à un processus trop long.

Les passerelles de paiement. Combien de scripts JS chargent-elles ? Certaines anciennes passerelles chargent jQuery et leurs propres fichiers sur chaque page du site, pas seulement au checkout.

Le cache. La page panier et le checkout ne doivent pas être cachées (sinon un client voit le panier d’un autre). Mais le reste du site doit l’être. Je vérifie les headers cf-cache-status si le site est sur Cloudflare.

Minute 12-15 : l’hébergement

Outil : TTFB sans cache

Je mesure le TTFB en bypassant le cache (ajout d’un paramètre aléatoire dans l’URL). Ça me donne le temps de réponse brut du serveur.

Moins de 300ms : bon
300-600ms : acceptable
Plus de 600ms : l’hébergement est probablement sous-dimensionné

Ce que je note :

La version PHP (8.2+ minimum, chaque version majeure apporte 10-20% de gains)
La présence de Redis (Object Cache)
Le type d’hébergement (mutualisé, VPS, managé)

Comme le souligne Remkus de Vries dans son article sur la performance WooCommerce (source : remkusdevries.com), un hébergement mutualisé n’est pas adapté dès que votre boutique charge des variations produit, du cross-sell, des cart fragments et du contenu personnalisé en temps réel.

Le résultat

En 15 minutes, j’ai une liste claire des problèmes classés par impact. En général, ça ressemble à ça :

Quick wins (impact immédiat, risque faible) : désactiver cart fragments, supprimer les scripts inutiles, activer le cache page
Optimisations moyennes (quelques heures de travail) : nettoyer les options autoloadées, migrer vers le checkout blocs, configurer Cloudflare
Chantiers structurels (plus lourd) : migration HPOS, changement de thème vers FSE, refonte de l’architecture de données ACF

C’est cette liste que je vous envoie quand vous demandez un audit gratuit.

Envie de savoir ce qui ralentit votre boutique ? Demandez un audit gratuit - diagnostic personnalisé sous 48h.