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).
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.
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.
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.
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.