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

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.