Core Web Vitals meten in Next.js: RUM Setup Gids

Meet de Core Web Vitals in Next.js

Next.js is een JavaScript framework bovenop React waarmee je razendsnelle en extreem gebruiksvriendelijke websites kunt bouwen. Dat klopt, Next.js is behoorlijk snel en heeft veel ingebouwde functies om ervoor te zorgen dat het snel blijft. Tenminste, in theorie. Na verloop van tijd, naarmate je website groeit en er meer functies worden toegevoegd, en misschien wanneer niet alle best practices worden gevolgd, zullen Next.js pagina's steeds trager worden. Dat is waarschijnlijk de reden waarom je deze pagina bezoekt :-)

Laatst beoordeeld door Arjen Karel in maart 2026

Om trage pagina's te meten en te voorkomen, is het belangrijk om de Core Web Vitals te meten en actie te ondernemen wanneer een metric onder de drempelwaarde zakt. De drie Core Web Vitals zijn Largest Contentful Paint (LCP) voor laden (drempelwaarde: 2,5 seconden), Interaction to Next Paint (INP) voor interactiviteit (drempelwaarde: 200ms), en Cumulative Layout Shift (CLS) voor visuele stabiliteit (drempelwaarde: 0,1). Slechts 48% van de mobiele origins slaagt voor alle drie volgens de 2025 Web Almanac. Voor Next.js sites specifiek, toonde het 2023 Astro framework rapport aan dat slechts ongeveer 25% van de Next.js origins slaagde. Server Components en de App Router in Next.js 14 en 15 hebben dit verbeterd, maar het meten van je eigen velddata is de enige manier om te weten waar je staat.

Vergeet Lighthouse (min of meer)

Lighthouse is een testtool voor de Core Web Vitals. Bijna elke klant waar ik voor werk zal op een gegeven moment beginnen over hun Lighthouse scores en hoe deze niet overeenkomen met hun Search Console scores. Het eerste wat ik hen vertel is dit: vergeet Lighthouse. Ik zal het uitleggen:

Lighthouse is een zeer nuttige tool die 'lab data' verzamelt voor een niet-gecachet eerste bezoek onder gereguleerde omstandigheden. Helaas weerspiegelt de verzamelde data niet noodzakelijkerwijs de velddata. Velddata wordt door de browser verzameld elke keer dat een gebruiker een van je pagina's laadt. Die data wordt vervolgens naar Google gestuurd en gebruikt om je daadwerkelijke Core Web Vitals scores te bepalen. Dit proces wordt ook wel Real User Monitoring (RUM) genoemd.

Dit is wat de meeste developers over het hoofd zien: INP kan helemaal niet gemeten worden in lab tools. Lighthouse interacteert niet met je website, dus het heeft geen interactiedata. Het gebruikt Total Blocking Time als een proxy, maar TBT en INP zijn niet hetzelfde. CLS in lab tools toont ook kunstmatig lage scores omdat Lighthouse niet scrolt of rondklikt op de pagina. De enige manier om echte INP en CLS cijfers te krijgen is van echte gebruikers.

Begrijp me niet verkeerd: ik ben dol op Lighthouse. Het is een meesterlijk stuk software en het zal je geweldige suggesties geven die je waarschijnlijk zou moeten implementeren. Wat ik probeer te zeggen is dat de RUM metrics op een Next.js site niet simpelweg bestaan uit ongecachete weergaven van een eerste bezoek. Nee, de Core Web Vitals op een Next.js website zijn gecompliceerder. Dat is de reden waarom een van de eerste dingen die ik voor mijn klanten implementeer real-time Real User Monitoring is. Google rankt op basis van CrUX velddata, niet op Lighthouse scores.

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

Als je de App Router (Next.js 13+) gebruikt, is de aanbevolen manier om Core Web Vitals te verzamelen de useReportWebVitals hook uit next/web-vitals. Deze hook wordt standaard met Next.js meegeleverd, dus er is niets extra's om te installeren.

Omdat de hook de 'use client' directive vereist, is de best practice om deze te isoleren in een kleine component. Dit houdt de client boundary strak en voorkomt dat je hele layout een client component wordt:

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

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

Importeer het vervolgens in je root layout:

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

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

Dat is alles. Elke paginalading zal nu LCP, INP, CLS, FCP en TTFB in de console rapporteren. Natuurlijk is loggen in de console niet erg nuttig in productie. Laat me je zien hoe je de data naar een nuttige plek kunt sturen.

Core Web Vitals naar een custom endpoint sturen

De meest betrouwbare manier om performance data te versturen is navigator.sendBeacon(). Het is precies hiervoor ontworpen: het versturen van kleine payloads wanneer de gebruiker wegnavigeert van de pagina, zonder de navigatie te blokkeren.

// 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 naar Google Analytics (GA4) sturen

Als je Google Analytics 4 met de gtag snippet gebruikt, kun je Core Web Vitals als custom events versturen:

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

Onthoud goed: wanneer je de Core Web Vitals data uit een RUM bron leest, moet je het 75e percentiel gebruiken. Dat is de drempelwaarde die Google gebruikt. Niet het gemiddelde, niet de mediaan. De p75.

Sampling op websites met veel verkeer

Op websites met veel verkeer heeft het weinig zin om data van elke gebruiker te verzamelen. Je kunt een sample nemen van 50% of minder, zoals dit:

// 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 meten in Next.js (Pages Router)

Als je nog steeds de Pages Router gebruikt, biedt Next.js een ingebouwde reportWebVitals functie die je exporteert vanuit pages/_app.js. Dit is de oudere aanpak, maar het werkt nog steeds:

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

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

Dezelfde patronen voor het verzenden van data naar een custom endpoint of Google Analytics zijn hier van toepassing. Plaats simpelweg de sendBeacon of gtag aanroep binnen de reportWebVitals functie in plaats van de hook callback.

Eén ding om op te merken: de Pages Router rapporteert ook Next.js custom metrics zoals Next.js-hydration en Next.js-route-change-to-render. Deze vertellen je hoe lang hydration en client-side navigaties duren. De App Router versie rapporteert deze custom metrics nog niet.

Third-party monitoring tools

Er zijn een paar third-party tools die Core Web Vitals in Next.js verzamelen. Vercel heeft @vercel/speed-insights, wat direct out-of-the-box werkt als je op Vercel deployt. Het is prima voor een snel overzicht, maar het splitst metrics niet op in sub-onderdelen, de dashboards zijn basis, en je zit vast in het Vercel ecosysteem.

NewRelic en Sentry verzamelen beide Core Web Vitals, maar het zijn geen performance tools. Het zijn error tracking en APM tools die Core Web Vitals als extra feature hebben toegevoegd. Beide injecteren scripts die concurreren om vroege netwerkresources en main thread tijd. Ik heb gezien dat Sentry 200ms aan blocking time toevoegde op mobiel. Dat is ironisch voor een tool die je zou moeten helpen bij het monitoren van performance.

CoreDash is wat ik gebruik en aanbeveel. Het is specifiek gebouwd voor Core Web Vitals. Elke metric is opgesplitst in sub-onderdelen zodat je precies weet waar de tijd aan opgaat. De dashboards tonen je trends, regressies en specificaties op paginaniveau zonder door vijf menu's te hoeven klikken. En de MCP-integratie stelt je in staat om je velddata te koppelen aan AI-tools en vragen te stellen over je performance in gewone taal. Vraag simpelweg "wat veroorzaakt layout shifts op mobiel" en krijg het antwoord uit je eigen data.

Als je third-party script problemen wilt oplossen of render-blocking CSS wilt verwijderen in Next.js, heb ik daar ook specifieke gidsen voor geschreven.