Meça os Core Web Vitals no Next.js: Guia de Configuração de RUM

Meça os Core Web Vitals no Next.js

O Next.js é um framework JavaScript baseado em React que permite construir sites super-rápidos e extremamente amigáveis. Isso é verdade, o Next.js é bem rápido e possui muitos recursos integrados para garantir que continue rápido. Pelo menos, na teoria. Com o tempo, à medida que seu site cresce e mais recursos são adicionados, e talvez quando nem todas as melhores práticas são seguidas, as páginas do Next.js se tornarão cada vez mais lentas. É provável que seja por isso que você está visitando esta página :-)

Última revisão por Arjen Karel em março de 2026

Para medir e prevenir páginas lentas, é importante medir os Core Web Vitals e agir quando uma métrica estiver abaixo do seu limite. Os três Core Web Vitals são o Largest Contentful Paint (LCP) para carregamento (limite: 2,5 segundos), o Interaction to Next Paint (INP) para interatividade (limite: 200ms) e o Cumulative Layout Shift (CLS) para estabilidade visual (limite: 0,1). Apenas 48% das origens mobile passam nos três, de acordo com o Web Almanac de 2025. Para sites Next.js especificamente, o relatório de frameworks da Astro de 2023 descobriu que apenas cerca de 25% das origens Next.js foram aprovadas. Server Components e o App Router no Next.js 14 e 15 melhoraram isso, mas medir os seus próprios dados de campo é a única maneira de saber onde você se encontra.

Esqueça o Lighthouse (ou quase isso)

O Lighthouse é uma ferramenta de testes para os Core Web Vitals. Quase todos os clientes com quem trabalho, em algum momento, começarão a falar sobre suas pontuações no Lighthouse e como elas não batem com as pontuações do Search Console. A primeira coisa que eu digo a eles é esta: esqueçam o Lighthouse. Eu explicarei:

O Lighthouse é uma ferramenta muito útil que coleta 'dados de laboratório' para uma primeira visita não armazenada em cache sob condições reguladas. Infelizmente, os dados coletados não refletem necessariamente os dados de campo. Os dados de campo são coletados pelo navegador toda vez que um usuário carrega uma de suas páginas. Esses dados são então enviados ao Google e usados para determinar suas pontuações reais nos Core Web Vitals. Esse processo também é chamado de Real User Monitoring (RUM).

Aqui está o ponto que a maioria dos desenvolvedores deixa passar: o INP não pode ser medido em ferramentas de laboratório de forma alguma. O Lighthouse não interage com o seu site, portanto, não possui dados de interação. Ele usa o Total Blocking Time como proxy, mas TBT e INP não são a mesma coisa. O CLS em ferramentas de laboratório também mostra pontuações artificialmente baixas porque o Lighthouse não rola a página nem clica nela. A única maneira de obter números reais de INP e CLS é a partir de usuários reais.

Não me entenda mal: eu adoro o Lighthouse. É um software magistral e lhe dará ótimas sugestões que você provavelmente deveria implementar. O que estou dizendo é que as métricas de RUM em um site Next.js não são compostas meramente por visualizações de primeira vez sem cache. Não, os Core Web Vitals em um site Next.js são mais complicados. É por isso que uma das primeiras coisas que implemento para os meus clientes é o Real User Monitoring em tempo real. O Google ranqueia com base nos dados de campo do CrUX, não nas pontuações do Lighthouse.

Meça os Core Web Vitals no Next.js (App Router)

Se você estiver usando o App Router (Next.js 13+), a maneira recomendada de coletar os Core Web Vitals é o hook useReportWebVitals de next/web-vitals. Esse hook vem nativo no próprio Next.js, então não há nada extra para instalar.

Como o hook requer a diretiva 'use client', a melhor prática é isolá-lo em um pequeno componente. Isso mantém o limite do cliente restrito e evita transformar todo o seu layout em um 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
}

Em seguida, importe-o no seu layout raiz:

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

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

É isso. Cada carregamento de página agora reportará LCP, INP, CLS, FCP e TTFB no console. Claro, registrar no console não é muito útil em produção. Deixe-me mostrar como enviar os dados para um lugar útil.

Envie os Core Web Vitals para um endpoint personalizado

A maneira mais confiável de enviar dados de desempenho é o navigator.sendBeacon(). Ele foi projetado exatamente para isso: enviar pequenos payloads quando o usuário navega para fora da página, sem bloquear a navegação.

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

Envie os Core Web Vitals para o Google Analytics (GA4)

Se você usa o Google Analytics 4 com o snippet do gtag, pode enviar os Core Web Vitals como eventos personalizados:

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

Lembre-se: ao ler os dados de Core Web Vitals de qualquer fonte de RUM, você precisa usar o percentil 75. Esse é o limite que o Google utiliza. Não a média, não a mediana. O p75.

Amostragem em sites de alto tráfego

Em sites de alto tráfego, fará pouco sentido coletar dados de todos os usuários. Você pode fazer uma amostragem de 50% ou menos desta forma:

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

Meça os Core Web Vitals no Next.js (Pages Router)

Se você ainda está no Pages Router, o Next.js fornece uma função reportWebVitals integrada que você exporta de pages/_app.js. Essa é a abordagem mais antiga, mas ainda funciona:

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

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

Os mesmos padrões para enviar dados a um endpoint personalizado ou ao Google Analytics se aplicam aqui. Basta colocar a chamada do sendBeacon ou gtag dentro da função reportWebVitals em vez do callback do hook.

Um ponto a ser observado: o Pages Router também relata métricas personalizadas do Next.js como Next.js-hydration e Next.js-route-change-to-render. Elas dizem quanto tempo a hidratação e as navegações no lado do cliente levam. A versão do App Router ainda não relata essas métricas personalizadas.

Ferramentas de monitoramento de terceiros

Existem algumas ferramentas de terceiros que coletam os Core Web Vitals no Next.js. A Vercel possui o @vercel/speed-insights que funciona de imediato se você realizar o deploy na Vercel. É bom para uma visão geral rápida, mas não divide as métricas em subpartes, os painéis são básicos e você fica preso ao ecossistema da Vercel.

Tanto o NewRelic quanto o Sentry coletam os Core Web Vitals, mas não são ferramentas de desempenho. Eles são ferramentas de rastreamento de erros e APM que adicionaram os Core Web Vitals como um recurso secundário. Ambos injetam scripts que competem por recursos iniciais de rede e tempo da thread principal. Eu já vi o Sentry adicionar 200ms de tempo de bloqueio em dispositivos móveis. Isso é irônico para uma ferramenta que deveria ajudá-lo a monitorar o desempenho.

O CoreDash é o que eu uso e recomendo. Ele foi construído especificamente para os Core Web Vitals. Cada métrica é dividida em subpartes para que você saiba exatamente para onde vai o tempo. Os painéis mostram tendências, regressões e análises no nível da página sem precisar clicar por cinco menus. E a integração MCP permite que você conecte os seus dados de campo a ferramentas de IA e faça perguntas sobre o seu desempenho em linguagem natural. Basta perguntar "o que está causando layout shifts em dispositivos móveis" e obter a resposta dos seus próprios dados.

Se você quiser corrigir problemas com scripts de terceiros ou remover CSS que bloqueia a renderização no Next.js, eu escrevi guias dedicados para eles também.