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).
![Gráfico de barras que muestra una disminución en el porcentaje de Next.js que logra buenas puntuaciones de INP y LCP en proporción a la cantidad de terceros cargados](https://developer.chrome.google.cn/static/blog/next-third-parties/image/chart-inp-lcp.png?authuser=7&hl=es-419)
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 .
![Gráfico de barras que muestra la diferencia en varias métricas del lab cuando un sitio se carga con y sin Google Tag Manager](https://developer.chrome.google.cn/static/blog/next-third-parties/image/wpt-chart.png?authuser=7&hl=es-419)
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.
![GIF que muestra la comparación de carga de página entre el componente de incorporación de YouTube y un iframe normal de YouTube](https://developer.chrome.google.cn/static/blog/next-third-parties/image/wpt-comparison.gif?authuser=7&hl=es-419)
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.
![GIF que muestra diferencias en el tiempo de bloqueo del subproceso principal para las diferentes estrategias de secuencia de comandos](https://developer.chrome.google.cn/static/blog/next-third-parties/image/main-thread.gif?authuser=7&hl=es-419)
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: