Comprendere la visione alla base del componente Script di Next.js, che fornisce una soluzione integrata per ottimizzare il caricamento degli script di terze parti.
Circa il 45% delle richieste provenienti da siti web pubblicati su dispositivi mobili e computer sono richieste di terze parti e il 33% sono script. Le dimensioni, la latenza e il caricamento di script di terze parti possono influire notevolmente sulle prestazioni di un sito. Il componente Script Next.js include best practice e impostazioni predefinite integrate per aiutare gli sviluppatori a introdurre script di terze parti nelle loro applicazioni, risolvendo contemporaneamente potenziali problemi di prestazioni.
Script di terze parti e relativo impatto sul rendimento
Gli script di terze parti consentono agli sviluppatori web di sfruttare le soluzioni esistenti per implementare funzionalità comuni e ridurre i tempi di sviluppo. Tuttavia, in genere gli autori di questi script non sono incentivati a prendere in considerazione l'impatto sul rendimento del sito web utilizzato. Questi script rappresentano anche una blackbox per gli sviluppatori che li utilizzano.
Gli script causano un numero significativo di byte di terze parti scaricati dai siti web in diverse categorie di richieste di terze parti. Per impostazione predefinita, il browser assegna la priorità agli script in base alla posizione nel documento in cui si trovano, il che potrebbe ritardare il rilevamento o l'esecuzione di script fondamentali per l'esperienza utente.
Le librerie di terze parti necessarie per il layout devono essere caricate in anticipo per il rendering della pagina. Le terze parti che non sono necessarie per il rendering iniziale devono essere differite in modo da non bloccare altre elaborazioni nel thread principale. Lighthouse prevede due controlli per segnalare gli script di blocco della visualizzazione o di blocco dei thread principali.
È importante considerare la sequenza di caricamento delle risorse della pagina, in modo che le risorse critiche non vengano ritardate e quelle non critiche non blocchino le risorse critiche.
Sebbene esistano best practice per ridurre l'impatto di terze parti, non tutti potrebbero essere a conoscenza di come implementarle per ogni terza parte utilizzata. Ciò può essere complicato perché:
- In media, i siti web utilizzano da 21 a 23 terze parti diverse, inclusi gli script, su dispositivi mobili e computer. L'utilizzo e i consigli possono variare per ciascuno.
- L'implementazione di molte terze parti può variare a seconda che si utilizzi un framework o una libreria UI particolare.
- Le librerie di terze parti più recenti vengono introdotte di frequente.
- Variare i requisiti aziendali relativi alla stessa terza parte rende difficile per gli sviluppatori standardizzarne l'utilizzo.
L'attenzione di Aurora agli script di terze parti
Una parte della collaborazione di Aurora con framework e strumenti web open source consiste nel fornire impostazioni predefinite efficaci e strumenti "guidati" per aiutare gli sviluppatori a migliorare aspetti dell'esperienza utente come prestazioni, accessibilità, sicurezza e idoneità per i dispositivi mobili. Nel 2021 ci siamo impegnati ad aiutare gli stack di framework a migliorare l'esperienza utente e le metriche relative ai Segnali web essenziali.
Uno dei passaggi più significativi per raggiungere il nostro obiettivo di migliorare le prestazioni del framework è stato la ricerca della sequenza di caricamento ideale degli script di terze parti in Next.js. Framework come Next.js si trovano in una posizione unica per fornire valori predefiniti e funzionalità utili che aiutano gli sviluppatori a caricare in modo efficiente le risorse, incluse le terze parti. Abbiamo studiato numerosi dati di HTTP Archive e Lighthouse per trovare quali terze parti bloccano il rendering maggiormente in framework diversi.
Per risolvere il problema del blocco degli script di terze parti nel thread principale utilizzati in un'applicazione, abbiamo creato il componente Script. Il componente racchiude funzionalità di sequenziamento per fornire agli sviluppatori controlli migliori per il caricamento di script di terze parti.
Sequenza di script di terze parti senza un componente del framework
Le indicazioni disponibili per ridurre l'impatto degli script che bloccano la visualizzazione forniscono i seguenti metodi per caricare e sequenziare in modo efficiente gli script di terze parti:
Utilizza l'attributo
asyncodefercon i tag<script>che indicano al browser di caricare script di terze parti non fondamentali senza bloccare l'analizzatore sintattico dei documenti. Gli script non necessari per il caricamento iniziale della pagina o per la prima interazione dell'utente potrebbero essere considerati non critici.<script src="https://example.com/script1.js" defer></script> <script src="https://example.com/script2.js" async></script>Stabilisci connessioni in anteprima alle origini richieste utilizzando le funzionalità di preconnessione e dns-prefetch. In questo modo, gli script critici possono avviarsi prima del download.
<head> <link rel="preconnect" href="http://PreconnThis.com"> <link rel="dns-prefetch" href="http://PrefetchThis.com"> </head>Caricamento lento: risorse e incorporamenti di terze parti al termine del caricamento dei contenuti principali della pagina o quando l'utente scorre verso il basso fino alla parte della pagina in cui sono inclusi.
Il componente Script Next.js
Il componente Script Next.js implementa i metodi illustrati sopra per la sequenza di script e fornisce agli sviluppatori un modello per definire la propria strategia di caricamento. Una volta specificata la strategia adatta, questa verrà caricata in modo ottimale senza bloccare altre risorse critiche.
Il componente Script si basa sul tag HTML <script> e offre un'opzione per impostare la priorità di caricamento per gli script di terze parti utilizzando l'attributo strategia.
// Example for beforeInteractive:
<Script src="https://polyfill.io/v3/polyfill.min.js?features=IntersectionObserverEntry%2CIntersectionObserver" strategy="beforeInteractive" />
// Example for afterInteractive (default):
<Script src="https://example.com/samplescript.js" />
// Example for lazyonload:
<Script src="https://connect.facebook.net/en_US/sdk.js" strategy="lazyOnload" />
L'attributo della strategia può assumere tre valori.
beforeInteractive: questa opzione può essere utilizzata per gli script critici che devono essere eseguiti prima che la pagina diventi interattiva. Next.js garantisce che questi script vengano inseriti nel codice HTML iniziale sul server ed eseguiti prima di altro codice JavaScript autoraggruppato. La gestione del consenso, gli script per il rilevamento di bot o le librerie helper necessari per visualizzare contenuti critici sono ottimi candidati per questa strategia.afterInteractive: questa è la strategia predefinita applicata ed equivale a caricare uno script con l'attributo differisce. Deve essere utilizzato per gli script che il browser può eseguire dopo che la pagina è interattiva, ad esempio per gli script di analisi. Next.js inserisce questi script sul lato client e vengono eseguiti dopo che la pagina è stata idratata. Pertanto, se non diversamente specificato, tutti gli script di terze parti definiti utilizzando il componente Script vengono differiti da Next.js, fornendo così un forte valore predefinito.lazyOnload: questa opzione può essere utilizzata per eseguire il caricamento lento degli script a bassa priorità quando il browser è inattivo. La funzionalità fornita da questi script non è necessaria immediatamente dopo che la pagina diventa interattiva, ad esempio plug-in di chat o social media.
Gli sviluppatori possono indicare a Next.js in che modo la loro applicazione utilizza uno script specificando la strategia. Ciò consente al framework di applicare ottimizzazioni e best practice per caricare lo script garantendo al contempo la sequenza di caricamento migliore.
Utilizzando il componente Script, gli sviluppatori possono inserire uno script di terze parti in qualsiasi punto dell'applicazione per il caricamento tardivo di terze parti e a livello di documento per gli script critici. Ciò implica che il componente Script potrebbe essere posizionato insieme al componente utilizzando lo script. Dopo l'idratazione, lo script viene inserito nell'intestazione del documento visualizzato inizialmente o in fondo al corpo, a seconda della strategia utilizzata.
Misurazione dell'impatto
Abbiamo utilizzato i modelli per l'app di e-commerce Next.js e il blog iniziale per creare due app demo che ci hanno aiutato a misurare l'impatto dell'inclusione di script di terze parti. Le terze parti comunemente utilizzate per gli incorporamenti di Google Tag Manager e dei social media sono state incluse nelle pagine di queste app all'inizio e poi tramite il componente Script. Abbiamo quindi confrontato il rendimento di queste pagine su WebPageTest.
Script di terze parti in un'app commerciale Next.js
Per la demo sono stati aggiunti script di terze parti al modello di app di e-commerce, come mostrato di seguito.
Il seguente confronto mostra l'avanzamento visivo per entrambe le versioni dello starter-kit commerciale Next.js. Come abbiamo visto, l'LCP si verifica quasi un secondo con il componente Script attivato con la strategia di caricamento corretta.
Script di terze parti in un blog Next.js
All'app del blog dimostrativo sono stati aggiunti script di terze parti, come indicato di seguito.
| Prima | Dopo |
|---|---|
| Google Tag Manager con asincrono | Componente script con strategia = lazyonload per ognuno dei quattro script |
| Pulsante Segui di Twitter con asincrono | |
| Pulsante "Iscriviti" di YouTube senza asincrono o rinvio | |
| Pulsante Segui LinkedIn senza asincrono o rinviare |
Come mostrato nel video, la metrica First Contentful Paint (FCP) si verifica a 0,9 secondi sulla pagina senza il componente Script e a 0,4 secondi con il componente Script.
Passaggi successivi per il componente Script
Le opzioni di strategia per afterInteractive e lazyOnload forniscono un controllo significativo sugli script che bloccano la visualizzazione, ma stiamo esaminando anche altre opzioni che potrebbero aumentare l'utilità del componente Script.
Utilizzo dei web worker
I web worker possono essere utilizzati per eseguire script indipendenti su thread in background, in modo da liberare il thread principale per gestire le attività di elaborazione dell'interfaccia utente e migliorare le prestazioni. I web worker sono più adatti a ridurre il carico di lavoro dell'elaborazione JavaScript, piuttosto che del lavoro dell'interfaccia utente, fuori dal thread principale. Gli script utilizzati per l'assistenza clienti o il marketing, che in genere non interagiscono con l'interfaccia utente, possono essere buoni candidati per l'esecuzione in un thread in background. È possibile utilizzare una leggera libreria di terze parti, PartyTown, per isolare questi script in un web worker.
Con l'attuale implementazione del componente script Next.js, ti consigliamo di rimandare questi script nel thread principale impostando la strategia su afterInteractive o lazyOnload. In futuro, proponiamo di introdurre una nuova opzione di strategia, 'worker', che consentirà a Next.js di utilizzare PartyTown o una soluzione personalizzata per eseguire script sui web worker. I commenti degli sviluppatori su questa RFC sono ben accetti.
Riduzione al minimo del CLS
Gli incorporamenti di terze parti, come annunci, video o feed di social media, possono causare variazioni del layout in caso di caricamento lento. Questo influisce sull'esperienza utente e sulla metrica Cumulative Layout Shift (CLS) per la pagina. La funzionalità CLS può essere ridotta a icona specificando le dimensioni del container in cui verrà caricato l'incorporamento.
Puoi utilizzare il componente Script per caricare incorporamenti che possono causare variazioni del layout. Stiamo prendendo in considerazione la possibilità di aumentarlo per fornire opzioni di configurazione che contribuiranno a ridurre la CLS. Queste informazioni possono essere rese disponibili all'interno del componente Script stesso o come componente companion.
Componenti wrapper
La sintassi e la strategia di caricamento per includere script di terze parti popolari come Google Analytics o Google Tag Manager (GTM) di solito sono fisse. Questi possono essere ulteriormente incapsulati in singoli componenti wrapper per ogni tipo di script. Agli sviluppatori sarà disponibile soltanto un insieme minimo di attributi specifici per l'applicazione (ad esempio l'ID monitoraggio). I componenti wrapper aiutano gli sviluppatori in quanto:
- Semplificando l'inclusione di tag di script popolari.
- Fare in modo che il framework utilizzi la strategia ottimale in background.
Conclusione
Gli script di terze parti vengono in genere creati per includere funzionalità specifiche nel sito web in uso. Per ridurre l'impatto degli script non critici, consigliamo di differirli, operazione che il componente Script Next.js esegue per impostazione predefinita. Gli sviluppatori sono sicuri che gli script inclusi non ritardano la funzionalità fondamentale, a meno che non applichino esplicitamente la strategia beforeInteractive. Come per il componente Script Next.js, anche gli sviluppatori di framework possono valutare la creazione di queste funzionalità in altri framework. Stiamo valutando attivamente di ottenere un componente simile con il team Nuxt.js. In base ai feedback ricevuti, ci auguriamo anche di migliorare ulteriormente il componente Script per altri casi d'uso.
Attestazioni
Grazie a Kara Erickson, Janicklas Ralph, Katie Hempenius, Philip Walton, Jeremy Wagner e Addy Osmani per il loro feedback su questo post.