Le site est celui d’un éditeur de comparateurs de prix actif dans trois pays (France, Belgique, Suisse), avec un trafic partagé de façon inégale entre mobile et ordinateur selon le pays, et deux grandes familles de pages : les pages de comparatif (fort contenu, tableaux) et les pages de fiche produit (plus légères). La bibliothèque web-vitals était déjà en place depuis plusieurs mois pour collecter les métriques de terrain, mais le tableau de bord existant n’affichait qu’une moyenne glissante sur sept jours, toutes pages et tous visiteurs confondus, ce qui masquait des situations très différentes d’un segment à l’autre.
Ce que la moyenne globale cachait
Le tableau de bord global affichait un LCP moyen de 2,1 secondes, jugé correct par l’équipe. Une fois les données ventilées par segment, l’image s’est révélée bien plus contrastée : les visiteurs mobiles en Suisse sur les pages de comparatif atteignaient un LCP moyen de 3,6 secondes, pénalisés par une combinaison de latence réseau plus élevée que la moyenne (constatée sur cette audience) et de tableaux comparatifs lourds à rendre sur des appareils souvent plus anciens que la moyenne française. Ce segment représentait pourtant moins de 6 % du trafic total, ce qui expliquait qu’il disparaisse complètement dans une moyenne globale dominée par le trafic desktop français.
Architecture du croisement de données
Plutôt que de stocker chaque événement web-vitals brut individuellement, ce qui aurait rapidement fait exploser le volume de données pour un trafic de plusieurs millions de pages vues par mois, le choix a été d’agréger les événements par segment et par tranche horaire directement côté serveur, avant stockage.
┌──────────────┐ événement CWV ┌────────────────────┐
│ Navigateur │ ───────────────────▶│ Endpoint de collecte│
│ (web-vitals) │ + user-agent, │ (beacon API) │
└──────────────┘ pays (en-tête) └──────────┬───────────┘
│ agrégation par segment
▼
┌────────────────────┐
│ Table agrégée │
│ (pays, appareil, │
│ type_page, heure) │
└──────────┬───────────┘
│
▼
┌────────────────────┐
│ Tableau de bord │
│ (croisement filtré) │
└────────────────────┘
Le schéma de la table agrégée
Chaque ligne de la table représente un segment (pays, type d’appareil, type de page) pour une heure donnée, avec des compteurs incrémentés à chaque événement reçu plutôt que des lignes individuelles par événement.
CREATE TABLE cwv_agrege (
heure DATETIME NOT NULL,
pays VARCHAR(2) NOT NULL,
appareil ENUM('mobile', 'desktop') NOT NULL,
type_page ENUM('comparatif', 'fiche_produit') NOT NULL,
lcp_somme FLOAT NOT NULL DEFAULT 0,
cls_somme FLOAT NOT NULL DEFAULT 0,
inp_somme FLOAT NOT NULL DEFAULT 0,
nb_evenements INT UNSIGNED NOT NULL DEFAULT 0,
PRIMARY KEY (heure, pays, appareil, type_page)
) ENGINE=InnoDB;
La clé primaire composite permet une écriture en INSERT ... ON DUPLICATE KEY UPDATE, qui incrémente directement les sommes et le compteur sans jamais multiplier les lignes, gardant la table à une taille gérable (environ 26 000 lignes par mois pour douze segments suivis, contre plusieurs millions d’événements bruts qui auraient été générés sans agrégation).
Ce que le tableau de bord a changé dans les priorités
Une fois le croisement disponible, l’équipe a reclassé ses priorités de correction : le segment mobile Suisse sur les pages de comparatif, bien que minoritaire en volume, a été traité en premier parce que son écart à l’objectif était le plus important en proportion, avec un allégement du tableau comparatif (moins de colonnes par défaut sur mobile, chargement différé des colonnes secondaires). Le segment desktop France, majoritaire en volume mais déjà dans la zone « bon », est resté en simple surveillance.
- Filtrer par pays, appareil et type de page avant de tirer une conclusion sur une métrique CWV.
- Prioriser les segments à fort écart à l’objectif, pas uniquement les segments à fort volume.
- Agréger côté serveur pour garder un volume de stockage maîtrisé sur la durée.
Hors périmètre
Cet article ne détaille pas la mise en place de la collecte elle-même avec la bibliothèque web-vitals, déjà en place sur ce projet avant la construction du tableau de bord segmenté ; il se concentre sur l’architecture de croisement et d’agrégation qui transforme des données brutes en priorités d’action.
Une moyenne qui rassure cache souvent le segment qui, lui, ne pardonnera jamais un mauvais chiffre — celui qui décroche avant même d’avoir vu la page.
En résumé
Le passage d’une moyenne globale à un tableau de bord croisant pays, appareil et type de page a révélé un segment minoritaire mais fortement dégradé, invisible dans les indicateurs précédents, et a permis de prioriser un correctif concret sur les tableaux comparatifs affichés sur mobile. L’agrégation côté serveur, plutôt que le stockage des événements bruts, a gardé le dispositif soutenable en volume sur la durée.
