# Un an de suivi des Core Web Vitals sur 200 pages produits WooCommerce

> Retour chiffré sur douze mois de surveillance CWV par catégorie de produit : ce qui s'est amélioré, ce qui a régressé après chaque mise à jour, et les décisions prises.

- Auteur : Clément Hadrot
- Publié le : 2024-01-17
- Mis à jour le : 2024-01-17
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/un-an-suivi-core-web-vitals-woocommerce/

## L’essentiel

- Le suivi par catégorie révèle des écarts que la moyenne globale cache
- Deux régressions sur douze mois causées par des extensions tierces
- Le LCP des fiches produit reste le point le plus fragile

La boutique vend du matériel de randonnée, avec un catalogue d'environ 900 références réparties en une dizaine de catégories, dont deux cents pages produit à fort trafic suivies de près depuis janvier 2023. L'idée de ce suivi n'était pas de courir après un score parfait, mais de comprendre comment les Core Web Vitals évoluent réellement sur un an de vie normale d'une boutique WooCommerce : mises à jour de plugins, ajouts de fonctionnalités marketing, changements saisonniers de trafic.

Les données proviennent du champ de terrain (CrUX via Search Console) croisé avec des mesures de laboratoire mensuelles sur un échantillon fixe de vingt fiches produit représentatives de chaque catégorie, pour distinguer une variation réelle d'un artefact de mesure.

## La moyenne globale masquait des écarts importants entre catégories

En janvier, le LCP moyen toutes pages produit confondues semblait acceptable, autour de 2,3 secondes. Mais en ventilant par catégorie, l'écart est apparu : les fiches de la catégorie « chaussures », qui affichent un carrousel de six visuels par produit, culminaient à 3,4 secondes, tandis que la catégorie « accessoires », avec une seule image, restait sous 1,8 seconde. La moyenne globale aurait masqué ce problème pendant des mois si le suivi n'avait pas été segmenté dès le départ.

## Ce qui s'est amélioré sur l'année

Trois changements ont eu un effet mesurable et durable :

- Le passage à des images au format WebP en mars a fait gagner en moyenne 320 millisecondes de LCP sur les fiches à fort contenu visuel.
- L'ajout de l'attribut `fetchpriority="high"` sur l'image principale des fiches produit en septembre, suite à son arrivée dans WordPress 6.3, a réduit le LCP de la catégorie « chaussures » de 3,1 à 2,6 secondes.
- La mise en cache d'objet Redis, activée en juin, a fait baisser le TTFB moyen de 480 à 210 millisecondes sur l'ensemble du catalogue.

## Ce qui a régressé, et pourquoi

Deux régressions notables ont ponctué l'année, toutes deux liées à des extensions tierces plutôt qu'au thème ou au cœur de WordPress.

> L'essentiel à retenir : Le suivi par catégorie révèle des écarts que la moyenne globale cache ; Deux régressions sur douze mois causées par des extensions tierces ; Le LCP des fiches produit reste le point le plus fragile

En avril, la mise à jour d'une extension d'avis clients a ajouté un script de suivi supplémentaire chargé en synchrone dans le `head`, sans que le changelog ne le mentionne clairement. Le CLS moyen des fiches produit est passé de 0,04 à 0,17 en une semaine, le temps que l'équipe identifie la cause via une comparaison avant/après des rapports Search Console filtrés par date de déploiement. Le correctif a consisté à différer le chargement du script avec l'attribut `defer` après une demande d'ajustement auprès de l'éditeur de l'extension.

En octobre, une mise à jour de WooCommerce a modifié la structure du bloc de variations de produit (taille, couleur), introduisant un décalage visuel au chargement des variantes qui a fait remonter le CLS d'un sous-ensemble de fiches produit ayant plus de trois variantes. Le correctif a nécessité de réserver explicitement l'espace du sélecteur de variantes en CSS, plutôt que de le laisser dépendre du contenu chargé dynamiquement.

## Le tableau de suivi trimestriel

| Trimestre | LCP moyen (pages produit) | CLS moyen | Part de pages « bon » (LCP) |
| --- | --- | --- | --- |
| T1 2023 | 2,3 s | 0,05 | 68 % |
| T2 2023 | 2,0 s | 0,04 | 75 % |
| T3 2023 | 2,4 s | 0,15 | 66 % |
| T4 2023 | 1,9 s | 0,05 | 84 % |

## Ce que ce suivi a changé dans les décisions de l'équipe

Le suivi segmenté a fait sortir de terre une règle simple, désormais appliquée avant toute mise à jour d'extension touchant les fiches produit : un test de non-régression Lighthouse manuel sur un échantillon de cinq pages représentatives des catégories les plus lourdes, avant de déployer en production. Cette règle n'existait pas en janvier 2023 et découle directement des deux régressions observées cette année-là.

## Ce que ce retour d'expérience ne couvre pas

Ce suivi porte sur des pages déjà en place avec un outil de collecte déjà opérationnel ; il ne détaille pas la mise en place initiale de la mesure elle-même, ni le choix entre les différentes bibliothèques de collecte RUM disponibles. Il ne couvre pas non plus les pages de catégorie ou le tunnel de commande, suivis séparément avec des seuils différents.

> Une moyenne globale de Core Web Vitals sur un catalogue hétérogène raconte rarement la vérité ; elle raconte la catégorie la plus représentée.

## En résumé

Douze mois de suivi segmenté par catégorie ont permis de faire passer la part de pages produit sous le seuil « bon » de LCP de 68 % à 84 %, malgré deux régressions en cours d'année dues à des extensions tierces. Le principal enseignement n'est pas technique mais méthodologique : sans segmentation par catégorie de produit, la moyenne globale aurait caché l'essentiel des problèmes réels rencontrés par une partie significative des visiteurs.