Lundi matin, un message Slack : « Julien, on a installé Woocommerce jeudi, ce matin le LCP est à 4.8s sur mobile et Google Search Console nous sort une volée d’URL “Détectées, actuellement non indexées”. » Trois jours d’installation, déjà les voyants rouges. Ce n’est pas une malchance, c’est le parcours standard d’un Woocommerce posé sans les premiers réglages de performance.
Ce que les guides de démarrage oublient de te dire, c’est que les vrais premiers pas ne consistent pas à créer ta première fiche produit. Ils consistent à poser les fondations de mesure et de restriction sans lesquelles ton LCP dérive dès le premier jour.
Installe, puis mesure tout de suite
Avant même de choisir un thème, tu installes le plugin Query Monitor. Tu ouvres Chrome DevTools, onglet Performance, et tu enregistres une navigation sur la page d’accueil de la boutique. Tu notes le LCP. Sur un WordPress nu avec Woocommerce et un thème par défaut, on dépasse déjà 2.5 secondes sur un VPS correct sans cache. La raison ? Woocommerce embarque ses scripts et ses styles sur toutes les pages, même celles qui n’affichent pas de produit. Le fichier woocommerce.css : chargé partout. jQuery Migrate : chargé partout. Le frontend ne distingue pas une page statique d’une fiche produit.
Mesure aussi l’INP sur la page panier et le checkout. Une interaction d’ajout au panier peut prendre 300 ms si elle déclenche des recalculs de style en cascade. Tu veux ton premier indicateur de référence avant d’ajouter la moindre extension. Si tu ne mesures rien, tu navigues à vue. On a détaillé l’outillage nécessaire dans notre guide sur l’optimisation des Core Web Vitals : Lighthouse, Web Vitals extension, et les rapports CrUX une fois que le site reçoit du trafic.
Le thème : ne prends pas le plus vendu, prends le plus sobre
Les thèmes les plus populaires sont des usines à JavaScript. Sliders réactifs, animations de survol, lazy loading tiers. Tu ne veux pas de ça. Tu veux un thème vide qui te laisse le contrôle des assets. Un thème sobre te fait gagner 300 ms sur le First Contentful Paint avant la moindre optimisation. Désactive tout builder visuel dont tu n’as pas l’usage immédiat. La ligne de code que tu n’envoies pas est toujours la plus rapide.
Les extensions : mets-toi une règle des 3 plugins
Chaque extension Woocommerce ajoute son propre CSS et son propre JavaScript dans la file d’attente de WordPress. Le pire, c’est qu’elle le fait sur toutes les pages. Tu installes un plugin de slider pour la page boutique et il charge Swiper.js sur l’article de blog, la page contact, la page panier. Ajoutes-en une demi-douzaine et tu obtiens 40 requêtes réseau supplémentaires avant même d’avoir entré un produit.
La règle que j’applique chez moi, c’est celle des trois extensions au démarrage, hors cache et Woocommerce lui-même. Pas de quatrième avant d’avoir audité l’impact de chaque ajout via l’onglet Réseau de DevTools et le waterfall. Query Monitor te liste les scripts et styles mis en file pour la requête en cours. Tu repères ceux qui ne servent pas sur la page. Ensuite tu utilises wp_dequeue_script et wp_dequeue_style dans le fichier functions.php de ton thème enfant, en ciblant les slugs enregistrés par le plugin. Conditionne le retrait par type de page : un script de variation de produit n’a rien à faire sur la page d’accueil.
Côté SEO, les mêmes excès se paient en crawl budget. Chaque requête AJAX vers admin-ajax.php peut générer des URLs sans contenu qui finissent dans les logs. Si en plus certaines extensions provoquent des redirections 302 ou des paramètres de session dans l’URL, Googlebot passe son temps sur des impasses. Moins tu installes d’extensions, moins tu passes de temps à expliquer à la Search Console pourquoi 30 % de ton budget crawl est consommé par des facettes vides.
⚠️ Attention : ne désactive pas un script Woocommerce essentiel au panier ou au passage de commande sans avoir testé en profondeur. Un
dequeuemal ciblé peut casser la mise à jour des quantités. Teste en environnement staging avec Query Monitor et les DevTools ouverts.
Si tu bidouilles beaucoup le code de ton thème, avoir un assistant qui te génère les bons snippets peut faire gagner du temps. On a comparé les sorties de Claude Code et de Cursor IDE sur du refactoring WordPress, le verdict est sans appel sur certains cas de figure, mais c’est un autre article (claude code vs cursor ide).
Les images produits : le lazy loading natif ne suffit pas
WordPress ajoute un attribut loading="lazy" aux images, ce qui est bien. Sauf que le navigateur ne peut pas réserver l’espace d’une image tant qu’il n’en connaît pas les dimensions. Résultat : le contenu se décale au chargement et ton CLS prend une claque. La première chose à faire, c’est d’ajouter explicitement width et height sur chaque balise <img>, ou de laisser le thème le faire s’il est moderne. Les images mises en fond via CSS échappent totalement au lazy loading natif. Ne les utilise pas pour les visuels produits principaux.
Active la conversion automatique en WebP, soit via un plugin léger, soit directement au niveau CDN. Vérifie que les miniatures Woocommerce ne sont pas régénérées dans des dimensions aberrantes. La fonction add_image_size mal paramétrée peut produire 15 tailles différentes par image, toutes en pleine résolution. Coupe dans le vif.
Cache et CDN : le piège du panier dynamique
Le full-page cache, c’est le plus gros gain de temps de réponse. Mais Woocommerce gère des sessions utilisateur. Si tu caches tout sans distinction de cookie, tu vas servir un panier vide à un client connecté. Configure le bypass sur /panier/, /commander/ et /mon-compte/. Utilise un cache proxy qui sait lire les cookies Woocommerce, comme l’Edge Cache de certains hébergeurs managés. Un cache mal configuré et ton taux de conversion s’effondre.
Le tunnel d’achat où l’INP explose
L’INP mesure la latence de l’interaction la plus lente. Dans une boutique Woocommerce, les interactions qui comptent sont les mises à jour de quantité, l’application d’un coupon, la sélection d’une variation. Chacune déclenche un appel admin-ajax.php qui met à jour le DOM du panier. Si le callback recalcule des hauteurs de colonne, redessine le tableau complet et n’utilise pas requestAnimationFrame, l’INP peut grimper à 500 ms.
La méthode : ouvre l’onglet Performance de Chrome, coche « Web Vitals », simule un mobile milieu de gamme, et effectue une modification de quantité. Repère la tâche longue. Souvent, le coupable est une fonction jQuery html() qui remplace un bloc entier du panier plutôt que de ne modifier que la ligne concernée. Différer le rechargement des scripts non critiques après l’interaction, ou mieux, remplacer l’appel AJAX par une implémentation qui utilise l’API Fetch et cible uniquement l’élément modifié, te fait redescendre sous 200 ms.
La Search Console te donne désormais un aperçu de l’INP par groupe de pages. Si ton tunnel d’achat dépasse le seuil, il apparaîtra en rouge. À ce stade, tu perds du classement et potentiellement des ventes. Le signal est froid, mais il est fiable.
Questions fréquentes
Faut-il un thème premium ou gratuit pour Woocommerce ?
Ni l’un ni l’autre. Le critère n’est pas le prix mais le poids en kilooctets et le nombre de requêtes bloquantes. Un thème gratuit vide bat toujours un thème premium livré avec WPBakery et 12 sliders. Avant de payer, génère un rapport WebPageTest sur la démo du thème.
Comment gérer les variations de produits qui ralentissent le chargement ?
Les variations chargées en AJAX alourdissent le DOM si elles injectent des blocs d’images sans lazy loading conditionnel. La meilleure approche consiste à utiliser l’API REST de Woocommerce pour ne charger que les données utiles et mettre à jour le DOM de manière ciblée, sans remplacer un bloc entier.
Woocommerce est-il taillé pour un site à fort trafic ?
Oui, à condition de déployer un cache objet (Redis), d’optimiser la base de données et de déporter les facettes vers un moteur externe comme Elasticsearch. La vraie limite n’est pas Woocommerce lui-même, c’est l’indexation des attributs de produits qui, sans clé appropriée, transforme la requête la plus simple en scan complet.
