Corrija Scripts de Terceiros no Next.js para Melhores Core Web Vitals

Corrija scripts de terceiros no Next.js

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

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

Pode ser por causa de scripts de terceiros como anúncios, analytics, botões de redes sociais, widgets, scripts de testes A/B, players de vídeo e assim por diante.

Como os scripts de terceiros impactam os Core Web Vitals

Scripts de terceiros podem arruinar seus Core Web Vitals de mais maneiras do que você provavelmente imagina. Estes são alguns dos problemas que encontro em sites reais.

• Desacelerar a rede. Scripts de terceiros podem enviar várias requisições para diversos servidores, baixar arquivos grandes não otimizados como imagens e vídeos, ou baixar frameworks e bibliotecas várias vezes.
• O JavaScript de terceiros pode bloquear o DOM a qualquer momento (ou até várias vezes durante a visita a uma página), atrasando a rapidez com que as páginas podem ser renderizadas e utilizando 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 compressão suficiente no servidor e protocolos HTTP lentos ou desatualizados.
• Prejudicar a user experience de muitas outras maneiras, como ocultando conteúdo, bloqueando eventos do navegador (como o evento window load) ou usando 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 Total Blocking Time quase 20 vezes. O Web Almanac 2025 relata um TBT mediano no mobile de 1.916 ms, quase 10x as práticas recomendadas de 200 ms. Scripts de terceiros são um grande contribuinte para esse número.

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

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

Isso significa que, assim que os pacotes do Next.js forem baixados, o navegador executará esse JavaScript. Isso consome tempo e recursos. Esse processo ficará mais lento quando o navegador estiver ocupado demais compilando e executando JavaScript de terceiros.

O componente Script do Next.js

O componente Script do Next.js (next/script) dá a você o controle sobre quando os scripts de terceiros carregam em relação ao código da sua aplicação. Em vez de lutar contra o comportamento padrão de carregamento 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 seu script de terceiros usando a propriedade strategy. Existem quatro estratégias de carregamento:

• beforeInteractive: Carregar um script antes de a página se tornar 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 no Pages Router)

Estratégia beforeInteractive

Scripts que carregam com a estratégia beforeInteractive são injetados no HTML inicial pelo servidor com o atributo defer ativado e são executados antes que o JavaScript empacotado da aplicação seja executado.

De uma perspectiva dos Core Web Vitals, esse é exatamente o tipo de comportamento que gostaríamos de evitar! A estratégia beforeInteractive deve ser usada apenas em scripts que são absolutamente críticos para a página. Scripts de terceiros nunca deveriam 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 pacotes do Next.js. Isso significa que o navegador provavelmente buscará e executará a biblioteca do bootstrap antes do pacote do Next.js. Isso atrasará a hidratação do Next.js e provavelmente bloqueará a main thread quando o navegador deveria estar 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

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

De uma perspectiva dos Core Web Vitals, este é um lugar muito melhor (mas ainda não perfeito) para injetar scripts de terceiros. Esta estratégia deve ser usada para scripts que não precisam ser carregados 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 estão finalmente ficando interessantes! A forma 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 deveria depender de terceiros.

Scripts que usam a estratégia lazyOnload são carregados tarde, depois que todos os recursos foram buscados e durante o tempo ocioso. Isso significa que o script de terceiros não interferirá nos 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 de na main thread. 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 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. Esses componentes lidam com a estratégia de carregamento internamente, para que você não precise configurá-la sozinho.

Instale-o:

npm install @next/third-parties

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

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 em 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ê usa o dataLayer do GTM, veja também o padrão de yield no INP para dataLayer para evitar que eventos de push bloqueiem interações.

Qual estratégia para qual script?

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

Em sites Next.js monitorados pelo CoreDash, aqueles que usam lazyOnload para scripts de analytics mostram uma melhoria mediana no INP de 27ms em comparação com afterInteractive. Essa é a diferença entre ser aprovado ou reprovado no limite do INP.

Seja qual for a estratégia escolhida, 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, consulte o guia sobre como medir 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.