La réponse courte : la vitesse n'est pas une métrique technique, c'est un multiplicateur pour tout le tunnel. Elle agit en même temps sur la conversion, sur les positions dans les moteurs de recherche et sur le prix du clic payant. C'est la seule amélioration que l'on ne peut pas faire « pour un seul canal » : elle agit partout à la fois.
Ce que Google mesure exactement
Depuis 2020, trois métriques sont collectées par Google auprès des vrais utilisateurs de votre site, et non en laboratoire. Elles s'appellent les Core Web Vitals, et les seuils sont les suivants :
| Métrique | Ce que cela veut dire en clair | Seuil « bon » |
|---|---|---|
| LCP | Quand apparaît le bloc principal de la page : photo du produit, titre | jusqu'à 2,5 s |
| INP | À quelle vitesse la page réagit aux clics | jusqu'à 200 ms |
| CLS | À quel point le contenu saute pendant le chargement | jusqu'à 0,1 |
Un détail qui échappe régulièrement : c'est le 75e percentile qui compte. Il ne suffit pas que « chez moi, sur mon portable, ça s'ouvre vite » : trois quarts des vraies visites, y compris les vieux Android sur réseau mobile, doivent entrer dans le seuil.
Dans les boutiques WordPress, c'est le plus souvent l'INP qui pèche : la page a le temps de s'afficher, mais pendant la seconde suivante elle ne réagit pas aux clics, car les scripts des plugins, du chat, des pixels et du panier continuent de tourner en arrière-plan. L'utilisateur ne le lit pas comme « page lente » mais comme « la page est cassée », et il repart.
Ce que cela coûte en argent
L'illustration publique la plus honnête est l'étude de cas Vodafone sur web.dev : un test A/B sur deux versions visuellement identiques d'une page a montré qu'une amélioration du LCP de 31 % a donné 8 % de ventes en plus. Sans refonte, sans nouvelle promotion : la vitesse seule.
Appliquez cela à vos propres chiffres, comme dans le premier sujet : si la boutique fait 40 000 € par mois, 8 %, c'est 3 200 € chaque mois. Le travail sur la vitesse, lui, se fait une seule fois.
Il y a un second effet, que l'on compte rarement : la vitesse change le coût de la publicité. Une page de destination lente dégrade le niveau de qualité dans les systèmes publicitaires et augmente le prix du clic. Vous payez deux fois : moins de monde arrive, et chaque arrivée a coûté plus cher.
Pourquoi c'est justement WooCommerce qui ralentit
WooCommerce en lui-même n'est pas lent. Ce qui le rend lent, c'est la construction typique qui l'entoure. D'après mes audits, l'ordre des coupables est presque toujours le suivant :
- Un thème à constructeur. Un thème polyvalent avec un builder visuel traîne des dizaines de fichiers CSS et JS sur chaque page, y compris ceux qui ne servent que sur la page d'accueil. C'est la cause la plus fréquente et la plus sous-estimée.
- Des plugins chargés partout. Le plugin de slider, de formulaire, d'avis et de calcul de livraison enregistrent leurs scripts dans toute la boutique, et pas seulement là où ils servent.
- Pas de cache de pages. Chaque entrée dans une catégorie est un cycle PHP complet plus des requêtes à la base. Sur un hébergement mutualisé à 5 €/mois, cela fait 1,5 à 3 secondes jusqu'au premier octet.
- Les fragments du panier. WooCommerce appelle par défaut
wc-ajax=get_refreshed_fragmentssur chaque page pour actualiser le compteur du panier. Sur une page par ailleurs mise en cache, c'est la seule requête non cachable, et elle bloque le reste. - Des photos à leur taille d'origine. Le photographe a livré des JPEG de 4 000 px de 3 Mo et ils ont été téléversés tels quels. Le navigateur télécharge 3 Mo pour afficher une image de 600 px de large.
- Des scripts externes. Chat, pixels, cartes, widgets d'avis. Chacun a l'air innocent, ensemble ils dévorent l'INP.
Quoi corriger, dans l'ordre de rentabilité
L'ordre compte : le moins cher et le plus efficace d'abord :
- Les photos : conversion en WebP/AVIF, taille adaptée, chargement différé de tout ce qui est sous le premier écran, mais pas de la photo principale du produit (cela dégrade le LCP)
- Cache de pages + object cache : mise en cache statique des catégories et des fiches produit, Redis ou Memcached pour les requêtes à la base
- Désactivation des fragments du panier là où ils ne sont pas nécessaires, ou remplacement par une actualisation légère du compteur
- Revue des plugins : supprimer ceux qui ne servent pas, limiter le chargement des scripts aux pages qui en ont vraiment besoin
- Report des scripts externes : charger le chat et les pixels après une interaction, et non dans le
<head> - Polices : hébergement propre,
font-display: swap, seulement les variantes utilisées - Hébergement : si après tout cela le TTFB dépasse encore 600 ms, le problème est dans la machine, pas dans le code
Les trois premiers points donnent généralement 70 % de l'effet et prennent quelques jours. Les détails techniques de chacun se trouvent dans le guide voisin : Core Web Vitals, images, polices et scripts et mise en cache.
Encadré pour le développeur
- Activez HPOS. High-Performance Order Storage déplace les commandes de
wp_posts/wp_postmetavers des tables dédiées. Sur une boutique avec des dizaines de milliers de commandes, cela change aussi bien l'administration que chaque requête sur les commandes. - Mesurez les données de terrain, pas celles du laboratoire. Le mode laboratoire de PageSpeed Insights est pratique pour déboguer, mais la note vient des données de terrain CrUX. Le rapport Core Web Vitals de la Search Console dit la vérité.
- Cherchez les tâches longues, pas le « poids de la page ». L'INP est tué par des gestionnaires précis : redessin du panier, script du slider, code d'analytics synchrone. Profilez l'onglet Performance plutôt que de compter les kilo-octets.
- Vérifiez les options autoload.
SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes': si cela se compte en mégaoctets, chaque requête traîne ce lest. Ce sont généralement des restes de plugins supprimés. - Vérifiez sur un profil mobile avec limitation du réseau et du processeur. Sur votre MacBook, c'est toujours rapide.
Quand l'optimisation du thème cesse d'aider
Il existe une limite au-delà de laquelle il n'y a plus rien à améliorer : le thème et les plugins imposent un minimum de travail qu'on ne peut pas supprimer sans casser la boutique. Les signes que vous l'avez atteinte :
- Le LCP mobile reste bloqué à 3–4 secondes, alors que les photos et le cache sont déjà faits
- Chaque nouveau plugin dégrade nettement les métriques
- Vous devez choisir entre « rapide » et « a les fonctions nécessaires »
À ce stade, il reste deux voies. La première est de réduire les fonctionnalités : renoncer au builder, réécrire les gabarits, supprimer une partie des plugins. La seconde est de séparer la vitrine et le back-end : garder WooCommerce pour les produits, les commandes et l'administration, et construire le front-end à part sur une pile rapide. Comment cela fonctionne et quand c'est rentable, la page WooCommerce et headless le décrit, y compris une description honnête des cas où cela ne l'est pas. Une solution toute prête de ce type est NextWoo, une vitrine en Next.js sur un WooCommerce existant.
Test pratique
- J'ai ouvert le rapport Core Web Vitals de Google Search Console et regardé les adresses mobiles
- Je connais le LCP, l'INP et le CLS d'après les données de terrain, et pas seulement d'après un test de laboratoire
- J'ai vérifié le poids de la photo principale du produit : moins de 150–200 Ko
- J'ai vérifié le TTFB sur une page de catégorie : moins de 600 ms
- J'ai désactivé ou limité les fragments du panier
- J'ai passé en revue la liste des plugins : chacun est soit nécessaire, soit supprimé
- J'ai calculé ce que valent 8 % de ventes en plus, en argent, pour moi
Et ensuite
Une boutique rapide est une condition, pas une raison d'acheter. Ensuite, le visiteur arrive sur la fiche produit et décide s'il vous fait assez confiance pour donner son argent : la fiche produit qui vend.
Si vous voulez le confier à quelqu'un : accélération du site, avec audit, liste des travaux par priorité et prix fixe pour la mise en œuvre.