Nel 2021, il team di Chrome Aurora ha introdotto lo script per migliorare delle prestazioni di caricamento degli script di terze parti in Next.js. Dal suo lancio, abbiamo ha ampliato le sue funzionalità per semplificare il caricamento di risorse di terze parti più velocemente per gli sviluppatori.
Questo post del blog fornisce una panoramica delle funzioni più recenti rilasciate, in particolare @next/third-parties e una bozza delle iniziative future sulla nostra roadmap.
Implicazioni sulle prestazioni degli script di terze parti
Il 41% di tutte le richieste di terze parti nei siti Next.js è costituito da script. Mettere Non mi piace più ad altri contenuti tipi di script, il download e l'esecuzione degli script possono richiedere molto tempo, il che può bloccare il rendering e ritardare l'interattività dell'utente. Dati da Chrome Il Report sull'esperienza utente (CrUX) indica che i siti Next.js che caricano più contenuti di terze parti gli script hanno un valore di interazione con Next Paint inferiore (INP) e Largest Contentful Paint (LCP).
La correlazione osservata in questo grafico non implica alcuna causa. Tuttavia, le impostazioni gli esperimenti forniscono ulteriori prove del fatto che script di terze parti significativamente influire sulle prestazioni della pagina. Ad esempio, il grafico seguente mette a confronto vari lab quando un contenitore di Google Tag Manager, di cui 18 selezionati casualmente, viene aggiunto a Taxonomy, un popolare esempio di Next.js dell'app.
La documentazione di WebPageTest fornisce dettagli su come vengono misurati questi tempi. A colpo d'occhio, che tutte queste metriche del lab sono interessate dal contenitore GTM. Per esempio, Total Blocking Time (TBT), un lab utile proxy che approssima l'INP, ha registrato un aumento di quasi 20 volte.
Componente script
Quando abbiamo distribuito il componente <Script> in Next.js, ci siamo assicurati di introdurre
tramite un'API facile da usare che ricorda da vicino il tradizionale <script>
. Utilizzandolo, gli sviluppatori possono geolocalizzare uno script di terze parti in qualsiasi
nella propria applicazione e Next.js si occuperà di sequenziare
dopo il caricamento delle risorse critiche.
<!-- 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" />
Decine di migliaia di applicazioni Next.js, tra cui siti popolari come
Patreon, Target e
Nozione: utilizza il componente <Script>. Nonostante le sue
efficacia, alcuni sviluppatori hanno sollevato preoccupazioni in merito a quanto segue:
cose:
- Dove posizionare il componente
<Script>in un'app Next.js rispettando al contempo alle varie istruzioni di installazione dei vari provider di terze parti (esperienza per sviluppatori). - Qual è la strategia di caricamento ottimale per diverse script di terze parti (esperienza utente).
Per rispondere a entrambe queste preoccupazioni, abbiamo lanciato @next/third-parties, una
libreria specializzata che offre una serie di utilità e componenti ottimizzati
su misura per terze parti popolari.
Esperienza di sviluppo: semplifica la gestione delle librerie di terze parti
In una percentuale significativa dei siti Next.js vengono utilizzati molti script di terze parti, con
Google Tag Manager è il più popolare, usato
rispettivamente il 66% dei siti.
@next/third-parties si basa su <Script>
introducendo wrapper a livello superiore progettati per semplificare l'utilizzo
questi casi d'uso comuni.
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 altro script di terze parti ampiamente utilizzato (52% dei siti Next.js), ha anche un componente dedicato.
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 semplifica il processo di caricamento degli script di uso comune,
ma estende anche la nostra capacità di sviluppare utilità per altre
come gli incorporamenti. Ad esempio, gli incorporamenti di Google Maps e YouTube
in uso in
L'8%
e
il 4%
di siti web Next.js e abbiamo anche fornito componenti per renderli
è più facile da caricare.
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" />
</>
);
}
Esperienza utente: velocizzare il caricamento delle librerie di terze parti
In un mondo perfetto, ogni libreria di terze parti ampiamente adottata sarebbe ottimizzate, rendendo inutili eventuali astrazioni che ne migliorano le prestazioni. Fino a quando ciò non sarà diventato realtà, possiamo provare a migliorare l'esperienza degli utenti una volta integrata mediante framework popolari come Next.js. Possiamo prova diverse tecniche di caricamento, assicurati che gli script siano in sequenza in modo corretto e infine condividere il nostro feedback con per incoraggiare cambiamenti a monte.
Prendiamo come esempio gli incorporamenti di YouTube. Per le implementazioni alternative
di gran lunga migliore rispetto
all'incorporamento nativo. Attualmente, la <YouTubeEmbed>
componente esportato da @next/third-parties utilizzi
lite-youtube-embed, che,
quando mostrato in "Hello World" Confronto Next.js, si carica notevolmente
più velocemente.
Allo stesso modo, per Google Maps, includiamo loading="lazy" come attributo predefinito per
l'incorporamento per garantire che la mappa venga caricata solo quando si trova a una certa distanza da
nell'area visibile. Potrebbe sembrare un attributo ovvio, soprattutto
poiché Google Maps
documentazione
lo include nello snippet di codice di esempio, ma solo
Il 45% dei siti Next.js che incorporano Google Maps utilizza loading="lazy".
Esecuzione di script di terze parti in un worker web
Una tecnica avanzata che stiamo esaminando in @next/third-parties è realizzare
è più facile trasferire gli script di terze parti a un worker web. Popolari da
come Partytown, questo può ridurre
l'impatto degli script di terze parti sulle prestazioni della pagina in modo sostanziale
e riposizionarle completamente dal thread principale.
La seguente GIF animata mostra le variazioni nelle attività lunghe e nel thread principale
blocco del tempo quando applichi strategie <Script> diverse a un contenitore GTM
all'interno di un sito Next.js. Tieni presente che, pur passando solo da un'opzione di strategia all'altra
ritarda i tempi di esecuzione di questi script, spostandoli su un worker web
eliminano completamente il loro tempo sul thread principale.
In questo esempio specifico, lo spostamento dell'esecuzione del contenitore GTM e dei relativi script di tag associati a un web worker hanno ridotto le TBT del 92%.
Vale la pena notare che, se non gestita con attenzione, questa tecnica può riprodurre in silenzio
interrompere molti script di terze parti, il che complica il debug. Nei prossimi
mesi, convalideremo se eventuali componenti di terze parti offerti
@next/third-parties funzionano correttamente quando vengono eseguiti in un worker web. In tal caso,
per fornire agli sviluppatori un modo semplice e facoltativo di usare
tecnica.
Passaggi successivi
Durante il processo di sviluppo del pacchetto, è emerso che esisteva una
centralizzare i suggerimenti di caricamento di terze parti in modo che altri framework
possono trarre vantaggio anche
dalle stesse tecniche sottostanti utilizzate. Questo ci ha portato a
sviluppare dati di terze parti
Capital, una biblioteca
che utilizza JSON per descrivere le tecniche di caricamento di terze parti, che attualmente
è la base di @next/third-parties.
Nei prossimi passi, continueremo a concentrarci sul miglioramento dei componenti forniti per Next.js ed espandere i nostri sforzi per includere utilità simili in altri i framework più diffusi e le piattaforme CMS. Attualmente stiamo collaborando con Nuxt manutentori e prevedono di rilasciare utilità di terze parti simili su misura al proprio ecosistema in futuro.
Se una delle terze parti che utilizzi nell'app Next.js è supportata da
@next/third-parties,
installare il pacchetto
e provaci! Ci piacerebbe ricevere il tuo feedback su
GitHub.