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

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2024-11-27

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.

nextjs css network

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

A estratégia worker é um recurso experimental que usa partytown https://partytown.builder.io/ para atuar como um proxy entre seus scripts e um web worker. O conceito é interessante, mas no momento provavelmente não está pronto para produção, pois ainda está em beta. Meu conselho sobre a estratégia worker no momento é ficar longe disso até que o projeto tenha amadurecido ou o DOM esteja disponível para web workers.

Stop debating in Jira.

Get a definitive answer on your performance issues. I deliver a granular breakdown of your critical rendering path.

Book a Deep Dive >>

  • Definitive Answers
  • Granular Breakdown
  • Critical Path Analysis
NextJS Core Web Vitals - corrigir scripts de terceirosCore Web Vitals NextJS Core Web Vitals - corrigir scripts de terceiros