Suivre les performances des utilisateurs réels

Un audit réussi avant la mise en ligne ne garantit pas que chaque visiteur bénéficie d’une expérience rapide. Les appareils, les réseaux et les conditions d’utilisation varient ; une régression peut donc apparaître après le déploiement, même si le code n’a pas changé en apparence.

Dans cette leçon, vous mettez en place une collecte légère des performances réelles, puis vous définissez quoi faire lorsque les mesures se dégradent. Les audits et les seuils de référence établis précédemment restent vos points de comparaison ; le suivi de terrain les complète, sans les remplacer.

Collecter des mesures de terrain

Les données de terrain proviennent des visites réelles et reflètent des configurations variées. Pour les Core Web Vitals et leurs seuils, reportez-vous à « Choisir les indicateurs à suivre » ; pour Lighthouse, à « Mesurer l’état initial d’une route ». Ici, l’enjeu est de transmettre les mesures après leur collecte, sans enregistrer de contenu de page, d’identifiant personnel ou de donnée de navigation inutile.

Next.js fournit useReportWebVitals dans next/web-vitals. Le composant suivant reçoit les mesures dans le navigateur et les envoie par sendBeacon à un collecteur que vous gérez. Configurez NEXT_PUBLIC_VITALS_ENDPOINT avec l’URL HTTPS de ce collecteur dans l’environnement de déploiement ; celui-ci doit accepter les requêtes POST de votre domaine et appliquer une politique de conservation adaptée.

'use client';

import { useReportWebVitals } from 'next/web-vitals';

export default function SuiviPerformances() {
  useReportWebVitals((metric) => {
    const endpoint = process.env.NEXT_PUBLIC_VITALS_ENDPOINT;

    if (!endpoint || typeof navigator.sendBeacon !== 'function') {
      return;
    }

    const payload = {
      id: metric.id,
      name: metric.name,
      value: metric.value,
      rating: metric.rating,
      route: window.location.pathname,
      navigationType: metric.navigationType
    };
    const body = new Blob([JSON.stringify(payload)], {
      type: 'application/json'
    });

    navigator.sendBeacon(endpoint, body);
  });

  return <div className="rando-mesures" aria-hidden="true" />;
}

Enregistrez ce fichier complet dans components/suivi-performances.tsx. L’identifiant de mesure sert à reconnaître un même événement lors du traitement ; la route permet de regrouper les résultats par page. La charge envoyée reste limitée aux champs nécessaires à l’analyse : n’ajoutez pas d’URL avec paramètres, de contenu saisi par les visiteurs ni d’identifiant permettant de les suivre.

Brancher le suivi au catalogue

Importez le composant client dans le layout racine, afin qu’il observe les routes du site, et rendez-le une seule fois dans le corps de la page. Voici un layout minimal cohérent avec le contrat du projet ; si votre layout contient déjà les composants d’en-tête et de pied de page, conservez-les et ajoutez seulement l’import et l’instance du suivi. Ne créez pas un second conteneur de mesures si votre layout en affiche déjà un.

import type { Metadata } from 'next';
import './style.css';
import SuiviPerformances from '../components/suivi-performances';
import EnTete from '../components/en-tete';
import PiedDePage from '../components/pied-de-page';

export const metadata: Metadata = {
  title: 'Randonnées — Catalogue des itinéraires',
  description: 'Découvrez des itinéraires et préparez votre prochaine sortie.'
};

export default function RootLayout({
  children
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="fr">
      <body>
        <div className="rando-site">
          <EnTete />
          <main className="rando-principal">{children}</main>
          <PiedDePage />
          <SuiviPerformances />
        </div>
      </body>
    </html>
  );
}

Adaptez l’import aux exports réellement présents dans vos composants d’en-tête et de pied de page, sans modifier leurs noms de fichier ni leurs classes. Le suivi produit un appel réseau distinct vers le collecteur, mais ne requiert pas de bibliothèque supplémentaire. Après intégration, construisez l’application et examinez le waterfall : vérifiez que le collecteur répond, que les événements ne sont pas envoyés en boucle et que le JavaScript client reste dans le budget défini dans « Fixer un budget de JavaScript client ».

Analyser et traiter une régression

Dans le collecteur, regroupez les mesures par nom d’indicateur, route et période, puis examinez leur distribution et leur évolution plutôt qu’un événement isolé. Comparez les résultats aux seuils de référence déjà définis et distinguez une dégradation durable d’un faible volume de données ou d’une variation ponctuelle. Les données de terrain ne sont pas directement équivalentes à une exécution Lighthouse : gardez séparés leurs conditions et leurs usages.

1. Vérifiez que le collecteur reçoit encore des événements et que la période observée contient assez de visites pour être interprétable.
2. Repérez les routes et indicateurs concernés ; comparez avec la version précédente et les conditions de déploiement.
3. Reproduisez le problème sur la route concernée avec Lighthouse et le waterfall réseau, puis identifiez la ressource ou le rendu qui a changé.
4. Si la régression est confirmée, bloquez la promotion ou revenez à la version stable selon votre procédure de déploiement ; corrigez puis comparez de nouveau avant toute remise en production.
5. Après correction, surveillez à nouveau les données de terrain et consignez la décision, la période et le résultat.

Une alerte doit déclencher une investigation, pas une correction automatique aveugle. Vérifiez d’abord la couverture de la collecte et le volume disponible, puis utilisez les audits reproductibles pour isoler la cause. N’acceptez pas une régression Lighthouse en vous appuyant uniquement sur une amélioration apparente d’un indicateur de terrain : les deux contrôles répondent à des questions complémentaires.

À retenir

• Les mesures de terrain complètent Lighthouse en décrivant des visites réelles et variées.
• Collectez uniquement les champs utiles, avec un endpoint contrôlé et une politique de confidentialité validée.
• Analysez les évolutions par route et par indicateur ; ne concluez pas à partir d’une mesure isolée.
• En cas de régression confirmée, bloquez ou annulez la mise en ligne, corrigez, puis vérifiez de nouveau avant promotion.

Vous disposez maintenant d’une boucle de suivi après déploiement : collecter, comparer, investiguer et corriger avant qu’une dégradation durable ne s’installe.