Core Web Vitals in Next.js messen: RUM Setup-Guide

Die Core Web Vitals in Next.js messen

Next.js ist ein JavaScript-Framework auf Basis von React, das es Ihnen ermöglicht, superschnelle und extrem nutzerfreundliche Websites zu erstellen. Das stimmt, Next.js ist ziemlich schnell und hat viele integrierte Funktionen, um sicherzustellen, dass es auch schnell bleibt. Zumindest in der Theorie. Mit der Zeit, wenn Ihre Website wächst und mehr Funktionen hinzugefügt werden und vielleicht nicht alle Best Practices befolgt werden, werden Next.js-Seiten immer langsamer. Das ist wahrscheinlich der Grund, warum Sie diese Seite besuchen :-)

Zuletzt überprüft von Arjen Karel im März 2026

Um langsame Seiten zu messen und zu verhindern, ist es wichtig, die Core Web Vitals zu messen und Maßnahmen zu ergreifen, wenn eine Metrik unter ihrem Schwellenwert liegt. Die drei Core Web Vitals sind Largest Contentful Paint (LCP) für das Laden (Schwellenwert: 2,5 Sekunden), Interaction to Next Paint (INP) für die Interaktivität (Schwellenwert: 200ms) und Cumulative Layout Shift (CLS) für die visuelle Stabilität (Schwellenwert: 0,1). Nur 48 % der mobilen Origins bestehen alle drei laut dem Web Almanac 2025. Speziell für Next.js-Websites ergab der Astro-Framework-Bericht 2023, dass nur etwa 25 % der Next.js-Origins bestanden haben. Server Components und der App Router in Next.js 14 und 15 haben dies verbessert, aber die Messung Ihrer eigenen Felddaten ist der einzige Weg, um zu wissen, wo Sie stehen.

Vergessen Sie Lighthouse (irgendwie)

Lighthouse ist ein Test-Tool für die Core Web Vitals. Fast jeder Kunde, mit dem ich zusammenarbeite, fängt irgendwann an, über seine Lighthouse-Scores zu sprechen und darüber, dass diese nicht mit den Search Console-Scores übereinstimmen. Das Erste, was ich ihnen sage, ist: Vergessen Sie Lighthouse. Ich erkläre es Ihnen:

Lighthouse ist ein sehr nützliches Tool, das 'Labordaten' für einen nicht gecachten Erstbesuch unter regulierten Bedingungen sammelt. Leider spiegeln die gesammelten Daten nicht zwangsläufig die Felddaten wider. Felddaten werden vom Browser jedes Mal gesammelt, wenn ein Nutzer eine Ihrer Seiten lädt. Diese Daten werden dann an Google gesendet und zur Bestimmung Ihrer tatsächlichen Core Web Vitals-Scores verwendet. Dieser Prozess wird auch Real User Monitoring (RUM) genannt.

Hier ist der Punkt, den die meisten Entwickler übersehen: INP kann in Labor-Tools überhaupt nicht gemessen werden. Lighthouse interagiert nicht mit Ihrer Website, also gibt es keine Interaktionsdaten. Es verwendet die Total Blocking Time als Proxy, aber TBT und INP sind nicht dasselbe. Auch der CLS in Labor-Tools zeigt künstlich niedrige Werte, weil Lighthouse nicht auf der Seite scrollt oder herumklickt. Der einzige Weg, echte INP- und CLS-Zahlen zu erhalten, sind echte Nutzer.

Verstehen Sie mich nicht falsch: Ich liebe Lighthouse. Es ist ein meisterhaftes Stück Software und liefert Ihnen großartige Vorschläge, die Sie wahrscheinlich umsetzen sollten. Was ich sagen will, ist, dass sich die RUM-Metriken auf einer Next.js-Site nicht nur aus ungespeicherten Erstansichten zusammensetzen. Nein, die Core Web Vitals auf einer Next.js-Website sind komplizierter. Deshalb ist eines der ersten Dinge, die ich für meine Kunden implementiere, Real User Monitoring in Echtzeit. Google rankt basierend auf CrUX-Felddaten, nicht auf Lighthouse-Scores.

Core Web Vitals in Next.js messen (App Router)

Wenn Sie den App Router (Next.js 13+) verwenden, ist der empfohlene Weg, Core Web Vitals zu sammeln, der useReportWebVitals-Hook von next/web-vitals. Dieser Hook wird mit Next.js selbst ausgeliefert, es muss also nichts extra installiert werden.

Da der Hook die 'use client'-Direktive erfordert, ist es die Best Practice, ihn in einer kleinen Komponente zu isolieren. Das hält die Client-Grenze eng und vermeidet, dass Ihr gesamtes Layout zu einer Client-Komponente wird:

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

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

Importieren Sie es dann in Ihr Root-Layout:

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

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

Das war's. Jeder Seitenaufruf wird nun LCP, INP, CLS, FCP und TTFB in die Konsole ausgeben. Natürlich ist das Loggen in die Konsole in der Produktion nicht sehr nützlich. Lassen Sie mich Ihnen zeigen, wie Sie die Daten an einen nützlichen Ort senden.

Core Web Vitals an einen eigenen Endpunkt senden

Der zuverlässigste Weg, um Performance-Daten zu senden, ist navigator.sendBeacon(). Es wurde genau dafür entwickelt: kleine payloads zu senden, wenn der Nutzer die Seite verlässt, ohne die Navigation zu blockieren.

// 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
}

Core Web Vitals an Google Analytics (GA4) senden

Wenn Sie Google Analytics 4 mit dem gtag-Snippet verwenden, können Sie Core Web Vitals als benutzerdefinierte Events senden:

// 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
}

Denken Sie daran: Wenn Sie die Core Web Vitals-Daten aus einer beliebigen RUM-Quelle auslesen, müssen Sie das 75. Perzentil verwenden. Das ist der Schwellenwert, den Google verwendet. Nicht den Durchschnitt, nicht den Median. Das p75.

Sampling auf Websites mit hohem Traffic

Auf Websites mit hohem Traffic macht es wenig Sinn, Daten von jedem Nutzer zu sammeln. Sie können ein Sampling von 50 % oder weniger wie folgt durchführen:

// 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
}

Core Web Vitals in Next.js messen (Pages Router)

Wenn Sie noch den Pages Router verwenden, bietet Next.js eine integrierte reportWebVitals-Funktion, die Sie aus pages/_app.js exportieren. Dies ist der ältere Ansatz, aber er funktioniert immer noch:

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

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

Hier gelten die gleichen Muster für das Senden von Daten an einen benutzerdefinierten Endpunkt oder Google Analytics. Setzen Sie einfach den sendBeacon- oder gtag-Aufruf in die reportWebVitals-Funktion anstatt in den Hook-Callback.

Eine Sache ist zu beachten: Der Pages Router meldet auch benutzerdefinierte Next.js-Metriken wie Next.js-hydration und Next.js-route-change-to-render. Diese geben an, wie lange die Hydration und clientseitige Navigationen dauern. Die App Router-Version meldet diese benutzerdefinierten Metriken noch nicht.

Monitoring-Tools von Drittanbietern

Es gibt einige Drittanbieter-Tools, die Core Web Vitals in Next.js sammeln. Vercel bietet @vercel/speed-insights an, das sofort funktioniert, wenn Sie auf Vercel deployen. Es ist in Ordnung für einen schnellen Überblick, aber es unterteilt die Metriken nicht in Unterkomponenten, die Dashboards sind einfach gehalten und Sie sind an das Vercel-Ökosystem gebunden.

NewRelic und Sentry sammeln beide Core Web Vitals, aber sie sind keine Performance-Tools. Es sind Error-Tracking- und APM-Tools, die Core Web Vitals als nachträgliches Feature hinzugefügt haben. Beide injizieren Skripte, die um frühe Netzwerkressourcen und Main-Thread-Zeit konkurrieren. Ich habe gesehen, wie Sentry auf Mobilgeräten 200ms an Blockierzeit hinzufügt. Das ist ironisch für ein Tool, das Ihnen eigentlich helfen soll, die Performance zu überwachen.

CoreDash ist das, was ich verwende und empfehle. Es wurde speziell für Core Web Vitals entwickelt. Jede Metrik wird in Unterkomponenten aufgeschlüsselt, damit Sie genau wissen, wohin die Zeit fließt. Die Dashboards zeigen Ihnen Trends, Regressionen und Aufschlüsselungen auf Seitenebene, ohne dass Sie sich durch fünf Menüs klicken müssen. Und die MCP-Integration ermöglicht es Ihnen, Ihre Felddaten in KI-Tools einzuspeisen und in natürlicher Sprache Fragen zu Ihrer Performance zu stellen. Fragen Sie einfach "Was verursacht Layoutverschiebungen auf Mobilgeräten?" und erhalten Sie die Antwort aus Ihren eigenen Daten.

Wenn Sie Probleme mit Drittanbieter-Skripten beheben oder Render-blockierendes CSS entfernen möchten in Next.js, habe ich dafür ebenfalls spezielle Anleitungen geschrieben.