# Surveiller les Core Web Vitals en continu avec la bibliothèque web-vitals

> Attendre le rapport mensuel de Search Console pour découvrir une régression, c'est réagir trois semaines trop tard. Collecter les métriques terrain en direct avec la bibliothèque web-vitals change la donne.

- Auteur : Clément Hadrot
- Publié le : 2025-04-22
- Mis à jour le : 2025-04-22
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/surveiller-core-web-vitals-continu-web-vitals/

## L’essentiel

- La bibliothèque officielle web-vitals mesure LCP, INP et CLS directement chez le visiteur réel
- Envoyer les mesures vers son propre point de collecte permet d'alerter en quelques heures, pas en quelques semaines
- Segmenter par gabarit de page évite de noyer une régression ciblée dans une moyenne globale

Une question revient souvent chez nos clients : « comment savoir si telle mise à jour a dégradé les performances, avant que Google ne nous le dise trois semaines plus tard ? » Le rapport Core Web Vitals de Search Console s'appuie sur des données agrégées sur 28 jours glissants, ce qui introduit un délai de détection incompatible avec un cycle de déploiement rapide. Ce tutoriel ne traite ni de Lighthouse, qui mesure en laboratoire et non chez de vrais visiteurs, ni de CrUX, la base de données publique de Google, mais de la collecte directe et immédiate de vos propres métriques terrain.

## Étape 1 : installer la bibliothèque web-vitals

La bibliothèque officielle `web-vitals`, maintenue par l'équipe Chrome, expose une API JavaScript simple pour capturer LCP, INP et CLS au moment exact où le navigateur les calcule pour le visiteur en cours. Elle peut être chargée en tant que script dans le thème, via `wp_enqueue_script()` pointant vers une version hébergée localement ou depuis un CDN de confiance comme jsDelivr.

```
function wpm_enqueue_web_vitals() {
    wp_enqueue_script(
        'web-vitals',
        get_stylesheet_directory_uri() . '/assets/js/web-vitals.iife.js',
        array(),
        '4.2.0',
        true
    );
    wp_enqueue_script(
        'wpm-vitals-collector',
        get_stylesheet_directory_uri() . '/assets/js/vitals-collector.js',
        array( 'web-vitals' ),
        '1.0',
        true
    );
}
add_action( 'wp_enqueue_scripts', 'wpm_enqueue_web_vitals' );
```

## Étape 2 : capturer et envoyer les mesures

> L'essentiel à retenir : La bibliothèque officielle web-vitals mesure LCP, INP et CLS directement chez le visiteur réel ; Envoyer les mesures vers son propre point de collecte permet d'alerter en quelques heures, pas en quelques semaines ; Segmenter par gabarit de page évite de noyer une régression ciblée dans une moyenne globale

Le script de collecte s'appuie sur les fonctions `onLCP`, `onINP` et `onCLS` exposées par la bibliothèque, chacune recevant en rappel la métrique calculée dès qu'elle est disponible pour la page en cours :

```
import { onLCP, onINP, onCLS } from 'web-vitals';

function envoyerMetrique(metrique) {
    const donnees = JSON.stringify({
        nom: metrique.name,
        valeur: metrique.value,
        gabarit: document.body.dataset.gabarit || 'inconnu',
        url: location.pathname,
    });
    navigator.sendBeacon('/wp-json/wpm/v1/vitals', donnees);
}

onLCP(envoyerMetrique);
onINP(envoyerMetrique);
onCLS(envoyerMetrique);
```

L'utilisation de `navigator.sendBeacon()` plutôt qu'un `fetch()` classique garantit que la mesure part correctement même si le visiteur quitte la page juste après, un cas fréquent pour l'INP notamment, calculé parfois tardivement dans le cycle de vie de la session.

## Étape 3 : recevoir les mesures côté WordPress

Un point d'API REST personnalisé reçoit les mesures et les stocke, par exemple dans une table dédiée plutôt que dans `wp_postmeta`, pour ne pas alourdir une table déjà sollicitée par ailleurs :

```
add_action( 'rest_api_init', function() {
    register_rest_route( 'wpm/v1', '/vitals', array(
        'methods'             => 'POST',
        'callback'            => 'wpm_enregistrer_vital',
        'permission_callback' => '__return_true',
    ) );
} );

function wpm_enregistrer_vital( WP_REST_Request $request ) {
    global $wpdb;
    $data = $request->get_json_params();
    $wpdb->insert( $wpdb->prefix . 'wpm_vitals', array(
        'metrique'  => sanitize_key( $data['nom'] ),
        'valeur'    => (float) $data['valeur'],
        'gabarit'   => sanitize_text_field( $data['gabarit'] ),
        'url'       => esc_url_raw( $data['url'] ),
        'cree_le'   => current_time( 'mysql' ),
    ) );
    return new WP_REST_Response( null, 204 );
}
```

## Étape 4 : segmenter par gabarit de page

Une moyenne globale masque souvent une régression localisée : sur un projet suivi de cette façon, le LCP moyen du site restait stable alors que le gabarit « fiche produit » s'était dégradé de 1,8 à 3,4 secondes après l'ajout d'un widget d'avis clients tiers, noyé statistiquement par la stabilité des autres gabarits bien plus nombreux. Stocker le gabarit avec chaque mesure, via un attribut `data-gabarit` posé sur `<body>` par le thème, permet de croiser les métriques par type de page dans un tableau de bord.

## Étape 5 : déclencher une alerte

Une tâche planifiée quotidienne calcule le 75e centile de chaque métrique par gabarit sur les dernières 24 heures (le centile recommandé par Google pour évaluer un site, plutôt qu'une moyenne sensible aux valeurs extrêmes) et envoie une alerte si un seuil est dépassé, par exemple un LCP au 75e centile supérieur à 2,5 secondes.

## Pour aller plus loin

Cette approche ne remplace pas les rapports officiels de Google, qui restent la référence pour le référencement, mais elle réduit le délai de détection d'une régression de plusieurs semaines à quelques heures, ce qui change radicalement la capacité à réagir avant qu'un incident de performance n'affecte durablement le trafic ou les conversions.