Misurare i Core Web Vitals in Next.js: Guida alla Configurazione RUM

Configurare il Real User Monitoring per i Core Web Vitals in Next.js (App Router e Pages Router)

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-10

Misurare i Core Web Vitals in Next.js

Next.js è un framework JavaScript basato su React che ti consente di creare siti web superveloci ed estremamente user-friendly. È vero, Next.js è piuttosto veloce e ha molte funzionalità integrate per garantire che rimanga tale. Almeno in teoria. Nel tempo, man mano che il tuo sito web cresce, vengono aggiunte nuove funzionalità e magari non si seguono tutte le best practice, le pagine Next.js diventeranno sempre più lente. Questo è probabilmente il motivo per cui stai visitando questa pagina :-)

Ultima revisione di Arjen Karel a Marzo 2026

Per misurare e prevenire pagine lente è importante misurare i Core Web Vitals e intervenire quando una metrica è al di sotto della sua soglia. I tre Core Web Vitals sono Largest Contentful Paint (LCP) per il caricamento (soglia: 2,5 secondi), Interaction to Next Paint (INP) per l'interattività (soglia: 200ms) e Cumulative Layout Shift (CLS) per la stabilità visiva (soglia: 0,1). Solo il 48% delle origini mobile supera tutti e tre secondo il Web Almanac 2025. Per i siti Next.js in particolare, l'Astro framework report del 2023 ha rilevato che solo circa il 25% delle origini Next.js lo superava. I Server Components e l'App Router in Next.js 14 e 15 hanno migliorato la situazione, ma misurare i propri dati sul campo è l'unico modo per sapere a che punto ci si trova.

Dimentica Lighthouse (più o meno)

Lighthouse è un testing tool per i Core Web Vitals. Quasi tutti i clienti con cui lavoro, a un certo punto, iniziano a parlare dei loro punteggi Lighthouse e di come non corrispondano a quelli della Search Console. La prima cosa che dico loro è questa: dimenticate Lighthouse. Mi spiego:

lighthouse 100 score

Lighthouse è uno strumento molto utile che raccoglie 'dati di laboratorio' per una prima visita senza cache in condizioni controllate. Sfortunatamente i dati raccolti non riflettono necessariamente i dati sul campo. I dati sul campo vengono raccolti dal browser ogni volta che un utente carica una delle tue pagine. Questi dati vengono poi inviati a Google e utilizzati per determinare i tuoi veri punteggi dei Core Web Vitals. Questo processo è chiamato anche Real User Monitoring (RUM).

Ecco la cosa che sfugge alla maggior parte degli sviluppatori: l'INP non può essere misurato affatto nei tool di laboratorio. Lighthouse non interagisce con il tuo sito web, quindi non ha dati di interazione. Usa il Total Blocking Time come proxy, ma TBT e INP non sono la stessa cosa. Anche il CLS nei tool di laboratorio mostra punteggi artificialmente bassi perché Lighthouse non scorre né fa clic sulla pagina. L'unico modo per ottenere numeri INP e CLS reali è da utenti reali.

Non fraintendetemi: adoro Lighthouse. È un software magistrale e vi darà ottimi suggerimenti che probabilmente dovreste implementare. Quello che sto dicendo è che le metriche RUM su un sito Next.js non sono composte semplicemente da prime visualizzazioni senza cache. No, i Core Web Vitals su un sito Next.js sono più complessi. Questo è il motivo per cui una delle prime cose che implemento per i miei clienti è il Real User Monitoring in tempo reale. Google posiziona in base ai dati sul campo CrUX, non ai punteggi di Lighthouse.

Misurare i Core Web Vitals in Next.js (App Router)

Se stai utilizzando l'App Router (Next.js 13+), il modo consigliato per raccogliere i Core Web Vitals è l'hook useReportWebVitals da next/web-vitals. Questo hook è incluso in Next.js stesso, quindi non c'è nulla di extra da installare.

Poiché l'hook richiede la direttiva 'use client', la best practice è isolarlo in un piccolo componente. Questo mantiene stretto il confine del client ed evita di trasformare l'intero layout in un client component:

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

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

Quindi importalo nel tuo root layout:

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

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

Questo è tutto. Ogni caricamento della pagina ora riporterà LCP, INP, CLS, FCP e TTFB nella console. Ovviamente, registrare nella console non è molto utile in produzione. Lascia che ti mostri come inviare i dati da qualche parte di utile.

Inviare i Core Web Vitals a un endpoint personalizzato

Il modo più affidabile per inviare dati sulle prestazioni è navigator.sendBeacon(). È progettato esattamente per questo: inviare piccoli payload quando l'utente si allontana dalla pagina, senza bloccare la navigazione.

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

Inviare i Core Web Vitals a Google Analytics (GA4)

Se usi Google Analytics 4 con lo snippet gtag, puoi inviare i Core Web Vitals come eventi personalizzati:

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

Ricorda: quando leggi i dati dei Core Web Vitals da qualsiasi fonte RUM, devi utilizzare il 75° percentile. Questa è la soglia utilizzata da Google. Non la media, non la mediana. Il p75.

Campionamento su siti ad alto traffico

Sui siti web ad alto traffico non avrà molto senso raccogliere dati da ogni utente. Puoi campionarne il 50% o meno in questo modo:

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

Misurare i Core Web Vitals in Next.js (Pages Router)

Se sei ancora su Pages Router, Next.js fornisce una funzione integrata reportWebVitals che esporti da pages/_app.js. Questo è l'approccio più vecchio, ma funziona ancora:

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

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

Qui si applicano gli stessi pattern per inviare dati a un endpoint personalizzato o a Google Analytics. Inserisci semplicemente la chiamata sendBeacon o gtag all'interno della funzione reportWebVitals anziché nel callback dell'hook.

Una cosa da notare: il Pages Router riporta anche metriche personalizzate di Next.js come Next.js-hydration e Next.js-route-change-to-render. Queste ti indicano quanto tempo richiedono l'hydration e le navigazioni lato client. La versione App Router non riporta ancora queste metriche personalizzate.

Strumenti di monitoraggio di terze parti

Ci sono alcuni strumenti di terze parti che raccolgono i Core Web Vitals in Next.js. Vercel ha @vercel/speed-insights che funziona out of the box se fai il deploy su Vercel. Va bene per una rapida panoramica, ma non suddivide le metriche in sotto-parti, le dashboard sono basilari e sei bloccato nell'ecosistema Vercel.

NewRelic e Sentry raccolgono entrambi i Core Web Vitals ma non sono strumenti per le performance. Sono tool di tracciamento degli errori e APM che hanno integrato i Core Web Vitals come funzionalità. Entrambi iniettano script che competono per le prime risorse di rete e il tempo del main thread. Ho visto Sentry aggiungere 200ms di tempo di blocco su mobile. È ironico per uno strumento che dovrebbe aiutarti a monitorare le prestazioni.

CoreDash è ciò che uso e raccomando. È costruito specificamente per i Core Web Vitals. Ogni metrica è suddivisa in sotto-parti in modo da sapere esattamente dove va a finire il tempo. Le dashboard ti mostrano trend, regressioni e ripartizioni a livello di pagina senza dover cliccare su cinque menu. E l'integrazione MCP ti consente di collegare i tuoi dati sul campo agli strumenti di IA e fare domande sulle tue performance in linguaggio naturale. Chiedi semplicemente "cosa sta causando layout shift su mobile" e ottieni la risposta dai tuoi stessi dati.

Se vuoi risolvere i problemi con gli script di terze parti o rimuovere il CSS render-blocking in Next.js, ho scritto guide dedicate anche per questi.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

Find out what is actually slow.

I map your critical rendering path using real field data. You get a prioritized fix list, not a Lighthouse report.

Get the audit
Misurare i Core Web Vitals in Next.js: Guida alla Configurazione RUMCore Web Vitals Misurare i Core Web Vitals in Next.js: Guida alla Configurazione RUM