Corrigir scripts de terceiros no Next.js para melhores Core Web Vitals

Corrigir scripts de terceiros no Next.js

Os scripts de terceiros são a causa mais comum de falhas de Core Web Vitals em sites Next.js de outra forma otimizados. Você fez tudo certo: imagens otimizadas, geração estática implementada, CSS crítico in-line. Mas o seu Interaction to Next Paint ainda falha. A causa é quase sempre o JavaScript de terceiros. De acordo com o 2025 Web Almanac, 92% das páginas carregam pelo menos um recurso de terceiros. Os scripts representam 24,8% de todas as solicitações de terceiros, mais do que qualquer outro tipo de recurso.

Revisado pela última vez por Arjen Karel em março de 2026

Pode ser devido a scripts de terceiros, como anúncios, análises, botões de mídia social, widgets, scripts de teste A/B, players de vídeo e assim por diante.

Como os scripts de terceiros impactam os Core Web Vitals

Os scripts de terceiros podem bagunçar os seus Core Web Vitals de mais maneiras do que você provavelmente pode imaginar. Estes são alguns dos problemas que encontro em sites ativos.

• Desaceleram a rede. Os scripts de terceiros podem enviar várias solicitações para vários servidores, baixar arquivos grandes não otimizados, como imagens e vídeos, baixar frameworks e bibliotecas várias vezes.
• JavaScript de terceiros pode bloquear o DOM a qualquer momento (ou até várias vezes durante uma visita à página), atrasando a rapidez com que as páginas podem ser renderizadas e usar muito tempo de CPU, o que pode atrasar a interação do usuário e causar esgotamento da bateria.
• Scripts de terceiros que bloqueiam a renderização podem ser um ponto único de falha (SPOF).
• Scripts de terceiros podem causar problemas de rede devido a cache HTTP mal configurado, falta de compactação de servidor suficiente e protocolos HTTP lentos ou desatualizados.
• Prejudicam a UX de muitas outras maneiras, como ocultar conteúdo, bloquear eventos do navegador (como o evento de carregamento da janela) ou usar APIs desatualizadas como document.write.

Os números são preocupantes. A equipe do Chrome Aurora descobriu que um contêiner do Google Tag Manager com 18 tags aumenta o Tempo Total de Bloqueio em quase 20 vezes. O 2025 Web Almanac relata um TBT móvel mediano de 1.916 ms, quase 10 vezes a melhor prática de 200 ms. Os scripts de terceiros são os principais contribuintes para esse número.

Corrigir scripts de terceiros e Core Web Vitals no Next.js

Idealmente, você deseja garantir que nenhum script de terceiros impacte o caminho de renderização crítico. Seu primeiro instinto seria usar o atributo defer ou async. Infelizmente, de uma perspectiva de tempo, esta não é uma boa opção para a maioria dos sites Next.js. Um site Next.js depende muito de JavaScript para hidratar a página.

Isso significa que assim que os bundles do Next.js forem baixados, o navegador executará esse JavaScript. Isso consome tempo e recursos. Este processo diminuirá de velocidade quando o navegador estiver muito ocupado compilando e executando JavaScript de terceiros.

O componente Script do Next.js

O componente Script do Next.js (next/script) lhe dá controle sobre quando os scripts de terceiros carregam em relação ao código do seu aplicativo. Em vez de lutar contra o comportamento de carregamento padrão do navegador, você escolhe uma estratégia que corresponda à importância do script.

Importe-o em qualquer componente:

import Script from 'next/script'

Estratégia

Com next/script, você decide quando carregar o seu script de terceiros usando a propriedade de estratégia. Existem quatro estratégias de carregamento:

• beforeInteractive: Carregar um script antes que a página seja interativa
• afterInteractive: Carregar um script imediatamente após a página se tornar interativa
• lazyOnload: Carregar um script durante o tempo ocioso
• worker: Carregar um script em um web worker (experimental, apenas Pages Router)

Estratégia beforeInteractive

Os scripts que carregam com a estratégia beforeInteractive são injetados no HTML inicial do servidor com o atributo defer habilitado e executados antes que o JavaScript auto-empacotado seja executado.

De uma perspectiva de Core Web Vitals, este é exatamente o tipo de comportamento que gostaríamos de evitar! A estratégia beforeInteractive só deve ser usada em scripts que são absolutamente críticos para a página. Scripts de terceiros nunca devem ser críticos!

<Script
  id="bootstrap-cdn"
  src="https://cdn.jsdelivr.net/npm/bootstrap@5.1.3/dist/js/bootstrap.bundle.min.js"
  strategy="beforeInteractive"
 />

Neste caso, a biblioteca JavaScript do bootstrap é adicionada ao HTML gerado com o atributo defer logo antes dos bundles do Next.js. Isso significa que o navegador provavelmente buscará e executará a biblioteca bootstrap antes do bundle do Next.js. Isso atrasará a hidratação do Next.js e provavelmente bloqueará a thread principal quando o navegador estiver baixando e executando os chunks do Next.js. Para os Core Web Vitals, isso significa que a Interaction to Next Paint provavelmente será afetada.

Estratégia afterInteractive

Os scripts que usam a estratégia afterInteractive são injetados no lado do cliente e serão baixados após o Next.js hidratar a página.

De uma perspectiva de Core Web Vitals, este é um local muito melhor (mas ainda não perfeito) para injetar scripts de terceiros. Esta estratégia deve ser usada para scripts que não precisam carregar o mais rápido possível e podem ser buscados e executados imediatamente após a página se tornar interativa.

<Script
  strategy="afterInteractive"
  dangerouslySetInnerHTML={{
    __html: `
    (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
    new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
    j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
    'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
    })(window,document,'script','dataLayer', 'GTM-XXXXXX');
  `,
  }}
/>

Para o Google Tag Manager e o Google Analytics, agora existe uma opção melhor. Veja a seção @next/third-parties abaixo.

Estratégia lazyOnload

Com a estratégia lazyOnload as coisas finalmente estão se tornando interessantes! A maneira como penso sobre scripts de terceiros é simples: 'eles não devem ser críticos para uma página'. Se você não consegue viver sem um certo script de terceiros, provavelmente não deve depender de um terceiro.

Os scripts que usam a estratégia lazyOnload são carregados tarde, após todos os recursos terem sido buscados e durante o tempo ocioso. Isso significa que o script de terceiros não interferirá com os chunks do Next.js e minimizará o impacto que este script tem na Interaction to Next Paint (INP).

<Script
  id="some-chat-script"
  src="https://example.com/chatscript.js"
  strategy="lazyOnload"
 />

Estratégia worker

A estratégia worker é um recurso experimental que usa o Partytown para executar scripts em um web worker em vez da thread principal. O conceito é interessante: a equipe do Chrome Aurora mediu uma redução de 92% no TBT ao mover o GTM para um web worker. Mas a estratégia worker só funciona com o Pages Router. Ela não suporta o App Router. Meu conselho: fique longe disso até que o projeto amadureça ou o DOM se torne disponível para os web workers.

@next/third-parties: a abordagem moderna

O Next.js agora fornece o pacote @next/third-parties com componentes otimizados para os serviços de terceiros mais comuns. Estes componentes lidam com a estratégia de carregamento internamente, portanto você não precisa configurá-la sozinho.

Instale-o:

npm install @next/third-parties

Para o Google Tag Manager, adicione o componente ao seu layout raiz:

import { GoogleTagManager } from '@next/third-parties/google'

export default function RootLayout({ children }) {
  return (
    <html>
      <GoogleTagManager gtmId="GTM-XXXXXX" />
      <body>{children}</body>
    </html>
  )
}

Para o Google Analytics:

import { GoogleAnalytics } from '@next/third-parties/google'

export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        {children}
        <GoogleAnalytics gaId="G-XXXXXX" />
      </body>
    </html>
  )
}

A equipe do Chrome Aurora relata que 66% dos sites Next.js usam o Google Tag Manager e 52% usam o Google Analytics. Se você estiver carregando qualquer um deles, use os componentes dedicados em vez do componente genérico Script com dangerouslySetInnerHTML. Se você usar o dataLayer do GTM, veja também o padrão de yield de INP do dataLayer para evitar que eventos de push bloqueiem interações.

Qual estratégia para qual script?

• GTM e GA: Use componentes @next/third-parties. Eles lidam com o tempo de carregamento internamente.
• Widgets de chat (Intercom, HubSpot, Drift): Use lazyOnload. Um widget de chat nunca é crítico para a primeira interação.
• Teste A/B (Optimizely, VWO): Use beforeInteractive apenas se o teste afetar o conteúdo above-the-fold. Caso contrário, use afterInteractive.
• Embeds sociais e players de vídeo: Use lazyOnload.
• Scripts de anúncios: Use afterInteractive. Os anúncios precisam carregar razoavelmente rápido para gerar receita, mas não devem bloquear a hidratação.

Nos sites Next.js monitorados pelo CoreDash, aqueles que usam lazyOnload para scripts de análise mostram uma melhoria mediana de INP de 27ms em comparação com afterInteractive. Essa é a diferença entre passar e falhar no limite de INP.

Qualquer que seja a estratégia que você escolher, verifique os resultados com Real User Monitoring. As pontuações de laboratório dizem o que pode acontecer. Os dados de campo dizem o que realmente aconteceu. E às vezes a melhor otimização é remover scripts que você não precisa.

Para saber mais sobre como medir o impacto, veja o guia sobre como medir os Core Web Vitals no Next.js. Se você também estiver lidando com CSS de bloqueio de renderização no Next.js, corrija isso primeiro. Para uma visão mais ampla de como o navegador decide o que buscar e quando, veja o guia de priorização de recursos.