Esta p�gina foi traduzida pela API Cloud Translation.

Um pacote Next.js para gerenciar bibliotecas de terceiros

Houssein Djirdeh

Em 2021, a equipe do Chrome Aurora introduziu o Script componente para melhorar a ao carregar o desempenho de scripts de terceiros no Next.js. Desde o lan�amento, expandiu suas capacidades para facilitar o carregamento de recursos de terceiros e mais rapidamente para os desenvolvedores.

Esta postagem do blog fornece uma vis�o geral dos recursos mais recentes que lan�amos, especialmente a @next/third-parties , bem como um esbo�o de iniciativas futuras em nosso roteiro.

Implica��es no desempenho de scripts de terceiros

41% de todas as solicita��es de terceiros nos sites Next.js s�o scripts. Ao contr�rio de outros conte�dos tipos, o download e a execu��o dos scripts pode levar um tempo consider�vel, o que pode bloquear a renderiza��o e atrasar a interatividade do usu�rio. Dados do Chrome O Relat�rio de experi�ncia do usu�rio (CrUX, na sigla em ingl�s) mostra que os sites do Next.js que carregam mais sites de terceiros os scripts t�m menor Intera��o com a Pr�xima Paint (INP) e Maior exibi��o de conte�do (LCP).

Gr�fico de barras que mostra uma redu��o na porcentagem de Next.js que alcan�a boas pontua��es de INP e LCP em propor��o ao n�mero de terceiros carregados — Relat�rio CrUX de dezembro de 2023 (110.823 sites)

A correlação observada neste gráfico não implica causalidade. No entanto, as campanhas locais os experimentos fornecem evidências adicionais de que scripts de terceiros afetar o desempenho da página. Por exemplo, a tabela abaixo compara vários laboratórios quando um contêiner do Gerenciador de tags do Google, composto por 18 itens selecionados aleatoriamente, é adicionada à Taxonomy, um exemplo conhecido do Next.js. app.

Gráfico de barras que mostra a diferença em várias métricas do laboratório quando um site é carregado com e sem o Gerenciador de tags do Google. — WebPageTest (Dispositivos móveis 4G - Virgínia, EUA)

Documentação do WebPageTest fornece detalhes sobre como esses tempos são medidos. Olhando rapidamente, é que todas essas métricas do laboratório são afetadas pelo contêiner do GTM. Para exemplo, Total Blocking Time (TBT), um laboratório útil que se aproxime do INP, teve um aumento de quase 20 vezes.

Componente de script

Quando enviamos o componente <Script> no Next.js, introduzimos por uma API fácil de usar que se assemelha ao <script> tradicional. . Com ele, os desenvolvedores podem colocalizar um script de terceiros em qualquer no aplicativo, e o Next.js fará o sequenciamento script após o carregamento dos recursos críticos.

<!-- By default, script will load after page becomes interactive -->
<Script src="https://example.com/sample.js" />

<!-- Script is injected server-side and fetched before any page hydration occurs -->
<Script strategy=”beforeInteractive” src="https://example.com/sample.js" />

<!-- Script is fetched later during browser idle time -->
<Script strategy=”lazyOnload” src="https://example.com/sample.js" />

Dezenas de milhares de aplicativos Next.js, incluindo sites populares como Patreon, Target e No��o: use o componente <Script>. Apesar da da efic�cia, alguns desenvolvedores levantaram preocupa��es sobre os seguintes coisas:

Onde colocar o componente <Script> em um app Next.js enquanto obedece as instru��es de instala��o variadas de provedores terceirizados (experi�ncia do desenvolvedor).
Qual estrat�gia de carregamento � a ideal para casos diferentes scripts de terceiros (experi�ncia do usu�rio).

Para lidar com essas duas preocupa��es, lan�amos o @next/third-parties, um biblioteca especializada que oferece um conjunto de componentes e utilit�rios otimizados personalizado para terceiros conhecidos.

Experi�ncia do desenvolvedor: como facilitar o gerenciamento de bibliotecas de terceiros

Muitos scripts de terceiros s�o usados em uma porcentagem significativa dos sites Next.js, com o Gerenciador de tags do Google � o mais usado, 66% dos sites, respectivamente. O @next/third-parties se baseia no <Script>. introduzindo wrappers de n�vel superior projetados para simplificar o uso para esses casos de uso comuns.

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

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

Google Analytics, outro script de terceiros amplamente utilizado (52% dos sites do Next.js) tamb�m tem um componente dedicado.

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

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

O @next/third-parties simplifica o processo de carregamento de scripts usados com frequ�ncia. mas tamb�m amplia nossa capacidade de desenvolver utilit�rios para categorias, como incorpora��es. Por exemplo, as incorpora��es do Google Maps e do YouTube s�o usado em 8% e 4% de sites Next.js, e tamb�m enviamos componentes para torn�-los mais f�ceis de carregar.

import { GoogleMapsEmbed } from "@next/third-parties/google";
import { YouTubeEmbed } from "@next/third-parties/google";

export default function Page() {
  return (
    <>
      <GoogleMapsEmbed
        apiKey="XYZ"
        height={200}
        width="100%"
        mode="place"
        q="Brooklyn+Bridge,New+York,NY"
      />
      <YouTubeEmbed videoid="ogfYd705cRs" height={400} params="controls=0" />
    </>
  );
}

Experi�ncia do usu�rio: carregamento mais r�pido de bibliotecas de terceiros

Em um mundo perfeito, toda biblioteca terceirizada amplamente adotada seria otimizados, tornando desnecess�rias todas as abstra��es que melhoram o desempenho. No entanto, at� que isso se torne realidade, podemos tentar melhorar integrada com frameworks conhecidos, como Next.js. Podemos testar diferentes t�cnicas de carregamento, garantir que os scripts sejam sequenciados da maneira correta e, por fim, compartilhar nossos feedbacks com terceiros provedores para incentivar mudan�as upstream.

Veja as incorpora��es do YouTube, por exemplo. Em que algumas implementa��es alternativas desempenho muito melhor do que a incorpora��o nativa. No momento, a vers�o <YouTubeEmbed> o componente exportado por @next/third-parties usa lite-youtube-embed, que, quando demonstrado em uma demonstra��o com o Next.js, carrega consideravelmente mais r�pido.

GIF que mostra a compara��o de carregamento da p�gina entre o componente de incorpora��o do YouTube e um iframe normal do YouTube — WebPageTest (Dispositivos m�veis 4G - Virg�nia, EUA)

Da mesma forma, para o Google Maps, inclu�mos loading="lazy" como um atributo padr�o para o incorporado para garantir que o mapa s� carregue quando estiver a uma determinada dist�ncia do na janela de visualiza��o. Isso pode parecer um atributo �bvio a ser inclu�do, especialmente j� que o SDK do Google Maps documenta��o inclu�-lo no snippet de c�digo de exemplo, mas apenas 45% dos sites da Next.js que incorporam o Google Maps usam o loading="lazy".

Como executar scripts de terceiros em um worker da Web

Uma t�cnica avan�ada que estamos explorando no @next/third-parties � torn�-la descarregar os scripts de terceiros em um web worker. Popularizado por bibliotecas, como Partytown, isso pode reduzir o impacto de scripts de terceiros no desempenho da p�gina de forma significativa, realocando-os totalmente da linha de execu��o principal.

O GIF animado a seguir mostra as varia��es nas tarefas longas e na linha de execu��o principal tempo de bloqueio ao aplicar diferentes estrat�gias do <Script> a um cont�iner do GTM em um site do Next.js. Enquanto voc� alterna apenas entre as op��es de estrat�gia, atrasa o tempo de execu��o desses scripts, realocando-os para um web worker elimina completamente o tempo que eles t�m na linha de execu��o principal.

GIF que mostra as diferen�as no tempo de bloqueio da linha de execu��o principal para as diferentes estrat�gias de script — WebPageTest (Dispositivos m�veis 4G - Virg�nia, EUA)

Neste exemplo espec�fico, mover a execu��o do cont�iner do GTM e seu scripts de tags associados a um worker da Web reduziu o TBT em 92%.

� importante ressaltar que, se n�o for administrada com cuidado, essa t�cnica pode quebrar muitos scripts de terceiros, o que dificulta a depura��o. Nos pr�ximos meses, vamos validar se h� componentes de terceiros oferecidos pela @next/third-parties funcionem corretamente quando executados em um web worker. Nesse caso, vamos trabalham para oferecer aos desenvolvedores uma maneira f�cil e opcional de usar t�cnica.

Pr�ximas etapas

No processo de desenvolvimento desse pacote, ficou evidente que havia precisam centralizar recomenda��es de carregamento de terceiros para que outras estruturas tamb�m podem se beneficiar das mesmas t�cnicas usadas. Isso nos levou a criar servi�os de Capital: uma biblioteca. que usa JSON para descrever t�cnicas de carregamento de terceiros, que atualmente serve como base para @next/third-parties.

Nas pr�ximas etapas, continuaremos a nos concentrar na melhoria dos componentes fornecidos para Next.js, al�m de expandir nossos esfor�os para incluir utilit�rios semelhantes em outros estruturas e plataformas de CMS conhecidas. No momento, estamos em colabora��o com a Nuxt mantenedores e planejam lan�ar utilit�rios de terceiros semelhantes ao ecossistema em breve.

Se um dos terceiros que voc� usa no seu app Next.js tiver suporte da @next/third-parties, instalar o pacote e tente! Gostar�amos de receber seu feedback sobre GitHub.