Mesurer les Core Web Vitals dans Next.js : Guide de configuration RUM

Mesurer les Core Web Vitals dans Next.js

Next.js est un framework JavaScript basé sur React qui vous permet de créer des sites web ultra-rapides et extrêmement conviviaux. C'est vrai, Next.js est plutôt rapide et intègre de nombreuses fonctionnalités pour garantir qu'il le reste. Du moins, en théorie. Au fil du temps, à mesure que votre site web grandit, que de nouvelles fonctionnalités sont ajoutées et peut-être lorsque toutes les bonnes pratiques ne sont pas suivies, les pages Next.js deviendront de plus en plus lentes. C'est probablement pour cette raison que vous visitez cette page :-)

Dernière révision par Arjen Karel en mars 2026

Pour mesurer et prévenir la lenteur des pages, il est important de mesurer les Core Web Vitals et de prendre des mesures lorsqu'une métrique est inférieure à son seuil. Les trois Core Web Vitals sont le Largest Contentful Paint (LCP) pour le chargement (seuil : 2,5 secondes), l'Interaction to Next Paint (INP) pour l'interactivité (seuil : 200 ms), et le Cumulative Layout Shift (CLS) pour la stabilité visuelle (seuil : 0,1). Seulement 48 % des origines mobiles réussissent les trois selon le Web Almanac 2025. Pour les sites Next.js en particulier, le rapport sur les performances des frameworks Astro 2023 a révélé qu'environ 25 % seulement des origines Next.js ont réussi. Les Server Components et l'App Router dans Next.js 14 et 15 ont amélioré cela, mais mesurer vos propres données de terrain est le seul moyen de savoir où vous en êtes.

Oubliez Lighthouse (en quelque sorte)

Lighthouse est un outil de test pour les Core Web Vitals. Presque tous les clients avec lesquels je travaille finiront, à un moment donné, par parler de leurs scores Lighthouse et du fait qu'ils ne correspondent pas à leurs scores Search Console. La première chose que je leur dis est la suivante : oubliez Lighthouse. Je vais vous expliquer :

Lighthouse est un outil très utile qui recueille des 'données de laboratoire' pour une première visite non mise en cache dans des conditions régulées. Malheureusement, les données recueillies ne reflètent pas nécessairement les données de terrain. Les données de terrain sont collectées par le navigateur à chaque fois qu'un utilisateur charge l'une de vos pages. Ces données sont ensuite envoyées à Google et utilisées pour déterminer vos véritables scores Core Web Vitals. Ce processus est également appelé Real User Monitoring (RUM).

Voici la chose que la plupart des développeurs omettent : l'INP ne peut pas du tout être mesuré dans les outils de laboratoire. Lighthouse n'interagit pas avec votre site web, il n'a donc aucune donnée d'interaction. Il utilise le Total Blocking Time comme approximation, mais le TBT et l'INP ne sont pas la même chose. Le CLS dans les outils de laboratoire affiche également des scores artificiellement bas car Lighthouse ne fait pas défiler la page et ne clique pas dessus. La seule façon d'obtenir de vrais chiffres INP et CLS est à partir d'utilisateurs réels.

Ne vous méprenez pas : j'adore Lighthouse. C'est un logiciel magistral et il vous donnera d'excellentes suggestions que vous devriez probablement implémenter. Ce que je dis, c'est que les métriques RUM sur un site Next.js ne sont pas simplement constituées de premières vues non mises en cache. Non, les Core Web Vitals sur un site web Next.js sont plus complexes. C'est pourquoi l'une des premières choses que j'implémente pour mes clients est un Real User Monitoring en temps réel. Google effectue son classement sur la base des données de terrain CrUX, et non sur les scores Lighthouse.

Mesurer les Core Web Vitals dans Next.js (App Router)

Si vous utilisez l'App Router (Next.js 13+), la méthode recommandée pour collecter les Core Web Vitals est le hook useReportWebVitals de next/web-vitals. Ce hook est fourni avec Next.js lui-même, il n'y a donc rien de plus à installer.

Étant donné que le hook nécessite la directive 'use client', la bonne pratique consiste à l'isoler dans un petit composant. Cela maintient la frontière client stricte et évite de faire de toute votre mise en page un composant client :

// app/_components/web-vitals.js
'use client'
import { useReportWebVitals } from 'next/web-vitals'

export function WebVitals() {
  useReportWebVitals((metric) => {
    console.log(metric)
  })
  return null
}

Ensuite, importez-le dans votre layout racine :

// app/layout.js
import { WebVitals } from './_components/web-vitals'

export default function Layout({ children }) {
  return (
    <html>
      <body>
        <WebVitals />
        {children}
      </body>
    </html>
  )
}

C'est tout. Chaque chargement de page signalera désormais le LCP, l'INP, le CLS, le FCP et le TTFB dans la console. Bien sûr, la journalisation dans la console n'est pas très utile en production. Laissez-moi vous montrer comment envoyer les données vers un endroit utile.

Envoyer les Core Web Vitals à un endpoint personnalisé

Le moyen le plus fiable d'envoyer des données de performance est navigator.sendBeacon(). Il est conçu exactement pour cela : envoyer de petites payloads lorsque l'utilisateur quitte la page, sans bloquer la navigation.

// app/_components/web-vitals.js
'use client'
import { useReportWebVitals } from 'next/web-vitals'

export function WebVitals() {
  useReportWebVitals((metric) => {
    const url = 'https://example.com/analytics'
    const body = JSON.stringify(metric)
    if (navigator.sendBeacon) {
      navigator.sendBeacon(url, body)
    } else {
      fetch(url, { body: body, method: 'POST', keepalive: true })
    }
  })
  return null
}

Envoyer les Core Web Vitals à Google Analytics (GA4)

Si vous utilisez Google Analytics 4 avec le snippet gtag, vous pouvez envoyer les Core Web Vitals en tant qu'événements personnalisés :

// app/_components/web-vitals.js
'use client'
import { useReportWebVitals } from 'next/web-vitals'

export function WebVitals() {
  useReportWebVitals((metric) => {
    window.gtag('event', metric.name, {
      event_category: 'Web Vitals',
      value: Math.round(metric.name === 'CLS' ? metric.value * 1000 : metric.value),
      event_label: metric.id,
      non_interaction: true,
    })
  })
  return null
}

N'oubliez pas : lorsque vous lisez les données des Core Web Vitals à partir de n'importe quelle source RUM, vous devez utiliser le 75ème percentile. C'est le seuil que Google utilise. Ni la moyenne, ni la médiane. Le p75.

Échantillonnage sur les sites à fort trafic

Sur les sites web à fort trafic, il sera peu judicieux de collecter les données de chaque utilisateur. Vous pouvez échantillonner à 50 % ou moins comme ceci :

// app/_components/web-vitals.js
'use client'
import { useReportWebVitals } from 'next/web-vitals'

const inSample = Math.random() >= 0.5

export function WebVitals() {
  useReportWebVitals((metric) => {
    if (inSample) {
      const body = JSON.stringify(metric)
      navigator.sendBeacon('/analytics', body)
    }
  })
  return null
}

Mesurer les Core Web Vitals dans Next.js (Pages Router)

Si vous êtes toujours sur le Pages Router, Next.js fournit une fonction reportWebVitals intégrée que vous exportez depuis pages/_app.js. C'est l'ancienne approche mais elle fonctionne toujours :

// pages/_app.js
export function reportWebVitals(metric) {
  if (metric.label === 'web-vital') {
    console.log(metric)
  }
}

export default function App({ Component, pageProps }) {
  return <Component {...pageProps} />
}

Les mêmes modèles pour envoyer des données à un endpoint personnalisé ou à Google Analytics s'appliquent ici. Mettez simplement l'appel sendBeacon ou gtag à l'intérieur de la fonction reportWebVitals au lieu du callback du hook.

Une chose à noter : le Pages Router signale également des métriques personnalisées Next.js telles que Next.js-hydration et Next.js-route-change-to-render. Celles-ci vous indiquent combien de temps prennent l'hydratation et les navigations côté client. La version App Router ne signale pas encore ces métriques personnalisées.

Outils de monitoring tiers

Il existe quelques outils tiers qui collectent les Core Web Vitals dans Next.js. Vercel a @vercel/speed-insights qui fonctionne de base si vous déployez sur Vercel. C'est très bien pour un aperçu rapide, mais cela ne décompose pas les métriques en sous-parties, les tableaux de bord sont basiques, et vous êtes enfermé dans l'écosystème Vercel.

NewRelic et Sentry collectent tous deux les Core Web Vitals mais ce ne sont pas des outils de performance. Ce sont des outils de suivi des erreurs et d'APM qui ont ajouté les Core Web Vitals en tant que fonctionnalité. Tous deux injectent des scripts qui entrent en compétition pour les ressources réseau précoces et le temps du thread principal. J'ai vu Sentry ajouter 200 ms de temps de blocage sur mobile. C'est ironique pour un outil censé vous aider à surveiller les performances.

CoreDash est ce que j'utilise et recommande. Il est conçu spécifiquement pour les Core Web Vitals. Chaque métrique est décomposée en sous-parties afin que vous sachiez exactement où va le temps. Les tableaux de bord vous montrent les tendances, les régressions et les répartitions au niveau de la page sans avoir à cliquer sur cinq menus. Et l'intégration MCP vous permet de connecter vos données de terrain à des outils d'IA et de poser des questions sur vos performances en langage clair. Demandez simplement "qu'est-ce qui cause des décalages de mise en page sur mobile" et obtenez la réponse à partir de vos propres données.

Si vous souhaitez résoudre les problèmes de scripts tiers ou supprimer le CSS bloquant le rendu dans Next.js, j'ai également écrit des guides dédiés pour cela.