En 2021, el equipo de Chrome Aurora present� el m�dulo Script componente para mejorar la cargar el rendimiento de secuencias de comandos de terceros en Next.js Desde su lanzamiento, expandi� sus capacidades para facilitar la carga de recursos de terceros m�s r�pido para los desarrolladores.
Esta entrada de blog ofrece una descripci�n general de las funciones nuevas que hemos lanzado, en particular el @next/third-parties y una descripci�n de las iniciativas futuras en nuestra hoja de ruta.
Implicaciones en el rendimiento de las secuencias de comandos de terceros
El 41% de todas las solicitudes de terceros en los sitios de Next.js son secuencias de comandos. Desmarcar Me gusta en otro contenido los tipos de secuencias de comandos, las secuencias de comandos pueden tardar bastante tiempo en descargarse y ejecutarse lo que puede bloquear la renderizaci�n y retrasar la interactividad del usuario. Datos de Chrome El Informe sobre la experiencia del usuario (CrUX) muestra que los sitios de Next.js que cargan m�s las secuencias de comandos tienen una interacci�n con el siguiente procesamiento de imagen (INP) y el Procesamiento de imagen con contenido m�s grande (LCP).
La correlaci�n observada en este gr�fico no implica causalidad. Sin embargo, la configuraci�n local proporcionan evidencia adicional de que las secuencias de comandos de terceros afectar el rendimiento de la p�gina. Por ejemplo, en el siguiente gr�fico se comparan varios labs m�tricas cuando se selecciona un contenedor de Google Tag Manager, compuesto por 18 etiquetas) se agrega a Taxonomy, un ejemplo popular de Next.js .
Documentaci�n de WebPageTest proporciona detalles sobre c�mo se miden estos plazos. A simple vista, que todas estas m�tricas del lab se ven afectadas por el contenedor de GTM. Para Ejemplo, Total Blocking Time (TBT), un lab �til que se aproxima a INP, observ� un aumento de casi 20 veces.
Componente de secuencia de comandos
Cuando enviamos el componente <Script> en Next.js, nos aseguramos de presentar
a trav�s de una API f�cil de usar que se parece mucho a la <script> tradicional
. Al usarla, los desarrolladores pueden ubicar una secuencia de comandos de terceros en cualquier
de la aplicaci�n en su aplicaci�n, y Next.js se encargar�
una secuencia de comandos
despu�s de que se cargan los recursos esenciales.
<!-- 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" />
Decenas de miles de aplicaciones de Next.js, incluidos sitios populares como
Patreon, Target y
Noción: usa el componente <Script>. A pesar de su
eficacia, algunos desarrolladores han planteado inquietudes sobre los siguientes
cosas:
- D�nde colocar el componente
<Script>en una app de Next.js mientras se cumple las diversas instrucciones de instalaci�n de los distintos proveedores externos (experiencia del desarrollador). - �Qu� estrategia de carga es la m�s �ptima para diferentes secuencias de comandos de terceros (experiencia del usuario).
Para abordar ambas inquietudes, lanzamos @next/third-parties, un
biblioteca especializada, que ofrece un conjunto de componentes y utilidades optimizados
adaptado para terceros populares.
Experiencia para desarrolladores: Facilitamos la administraci�n de bibliotecas de terceros
Muchas secuencias de comandos de terceros se usan en un porcentaje significativo de sitios de Next.js, con
Google Tag Manager es el m�s popular, usado por
66% de los sitios, respectivamente.
@next/third-parties se basa en <Script>.
principal introduciendo wrappers de nivel superior dise�ados para simplificar el uso de
estos casos de uso comunes.
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, otra secuencia de comandos de terceros muy utilizada (52% de los sitios de Next.js), tambi�n tiene un componente propio 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>
);
}
@next/third-parties simplifica el proceso de carga de secuencias de comandos de uso general.
pero tambi�n ampl�a nuestra capacidad de desarrollar utilidades para otros
categor�as, como incorporaciones. Por ejemplo, las incorporaciones de Google Maps y YouTube se
usado en
Un 8%
y
4%
de los sitios web Next.js respectivamente y tambi�n hemos enviado componentes para que sean
m�s f�ciles de cargar.
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" />
</>
);
}
Experiencia del usuario: C�mo acelerar la carga de las bibliotecas de terceros
En un mundo ideal, todas las bibliotecas de terceros ampliamente adoptadas optimizado, lo que hace que las abstracciones que mejoren su rendimiento sean innecesarias. Sin embargo, hasta que esto se haga realidad, podemos tratar de mejorar experiencia cuando se integra a trav�s de frameworks populares, como Next.js. Podemos Experimente con distintas t�cnicas de carga, aseg�rese de que las secuencias de comandos est�n secuenciadas de la manera correcta y, en �ltima instancia, compartiremos nuestros comentarios con para fomentar los cambios ascendentes.
Tomemos como ejemplo las incorporaciones de YouTube. Algunas implementaciones alternativas
un rendimiento mucho mejor que la incorporaci�n nativa. Actualmente, el <YouTubeEmbed>
componente exportado por @next/third-parties usa
lite-youtube-embed, que,
cuando se muestra en la p�gina "Hello, World" Comparaci�n de Next.js, se carga considerablemente
m�s r�pido.
Del mismo modo, en el caso de Google Maps, incluimos loading="lazy" como atributo predeterminado para
insertar para asegurarte de que el mapa solo se cargue a cierta distancia de
el viewport. Puede parecer un atributo obvio, en especial
ya que Google Maps
documentaci�n
lo incluye en el fragmento de c�digo de ejemplo,
El 45% de los sitios de Next.js que incorporan Google Maps utilizan loading="lazy".
Ejecuci�n de secuencias de comandos de terceros en un trabajador web
Una t�cnica avanzada que estamos explorando en @next/third-parties es hacer que sea
y facilitar la descarga de secuencias de comandos
de terceros en un trabajador web. Popularizado por
bibliotecas como Partytown, esto puede reducir
el impacto de las secuencias de comandos de terceros
en el rendimiento de las p�ginas
reubicarlas por completo fuera del subproceso principal.
En el siguiente GIF animado, se muestran las variaciones en las tareas largas y el subproceso principal
tiempo de bloqueo cuando se aplican diferentes estrategias de <Script> a un contenedor de GTM
en un sitio de Next.js. Si bien solo alterna entre las diferentes opciones de estrategia,
Retrasa el tiempo de ejecuci�n de estas secuencias de comandos y las reubica en un trabajador web
elimina por completo su tiempo en el subproceso principal.
En este ejemplo en particular, trasladar la ejecuci�n del contenedor GTM y su secuencias de comandos de etiquetas asociadas a un trabajador web redujo el TBT en un 92%.
Vale la pena se�alar que, si no se administra con cuidado, esta t�cnica puede
romper muchas secuencias de comandos de terceros, lo que dificulta la depuraci�n. En las pr�ximas
validaremos si alg�n componente de terceros ofrece
@next/third-parties funcionan correctamente cuando se ejecutan en un trabajador web. Si es as�,
a fin de proporcionar a los desarrolladores una forma f�cil y opcional de usar
t�cnica.
Pr�ximos pasos
En el proceso de desarrollo de este paquete, fue evidente que hab�a una
necesitan centralizar recomendaciones de carga de terceros para que otros frameworks
tambi�n podr�a beneficiarse
de las mismas t�cnicas subyacentes empleadas. Esto nos llev� a
crear herramientas de
Capital, una biblioteca
que usa JSON para describir t�cnicas de carga de terceros, que actualmente
y sirve como base para @next/third-parties.
En los pr�ximos pasos, seguiremos enfoc�ndonos en mejorar los componentes proporcionados para Next.js y tambi�n ampliaremos nuestros esfuerzos para incluir utilidades similares en otras y plataformas de CMS populares. Actualmente, estamos en colaboraci�n con Nuxt y planean lanzar utilidades de terceros similares adaptadas a su ecosistema en un futuro cercano.
Si alguno de los terceros que usas en tu app de Next.js es compatible con
@next/third-parties,
instalar el paquete
�y pru�bala! Nos encantar�a recibir tus comentarios sobre
GitHub: