Mesurer les Core Web Vitals sur le terrain : bonnes pratiques
Suivez les bonnes pratiques pour mesurer vos Core Web Vitals avec votre outil d'analyse, sans dégrader les performances de vos pages.
Mesurer les performances réelles de vos pages est indispensable pour diagnostiquer et améliorer l’expérience au fil du temps. Sans données terrain, impossible de confirmer qu’une modification produit bien le résultat espéré. Si vous partez de zéro, notre guide pour débuter avec la mesure des Core Web Vitals pose les bases avant d’aller plus loin. La plupart des outils d’analyse RUM populaires prennent déjà en charge les Core Web Vitals, et même ceux qui ne le font pas permettent presque toujours de définir des métriques ou des événements personnalisés.
Pour le SEO, cette mesure terrain est précieuse : elle vous permet de vérifier le respect des seuils Core Web Vitals page par page et d’éviter les régressions, donc de protéger durablement la qualité de votre expérience de page.
L’erreur que je vois le plus souvent, c’est de mettre en place une mesure terrain qui dégrade elle-même les performances qu’elle est censée surveiller. Soyez vigilant sur le moment où vous envoyez les données et sur le poids de votre instrumentation. Une bonne collecte est légère, discrète, et envoie ses mesures au bon moment, sans jamais peser sur l’expérience du visiteur.
Mesurer avec des métriques ou des événements personnalisés
Si votre outil d’analyse accepte les données personnalisées, vous pouvez y mesurer chacune des métriques Core Web Vitals. La démarche suit généralement trois étapes, résumées ci-dessous. Pour le calcul côté client, la librairie web-vitals fait le travail à votre place.
| Étape | Action | Où la réaliser |
|---|---|---|
1 |
Définir ou enregistrer la métrique personnalisée (si nécessaire) |
Interface d’administration de votre outil d’analyse |
2 |
Calculer la valeur de la métrique côté client |
Code JavaScript, via la librairie web-vitals |
3 |
Envoyer la valeur au backend en respectant le nom ou l’ID |
Code JavaScript et configuration de l’outil |
Un exemple concret avec la librairie web-vitals
La librairie web-vitals rend le suivi remarquablement simple : vous importez les fonctions de mesure, vous définissez une fonction d’envoi, et vous laissez la librairie déclencher les rapports au bon moment. L’exemple ci-dessous mesure le CLS, l’INP et le LCP, puis transmet les résultats à un point de collecte en privilégiant l’API sendBeacon, plus économe. Pour transformer ces chiffres en éléments concrets à corriger, complétez cette collecte par l’attribution décrite dans notre guide pour déboguer les performances sur le terrain.
import {onCLS, onINP, onLCP} from 'web-vitals';
function sendToAnalytics({name, value, id}) {
const body = JSON.stringify({name, value, id});
// Utilise navigator.sendBeacon() si disponible, sinon fetch().
(navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
fetch('/analytics', {body, method: 'POST', keepalive: true});
}
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);Envoyer les données au bon moment
Certaines métriques se calculent une fois la page chargée, mais d’autres comme le CLS prennent en compte toute la durée de vie de la page et ne sont définitives qu’au moment où celle-ci se décharge. Or les événements beforeunload et unload ne sont pas fiables, surtout sur mobile, et leur usage est déconseillé car ils peuvent empêcher la mise en cache de la page.
La bonne pratique consiste à envoyer la valeur courante lors de l’événement visibilitychange, dès que la page passe à l’état hidden. Cet événement est bien plus fiable, y compris quand l’utilisateur change d’onglet, ouvre une autre application ou ferme le navigateur. La librairie web-vitals gère déjà les cas particuliers et les bugs de navigateur associés.
Ne pas dégrader les performances en les mesurant
Votre code de mesure ne doit jamais nuire aux performances qu’il observe, sous peine de fausser toutes vos conclusions. Chargez le code d’analyse de façon asynchrone et non bloquante, en dernier, pour ne pas pénaliser le LCP. Évitez les tâches longues qui bloquent le thread principal et dégradent l’INP. Privilégiez des API non bloquantes comme sendBeacon() et requestIdleCallback(). Enfin, ne suivez que les données réellement utiles : ce n’est pas parce qu’une donnée est disponible qu’il faut l’enregistrer. Pour une analyse plus poussée, vous pouvez ensuite mesurer vos Core Web Vitals avec GA4 et BigQuery et croiser ces données avec vos dimensions métier.
La moyenne semble pratique mais elle ne représente la session d’aucun utilisateur réel : quelques valeurs extrêmes suffisent à la fausser. Pour respecter les seuils Core Web Vitals, affichez chaque métrique au 75e percentile. Pour comprendre les utilisateurs les plus pénalisés, observez aussi le 90e, voire le 95e percentile.
À faire
- calculer les métriques avec web-vitals
- envoyer les données lors de visibilitychange
- charger le code d’analyse en asynchrone
- rapporter au 75e percentile
- segmenter par version déployée
À éviter
- se reposer sur les moyennes
- utiliser les événements unload ou beforeunload
- bloquer le rendu avec un test A/B côté client
- suivre toutes les données sans tri
Points clés à retenir
- Utilisez vos métriques ou événements personnalisés et la librairie web-vitals.
- Envoyez les valeurs lors de l'événement visibilitychange, pas à l'unload.
- Chargez le code d'analyse en asynchrone, en dernier, sans bloquer le rendu.
- Privilégiez sendBeacon() et requestIdleCallback() pour rester non bloquant.
- Rapportez toujours au 75e percentile, jamais en moyenne.
Pour mesurer vos signaux Web sur le terrain sans dégrader l’expérience, retenez ceci.
Quiz : testez vos connaissances
Quiz : testez vos connaissances
-
À quel moment envoyer les données de mesure plutôt qu'aux événements unload ou beforeunload ?
- Dès la fin du chargement de la page, une seule fois
- À l'événement beforeunload, le plus fiable pour capturer le CLS final
- Lors de l'événement visibilitychange, car unload et beforeunload ne sont pas fiables, surtout sur mobile
Le CLS n’est définitif qu’au déchargement, mais
unloadetbeforeunloadne sont pas fiables, surtout sur mobile. Envoyer les données lors devisibilitychangeest plus sûr. -
Comment éviter que le code de mesure dégrade les performances qu'il observe ?
- Charger le code d'analyse de façon asynchrone et non bloquante, en dernier
- Lancer un test A/B côté client avant le rendu pour comparer les versions
- Charger le code d'analyse en premier et de façon synchrone
Un code de mesure bloquant fausse les résultats. Le charger en asynchrone, non bloquant et en dernier évite de pénaliser le LCP et le thread principal.
-
Pourquoi éviter la moyenne pour rapporter les Core Web Vitals ?
- Parce que Google interdit son usage dans les outils RUM
- Parce qu'elle est plus difficile à calculer que le 75e percentile
- Parce qu'elle ne représente la session d'aucun utilisateur réel et qu'elle est faussée par les valeurs extrêmes
La moyenne ne correspond à l’expérience d’aucun visiteur et quelques valeurs extrêmes suffisent à la fausser. Le 75e percentile respecte les seuils de Google.
À propos de l'auteur
Besoin d'un accompagnement SEO ?
Besoin d'aide pour instrumenter vos Core Web Vitals sans pénaliser vos performances ?