En 2021, l'équipe Chrome Aurora a lancé le Script pour améliorer les performances de chargement des scripts tiers dans Next.js. Depuis son lancement, nous avons a développé ses fonctionnalités pour faciliter le chargement des ressources tierces pour les développeurs.
Cet article de blog offre un aperçu des nouvelles fonctionnalités que nous avons lancées, et notamment @next/third-parties bibliothèque, ainsi que les grandes lignes des futures initiatives sur notre feuille de route.
Implications des scripts tiers sur les performances
41% de toutes les requêtes tierces sur les sites Next.js sont des scripts. Retirer le like sur d'autres contenus le téléchargement et l'exécution des scripts peuvent prendre un certain temps, ce qui peut bloquer l'affichage et retarder l'interactivité de l'utilisateur. Données de Chrome Le rapport d'expérience utilisateur (CrUX) indique que les sites Next.js qui chargent davantage de sites scripts présentent une interaction avec le tableau suivant moins élevé (INP) et Largest Contentful Paint (LCP).
<ph type="x-smartling-placeholder">.La corrélation observée dans ce graphique n'implique pas de causalité. Toutefois, en local les tests montrent de nouvelles preuves que les scripts tiers sur les performances des pages. Par exemple, le tableau ci-dessous compare différents ateliers dans le cas d'un conteneur Google Tag Manager, soit 18 éléments sélectionnés au hasard. sont ajoutées à Taxonomy, un exemple populaire de Next.js l'application.
<ph type="x-smartling-placeholder">.La documentation WebPageTest fournit des détails sur la façon dont ces délais sont mesurés. En bref, il est que toutes ces métriques d'atelier sont affectées par le conteneur Google Tag Manager. Pour Exemple : Total Blocking Time (TBT), un atelier utile qui se rapproche de l'INP, a presque doublé.
Composant de script
Lorsque nous avons lancé le composant <Script>
dans Next.js, nous avons veillé à introduire
via une API conviviale qui ressemble beaucoup au <script>
traditionnel
. Grâce à lui, les développeurs peuvent colocaliser un script tiers dans n'importe quelle
dans son application, et Next.js se charge de séquencer le
après le chargement des ressources critiques.
<!-- 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" />
Des dizaines de milliers d'applications Next.js, y compris des sites populaires tels que
Patreon, Target et
Notion : utilisez le composant <Script>
. Malgré son
efficacité, certains développeurs ont exprimé des inquiétudes sur les points suivants
choses:
- Où placer le composant
<Script>
dans une application Next.js tout en respectant aux instructions d'installation de différents fournisseurs tiers. (expérience développeur). - Quelle est la stratégie de chargement la plus adaptée scripts tiers (expérience utilisateur).
Pour répondre à ces deux préoccupations, nous avons lancé @next/third-parties
, un
bibliothèque spécialisée proposant un ensemble de composants et d'utilitaires optimisés
spécialement conçu pour les tiers populaires.
Expérience développeur: simplification de la gestion des bibliothèques tierces
De nombreux scripts tiers sont utilisés dans un
pourcentage significatif de sites Next.js, avec
Google Tag Manager est l'outil le plus utilisé,
66% des sites respectivement.
@next/third-parties
s'appuie sur <Script>
en introduisant des wrappers de niveau supérieur conçus pour simplifier l'utilisation
ces cas d'utilisation courants.
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, un autre script tiers couramment utilisé (52% des sites Next.js). Elle dispose également d'un composant dédié.
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
simplifie le processus de chargement de scripts couramment utilisés,
mais cela étend également notre capacité à développer des fournisseurs d'énergie pour d'autres
comme les intégrations. Par exemple, les intégrations Google Maps et YouTube
utilisé dans
8%
et
4%
des sites Web Next.js, et nous avons également
expédié des composants pour les rendre
plus facile à charger.
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" />
</>
);
}
Expérience utilisateur: accélérer le chargement des bibliothèques tierces
Dans un monde parfait, chaque bibliothèque tierce largement adoptée serait entièrement optimisés, ce qui rend inutiles les abstractions qui améliorent leurs performances. Toutefois, en attendant que cela devienne réalité, nous pouvons essayer d'améliorer une expérience utilisateur lorsqu'elle est intégrée via des frameworks populaires comme Next.js. Nous pouvons tester différentes techniques de chargement, vérifier que les scripts sont séquencés de la bonne manière et partager nos commentaires avec des tiers pour encourager les changements en amont.
Prenons l'exemple des intégrations YouTube. Lorsque d'autres implémentations ont
de bien meilleures performances que l'intégration native. Actuellement, les <YouTubeEmbed>
que le composant exporté par @next/third-parties
utilise
lite-youtube-embed, qui,
lorsqu'il s'agit d'une application "Hello, World" Next.js charge considérablement
plus rapidement.
De même, pour Google Maps, nous incluons loading="lazy"
comme attribut par défaut pour
l'intégration pour garantir que la carte se charge uniquement à une certaine distance
la fenêtre d'affichage. Cet attribut peut sembler évident,
depuis que Google Maps
documentation
l'inclut dans leur exemple d'extrait de code, mais seulement
45% des sites Next.js qui intègrent Google Maps utilisent loading="lazy"
.
Exécuter des scripts tiers dans un nœud de calcul Web
Une technique avancée que nous
explorons dans @next/third-parties
est de la rendre
plus facile de décharger les scripts tiers
vers un nœud de calcul Web. Popularité par
des bibliothèques telles que Partytown, ce qui peut réduire
l'impact des scripts tiers sur les performances des pages de façon significative
en les déplaçant complètement
hors du thread principal.
Le GIF animé suivant montre les variations dans les tâches longues et le thread principal
temps de blocage lors de l'application de différentes stratégies <Script>
à un conteneur GTM
sur un site Next.js. Notez que si vous passez d'une stratégie à l'autre
retarde l'exécution de ces scripts et les transfère vers un nœud de calcul Web.
élimine complètement
le temps passé sur le thread principal.
Dans cet exemple, déplacer l'exécution du conteneur GTM et scripts de tag associés à un nœud de calcul Web a réduit de 92% la durée du traitement des données.
Si elle n'est pas gérée avec précaution, cette technique peut en arrière-plan
casser de nombreux scripts tiers, ce qui complique le débogage. Dans
mois, nous vérifierons si les composants tiers proposés
@next/third-parties
fonctionne correctement lorsqu'il est exécuté dans un nœud de calcul Web. Si c’est le cas, nous
s'efforcent de proposer aux développeurs un moyen simple et facultatif d'utiliser
technique.
Étapes suivantes
Au cours du développement de ce package, il est devenu évident
des recommandations de chargement tiers afin que les autres frameworks
pourraient également tirer parti des mêmes
techniques sous-jacentes que celles utilisées. Cela nous a amenés à
créer des applications
Capital, une bibliothèque
qui utilise JSON pour décrire les techniques de chargement tierces, qui sont actuellement
sert de base à @next/third-parties
.
Lors des prochaines étapes, nous continuerons à nous concentrer sur l'amélioration des composants fournis pour Next.js et nous nous efforçons d'inclure des utilitaires similaires dans d'autres des frameworks et des plates-formes CMS populaires. Nous travaillons actuellement en collaboration avec Nuxt et ont l'intention de lancer des utilitaires tiers similaires, adaptés à leur écosystème dans un avenir proche.
Si l'un des tiers que vous utilisez dans votre application Next.js est compatible avec
@next/third-parties
,
installer le package
et essayez ! Nous aimerions connaître votre avis sur
GitHub