NextJS Core Web Vitals - corrigir scripts de terceiros
O guia definitivo de NextJS Core Web Vitals - corrija problemas de Core Web Vitals causados por scripts de terceiros

Corrigir Scripts de Terceiros no NextJS
Scripts de terceiros são scripts que adicionam funcionalidades de terceiros aos seus sites. Muitas vezes, esses scripts são hospedados por terceiros, embora isso geralmente não seja estritamente necessário (você pode, por exemplo, hospedar o arquivo JavaScript de analytics). Scripts de terceiros fornecem uma ampla gama de funcionalidades úteis, tornando a web mais dinâmica, interativa e interconectada. Esses scripts podem ser cruciais para a funcionalidade ou receita do seu site. Mas scripts de terceiros também trazem muitos riscos que devem ser considerados para minimizar seu impacto e ainda fornecer valor.
Table of Contents!

Imagine: Você é o orgulhoso proprietário de um site Next.js otimizado. Você otimizou todo o seu código, implementou alguma forma de geração estática, otimizou todas as suas imagens, implementou Critical CSS, mas seu site ainda não passa nos Core Web Vitals. O que está acontecendo?
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 Scripts de Terceiros Impactam os Core Web Vitals
Scripts de terceiros podem prejudicar seus Core Web Vitals de mais formas do que você provavelmente imagina. Estes são alguns dos problemas que encontrei em sites reais.
- Tornar a rede lenta. Scripts de terceiros podem enviar múltiplas requisições para múltiplos 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 renderizar e usar tempo excessivo de CPU, o que pode atrasar a interação do usuário e causar consumo de 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/antigos
- Prejudicar a user experience de muitas outras formas, como esconder conteúdo, bloquear eventos do navegador (como o evento window load) ou usar APIs desatualizadas como document.write
Corrigir scripts de terceiros e Core Web Vitals no Next.js
Idealmente, você vai querer garantir que scripts de terceiros não estejam impactando o caminho crítico de renderização. Sua solução padrão seria usar o atributo defer ou async. Infelizmente, em termos de timing, esta 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 bundles do Next.js forem baixados, o navegador executará esse JavaScript. Isso consome tempo e recursos. Este processo ficará mais lento quando o navegador estiver muito ocupado compilando e executando JavaScripts de terceiros.
Apresentando o componente Script do Next.js
O componente Script do Next.js, next/script, é uma extensão do elemento HTML <script>. Ele permite que desenvolvedores definam a prioridade de carregamento de scripts de terceiros em qualquer lugar da aplicação, fora do next/head, economizando tempo do desenvolvedor e melhorando o desempenho de carregamento.
Para adicionar um script de terceiros à sua aplicação, importe o componente next/script:
import Script from 'next/script' Estratégia
Com next/script, você decide quando carregar seu script de terceiros usando a propriedade strategy:
Existem três estratégias de carregamento diferentes que podem ser usadas:
- beforeInteractive: Carregar um script antes da página ser 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
Estratégia beforeInteractive
Scripts que carregam com a estratégia beforeInteractive são injetados no HTML inicial do servidor com o atributo defer habilitado e executam antes do JavaScript empacotado ser executado.
Da perspectiva dos Core Web Vitals, este é 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 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 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 main thread quando o navegador deveria estar baixando e executando os chunks do Next.js. Para os Core Web Vitals, isso significa que o First Input Delay provavelmente será afetado.
Estratégia afterInteractive
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.
Da 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 carregar o mais rápido possível e podem ser buscados e executados imediatamente após a página ser 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');
`,
}}
/> Estratégia lazyOnload
Com a estratégia lazyOnload as coisas finalmente ficam 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 pode viver sem um determinado script de terceiros, provavelmente não deveria depender de um terceiro.
Scripts que usam a estratégia lazyOnload são carregados tardiamente após todos os recursos terem sido 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 no First Input Delay (FID)
<Script
id="some-chat-script"
src="https://example.com/chatscript.js"
strategy="lazyOnload"
/> Estratégia worker
Stop debating in Jira.
Get a definitive answer on your performance issues. I deliver a granular breakdown of your critical rendering path.
- Definitive Answers
- Granular Breakdown
- Critical Path Analysis

