De la donnée terrain aux traces : auditer la performance web

Dans ce scénario, une application Next.js sert des pages publiques et un espace connecté. Les tests locaux semblent corrects, mais le support remonte des interactions lentes sur mobile et les Core Web Vitals varient fortement d’une route à l’autre.

L’équipe a déjà appliqué les optimisations évidentes. Ajouter une checklist ne dira pas où le temps est réellement perdu ; l’audit part donc d’une expérience observée pour remonter jusqu’à une cause vérifiable.

Nous choisissons un parcours touché : ouvrir une fiche, modifier un filtre, puis afficher les résultats. Les données terrain indiquent quelle population rencontre la dégradation ; un test contrôlé rejoue ensuite la séquence avec un profil réseau et CPU représentatif.

Un INP dégradé peut venir d’un rendu React coûteux, d’une long task ou d’un script tiers. Un LCP tardif peut dépendre du temps serveur, de la découverte de la ressource ou de son décodage. La métrique resserre l’enquête, mais ne désigne pas seule le responsable.

L’investigation aboutit à une hypothèse testable pour une population et une action données. Une correction ciblée ne prétend pas accélérer toutes les pages.

Une mesure terrain devient exploitable avec une route normalisée, un build, une catégorie de viewport (mobile ou desktop), un type de navigation, un identifiant de page et des horodatages. Ces dimensions permettent de retrouver le bon segment sans collecter de données personnelles inutiles.

Elles ne prouvent pas qu’un Web Vital correspond à un span précis. Une liaison exacte exige un identifiant généré côté serveur, transmis au navigateur puis réutilisé sur les requêtes concernées. Sans cette propagation, les traces Next.js et OpenTelemetry restent utiles pour comparer la même route, le même build et la même fenêtre temporelle, mais cette comparaison doit être présentée comme telle.

import { onCLS, onINP, onLCP, type Metric } from 'web-vitals'

let registered = false

type ViewportClass = 'mobile' | 'desktop'

function getViewportClass(): ViewportClass {
    return matchMedia('(max-width: 767px)').matches
        ? 'mobile'
        : 'desktop'
}

export function registerWebVitals(normalizedRoute: string) {
    if (registered) return
    registered = true

    const pageId = crypto.randomUUID()
    const report = (metric: Metric) => {
        const payload = {
            route: normalizedRoute,
            build: process.env.NEXT_PUBLIC_BUILD_ID ?? 'dev',
            viewport: getViewportClass(),
            navigation: metric.navigationType,
            pageId,
            pageStartedAt: performance.timeOrigin,
            reportedAt: new Date().toISOString(),
            metric: {
                id: metric.id,
                name: metric.name,
                value: metric.value,
                rating: metric.rating,
            },
        }

        const body = new Blob([JSON.stringify(payload)], {
            type: 'application/json',
        })
        navigator.sendBeacon('/api/vitals', body)
    }

    onCLS(report)
    onINP(report)
    onLCP(report)
}

Ce callback s’enregistre une fois par chargement de document ; ce snippet ne mesure pas séparément chaque navigation client de l’App Router. L’identifiant de build doit être injecté au déploiement. Un bon diagnostic dépend de dimensions cohérentes et d’un niveau de certitude annoncé honnêtement.

L’audit avance parcours par parcours. Chaque étape produit un artefact que l’équipe peut relire ou mesurer : segment, capture de trace, hypothèse, diff ou résultat en production.

1. 01

   Qualifier le signal terrain

   Vérifier la collecte, séparer les routes et isoler la population concernée.

2. 02

   Reproduire le parcours

   Utiliser un scénario stable, un profil d’appareil crédible et le même build.

3. 03

   Localiser le temps perdu

   Croiser flame chart, React Profiler et spans serveur lorsque la requête est instrumentée.

4. 04

   Traiter une cause

   Réduire une long task, déplacer un calcul, corriger une cascade de requêtes ou prioriser une ressource.

5. 05

   Mesurer après livraison

   Comparer le même segment sur le nouveau build et conserver un garde-fou adapté.

Si le signal attendu ne bouge pas, l’hypothèse est rejetée et documentée. L’équipe évite ainsi de répéter une optimisation séduisante mais inefficace.

Produit, design et développement partagent les mêmes repères. Une alerte précise la population et l’action touchées ; une PR annonce le signal attendu. Le support peut transmettre la route, le build et la catégorie mobile ou desktop sans demander à l’utilisateur d’ouvrir DevTools.