Les Core Web Vitals qui comptent, ceux que Google utilise et qui décrivent l’expérience réelle d’un site, proviennent du Chrome UX Report : des données collectées auprès des navigateurs Chrome des utilisateurs qui ont accepté de les partager. Ce sont des données précieuses, mais elles ont des limites nettes. Elles arrivent avec un retard, sur une fenêtre de 28 jours ; elles ne couvrent que les pages ayant assez de trafic ; elles ne disent rien du modèle de page, du type d’utilisateur ou de l’élément qui cause un problème. Pour cette raison, tôt ou tard, quiconque prend la performance au sérieux se pose une question : comment mesurer les Core Web Vitals directement sur mes propres utilisateurs ?
La réponse s’appelle Real User Monitoring, ou RUM : collecter les métriques depuis les navigateurs des visiteurs réels, les envoyer à un système d’analyse et les étudier comme on étudie les autres données du site. Dans cet article, nous voyons ce qu’il apporte par rapport au CrUX, comment le mettre en œuvre avec la bibliothèque officielle de Google, quoi collecter en plus des chiffres et comment lire les résultats.
Ce que le RUM ajoute au Chrome UX Report
Le CrUX est la référence officielle, et il est bon de continuer à l’utiliser pour savoir comment Google voit le site, comme l’explique l’article sur les raisons pour lesquelles il faut à la fois CrUX et les données de laboratoire. Le RUM ne le remplace pas, mais il comble quatre lacunes importantes.
- L’actualité des données. Les données CrUX sont mises à jour sur une fenêtre glissante de 28 jours : l’effet d’une intervention n’est pleinement visible qu’au bout d’un mois. Avec le RUM, on le voit dès le lendemain, et une régression causée par une mise à jour apparaît en quelques heures.
- La segmentation. Le CrUX fournit des données par page ou par origine, réparties par type d’appareil. Le RUM permet de répartir les données par modèle de page, catégorie, pays, type de connexion, utilisateurs anonymes ou connectés, variante de test A/B : toute information disponible au moment de la mesure.
- La couverture. Les pages à faible trafic n’apparaissent pas dans le CrUX. Avec le RUM, même une fiche produit de niche a ses données, et surtout on peut agréger des pages similaires même quand aucune n’a assez de visites à elle seule.
- L’attribution. Le CrUX vous dit que l’INP est médiocre ; le RUM peut vous dire sur quel élément se produit l’interaction lente, quelle phase pèse le plus et quel script est responsable. C’est la différence entre savoir que l’on a un problème et savoir où intervenir.
La bibliothèque web-vitals
Mesurer correctement les Core Web Vitals dans le navigateur n’est pas trivial. Le CLS doit se calculer par fenêtres de session, l’INP exige d’observer toutes les interactions et de choisir la représentative, le LCP s’arrête à la première interaction de l’utilisateur, et tous doivent être gérés correctement quand la page est masquée, restaurée depuis le back/forward cache ou activée par un prerender. Pour éviter de réimplémenter ces règles, Google maintient une petite bibliothèque open source, web-vitals, qui les applique exactement comme Chrome le fait pour le CrUX.
L’usage de base tient en quelques lignes. Pour chaque métrique, on enregistre une fonction qui reçoit la valeur quand elle est disponible, et on l’envoie au serveur avec navigator.sendBeacon, qui fonctionne aussi quand la page se ferme :
import { onLCP, onINP, onCLS } from 'web-vitals/attribution';
function invia( metrica ) {
const dati = JSON.stringify( {
nome: metrica.name,
valore: metrica.value,
stato: metrica.rating, // good, needs-improvement, poor
id: metrica.id, // unique per page view
navigazione: metrica.navigationType,
modello: document.body.dataset.modello, // par ex. "scheda-prodotto"
pagina: location.pathname,
} );
navigator.sendBeacon( '/rum', dati );
}
onLCP( invia );
onINP( invia );
onCLS( invia );Certains détails sont importants. Le CLS et l’INP peuvent évoluer pendant toute la vie de la page, la bibliothèque les signale donc quand la page est masquée ; certaines visites, par exemple quand le navigateur est fermé brutalement, n’enverront jamais de données, et c’est normal. La même métrique peut être signalée plusieurs fois pour la même page, par exemple après une restauration depuis le bfcache : le champ id permet de distinguer les mesures et de ne garder que la dernière pour chaque page vue.
L’attribution : savoir pourquoi
La version « attribution » de la bibliothèque, celle importée dans l’exemple, ajoute des informations de diagnostic à chaque métrique. Pour le LCP, elle donne l’élément, l’URL de la ressource et la décomposition du temps en quatre phases : TTFB, délai avant le début du téléchargement, durée du téléchargement et délai de rendu. Pour l’INP, elle donne l’élément sur lequel l’interaction s’est produite, le type d’événement et la répartition entre délai initial, traitement et affichage, avec les scripts concernés tels que les détecte la Long Animation Frames API. Pour le CLS, elle donne l’élément qui s’est le plus décalé et le moment du décalage.
Ces informations font du RUM un outil de diagnostic plutôt qu’un simple thermomètre. Si, sur les fiches produit, la phase dominante du LCP est le délai avant le téléchargement, le problème est la découverte tardive de l’image, et la solution concerne la priorité et le lazy loading ; si c’est le TTFB, le problème est le serveur. Si le pire INP se produit toujours sur le même bouton et que le traitement est dominé par un seul script, on sait exactement par où commencer. Il vaut mieux n’envoyer que l’information essentielle, comme un sélecteur synthétique de l’élément et le nom du script, pour garder des données légères et sans information personnelle.
Où envoyer les données
Il y a trois voies principales. La première est un service RUM spécialisé : plusieurs éditeurs proposent collecte, stockage et tableaux de bord prêts à l’emploi, avec segmentation et attribution déjà organisées. C’est la solution la plus rapide, à un coût qui croît avec le trafic. La deuxième consiste à envoyer les métriques sous forme d’événements à un système d’analytics déjà utilisé, par exemple Google Analytics 4, et à les analyser avec des exports de données brutes : on utilise une infrastructure existante, mais il faut des compétences d’analyse. La troisième est un endpoint maison, qui écrit les données dans une base de données ou un système de journalisation : contrôle maximal, mais tout le travail de stockage et de visualisation revient au site.
Quel que soit le choix, pensez à l’échantillonnage. Sur un site à fort trafic, il n’est pas nécessaire de mesurer chaque visite : un pourcentage fixe, par exemple dix pour cent des pages vues, donne déjà des résultats statistiquement solides et réduit les coûts et le volume de données. L’échantillonnage doit être décidé par page vue, et non par métrique individuelle, pour garder cohérentes les données d’une même visite.
Le RUM sur WordPress
Sur un site WordPress, l’information la plus utile à ajouter aux métriques est le modèle de page : article, page, archive, produit, panier. Le thème la connaît déjà, et peut l’exposer par un attribut sur l’élément body, que le script de mesure lit au moment de l’envoi. Pour la collecte, une route de l’API REST ou un service externe sont tous deux envisageables ; l’important est que l’endpoint soit léger et ne passe pas par la génération complète d’une page.
// Expose le modèle de page au script de mesure
add_filter(
'body_class',
function ( $classi ) {
$modello = is_singular() ? get_post_type() : ( is_archive() ? 'archivio' : 'altro' );
$classi[] = 'modello-' . sanitize_html_class( $modello );
return $classi;
}
);Le script de mesure doit être chargé de façon non bloquante, comme module ou avec defer : la bibliothèque pèse quelques kilo-octets et ne doit pas devenir elle-même un coût pour la performance qu’elle mesure.
Au-delà des Core Web Vitals
Une fois la collecte en place, il est naturel de l’étendre. La même bibliothèque mesure aussi le TTFB et le First Contentful Paint, utiles pour séparer les problèmes de serveur de ceux du front-end. Mais le RUM permet aussi de mesurer ce qui compte pour le site concerné : le temps d’affichage des résultats de recherche interne, d’ouverture du mini-panier, d’achèvement d’une étape du paiement. Avec la User Timing API, quelques repères dans le code suffisent à transformer une interaction importante pour l’activité en métrique à suivre dans le temps, aux côtés des métriques standard.
Confidentialité et consentement
Les métriques de performance sont des données techniques, mais elles sont collectées sur les appareils des utilisateurs et envoyées avec des informations comme la page visitée. La bonne pratique est de ne rien collecter qui identifie la personne, d’éviter les identifiants persistants, de ne pas envoyer d’URL avec des paramètres pouvant contenir des données personnelles, et d’évaluer avec son propre conseil la base juridique de la collecte et le rapport avec le bandeau de cookies. Une collecte minimale et anonyme, limitée à la performance, est généralement plus simple à gérer qu’un suivi complet, mais l’évaluation doit se faire au cas par cas.
Comment lire les données
La première erreur à éviter est de regarder la moyenne. Les Core Web Vitals sont évalués au 75e percentile, et les distributions des temps de chargement sont asymétriques : quelques valeurs très élevées déplacent la moyenne sans dire grand-chose de l’expérience typique. Le 75e percentile, calculé séparément pour le mobile et le desktop, est la mesure à comparer aux seuils de Google et aux données CrUX.
La deuxième est de comparer des populations différentes. Les données RUM incluent souvent des navigateurs autres que Chrome, où certaines métriques sont indisponibles ou mesurées différemment, des visites avec un cache chaud et des visites d’utilisateurs que le CrUX n’inclut pas. Il est normal que les valeurs ne coïncident pas avec celles de la Search Console ; ce qui compte, c’est la cohérence des tendances et la capacité d’expliquer les écarts. Pour une comparaison directe, il vaut mieux filtrer les données RUM sur les seuls navigateurs Chromium.
La troisième est de lire les données sans les segmenter. La valeur globale du site dit peu de choses ; la même valeur répartie par modèle de page et par appareil dit presque tout. Un bon tableau de bord montre, pour chaque modèle de page important, le 75e percentile des trois métriques dans le temps, la part des visites dans la plage « bon » et, pour les métriques au-delà du seuil, les éléments et les phases les plus fréquents dans l’attribution.
Enfin, en plus du percentile, il vaut la peine de regarder la distribution. Un histogramme des valeurs de LCP ou d’INP montre si le problème touche uniformément tous les utilisateurs, ou un groupe précis : une seconde bosse dans la partie haute de la distribution désigne souvent un segment particulier, comme une connexion lente, un pays éloigné du serveur, un modèle de smartphone ou une page avec un widget particulier. Trouver ce groupe est souvent le chemin le plus court pour améliorer le 75e percentile de l’ensemble du site.
Un cas d’usage : contrôler une mise en production
La valeur du RUM apparaît clairement au moment des mises en production. Une mise à jour du thème, un nouveau plugin ou une campagne avec un nouveau pixel peuvent dégrader la performance sans que personne le remarque dans les tests manuels. Avec le CrUX, le problème ne ressortirait que des semaines plus tard, dilué dans la fenêtre de 28 jours ; avec le RUM, une comparaison du 75e percentile entre la veille et le lendemain de la mise en production le montre tout de suite, et l’attribution désigne souvent directement le script ou l’élément responsable. De la même façon, une optimisation peut être vérifiée en quelques jours au lieu d’un mois.
En bref
Le Real User Monitoring mesure les Core Web Vitals sur les visiteurs réels du site et comble les limites du Chrome UX Report : des données immédiates plutôt qu’une fenêtre de 28 jours, une segmentation par modèle de page et par type d’utilisateur, la couverture des pages à faible trafic et, surtout, l’attribution des causes. La bibliothèque web-vitals applique les mêmes règles que Chrome et, dans sa version « attribution », désigne les éléments, les phases et les scripts responsables.
Le mettre en œuvre demande quelques lignes de code, une destination pour les données et un peu de soin pour l’échantillonnage, la confidentialité et la lecture des résultats : 75e percentile, segmentation, comparaison avec le CrUX sur les mêmes populations. Le CrUX reste la référence pour savoir comment Google évalue le site ; le RUM est l’outil pour comprendre pourquoi, et pour s’apercevoir à temps que quelque chose change.
