# Segmenter les Core Web Vitals par appareil et pays dans un tableau de bord > Construire un tableau de bord maison qui croise les données RUM par segment (mobile, desktop, pays, type de page) pour prioriser les correctifs plutôt qu'une moyenne trompeuse. - Auteur : Clément Hadrot - Publié le : 2025-01-31 - Mis à jour le : 2025-01-31 - Catégorie : Performance - URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/segmenter-core-web-vitals-appareil-pays-dashboard/ ## L’essentiel - Une moyenne globale masque les segments réellement en difficulté - Le croisement pays x appareil x type de page révèle des priorités différentes - Le stockage en base agrégée évite l'explosion de volume des événements bruts 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é) │ └────────────────────┘ ``` > L'essentiel à retenir : Une moyenne globale masque les segments réellement en difficulté ; Le croisement pays x appareil x type de page révèle des priorités différentes ; Le stockage en base agrégée évite l'explosion de volume des événements bruts ## 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.