vendredi 25 septembre 2026

À propos

Contact

Performance

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.

Par Clément Hadrot • 22 avril 2025 • 4 min de lecture • Aucun commentaire
Surveiller les Core Web Vitals en continu avec la bibliothèque web-vitals

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.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi