Comprendi la visione alla base del componente Script di Next.js, che fornisce una soluzione integrata per ottimizzare il caricamento di script di terze parti.
Circa il 45% delle richieste da siti web pubblicati su dispositivi mobili e computer sono richieste di terze parti, di cui il 33% sono script. Le dimensioni, la latenza e il caricamento degli 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 da subito 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, gli autori di questi script in genere non sono incentivati a considerare l'impatto sul rendimento del sito web che li utilizza. Questi script sono anche una blackbox per gli sviluppatori che li utilizzano.
Gli script rappresentano 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 priorità agli script in base alla loro posizione nel documento, il che potrebbe ritardare il rilevamento o l'esecuzione di script critici per l'esperienza utente.
Le librerie di terze parti necessarie per il layout devono essere caricate in anticipo per eseguire il rendering della pagina. Le terze parti che non sono richieste per il rendering iniziale devono essere differite in modo da non bloccare altre elaborazioni sul 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 che quelle non critiche non blocchino quelle critiche.
Sebbene esistano best practice per ridurre l'impatto delle terze parti, non tutti potrebbero sapere come implementarle per tutte le terze parti che utilizzano. Questo 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 potrebbero variare per ciascuno.
- L'implementazione di molte terze parti può variare in base all'utilizzo di un determinato framework o di una libreria UI.
- Le librerie di terze parti più recenti vengono introdotte di frequente.
- La variabilità dei requisiti aziendali relativi alla stessa terza parte rende difficile per gli sviluppatori standardizzarne l'utilizzo.
L'attenzione di Aurora sugli script di terze parti
Parte della collaborazione di Aurora con framework e strumenti web open source consiste nel fornire valori predefiniti efficaci e strumenti guidati per aiutare gli sviluppatori a migliorare gli aspetti dell'esperienza utente, come prestazioni, accessibilità, sicurezza e idoneità ai dispositivi mobili. Nel 2021 ci siamo impegnati ad aiutare gli stack di framework a migliorare l'esperienza utente e le relative metriche Core Web Vitals.
Uno dei passaggi più significativi per raggiungere il nostro obiettivo di migliorare le prestazioni del framework è stato quello di ricercare la sequenza di caricamento ideale degli script di terze parti in Next.js. Framework come Next.js sono in una posizione unica per fornire valori predefiniti e funzionalità utili che aiutano gli sviluppatori a caricare in modo efficiente le risorse, incluse quelle di terze parti. Abbiamo studiato esaustivi i dati di HTTP Archive e Lighthouse per individuare quali terze parti bloccano il rendering più frequentemente nei diversi framework.
Per risolvere il problema degli script di terze parti che bloccano il thread principale utilizzati in un'applicazione, abbiamo creato il componente Script. Il componente incapsula 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 di blocco del rendering forniscono i seguenti metodi per caricare e sequenza 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 critici senza bloccare l'analizzatore sintattico dei documenti. Gli script non necessari per il caricamento iniziale della pagina o 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 iniziali alle origini richieste utilizzando preconnect e dns-prefetch. Ciò consente di avviare prima il download degli script critici.
<head> <link rel="preconnect" href="http://PreconnThis.com"> <link rel="dns-prefetch" href="http://PrefetchThis.com"> </head>Caricamento lento: le risorse e gli incorporamenti di terze parti al termine del caricamento dei contenuti della pagina principale 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 precedenti per la sequenza degli script e fornisce un modello per consentire agli sviluppatori di definire la 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 fornisce un'opzione per impostare la priorità di caricamento per gli script di terze parti utilizzando l'attributo della 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ò avere tre valori.
beforeInteractive: questa opzione può essere utilizzata per gli script critici che devono essere eseguiti prima che la pagina diventi interattiva. Next.js assicura che questi script vengano inseriti nell'HTML iniziale sul server ed eseguiti prima di altri script JavaScript auto-integrati. La gestione del consenso, gli script di rilevamento di bot o le librerie helper necessarie per il rendering dei contenuti critici sono ottimi candidati per questa strategia.afterInteractive: è la strategia predefinita applicata ed equivale al caricamento di uno script con l'attributo defer. Deve essere utilizzata per gli script che il browser può eseguire dopo che la pagina è interattiva, ad esempio 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 valore predefinito elevato.lazyOnload: questa opzione può essere utilizzata per eseguire il caricamento lento di script a bassa priorità quando il browser è inattivo. La funzionalità fornita da questi script non è necessaria subito dopo che la pagina diventa interattiva, ad esempio plug-in di chat o di social media.
Gli sviluppatori possono indicare a Next.js in che modo la loro applicazione utilizza uno script specificando la strategia. In questo modo il framework può applicare ottimizzazioni e best practice per caricare lo script garantendo al contempo la migliore sequenza di caricamento.
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 può essere posizionato insieme al componente utilizzando lo script. Dopo l'idratazione, lo script verrà inserito nell'intestazione del documento visualizzato inizialmente o nella parte inferiore del corpo, a seconda della strategia utilizzata.
Misurazione dell'impatto
Abbiamo utilizzato i modelli per l'app commerciale e il blog iniziale di Next.js per creare due app demo che hanno consentito di misurare l'impatto dell'inclusione di script di terze parti. Le terze parti più comunemente utilizzate per Google Tag Manager e gli incorporamenti nei social media sono state incluse inizialmente nelle pagine di queste app direttamente e poi tramite il componente Script. Abbiamo poi confrontato il rendimento di queste pagine su WebPageTest.
Script di terze parti in un'app commerciale Next.js
Script di terze parti sono stati aggiunti al modello di app commerciale per la demo, come illustrato di seguito.
Il seguente confronto mostra l'avanzamento visivo di entrambe le versioni dello starter-kit commerciale Next.js. Come abbiamo visto, la metrica LCP si verifica quasi un secondo prima con il componente Script abilitato e la strategia di caricamento corretta.
Script di terze parti in un blog Next.js
Sono stati aggiunti script di terze parti all'app del blog dimostrativo, come illustrato di seguito.
| Prima | Dopo |
|---|---|
| Google Tag Manager con asincrono | Componente dello script con strategia = carico lazyon per ciascuno dei quattro script |
| Pulsante Segui Twitter con asincrono | |
| Pulsante Iscriviti di YouTube senza asincrono o differito | |
| Pulsante Segui LinkedIn senza asincrono o differito |
Come mostrato nel video, la metrica First Contentful Paint (FCP) viene visualizzata 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
Anche se le opzioni della strategia per afterInteractive e lazyOnload offrono un controllo significativo sugli script di blocco della visualizzazione, stiamo valutando anche altre opzioni che potrebbero aumentare l'utilità del componente Script.
Utilizzo dei web worker
È possibile utilizzare i web worker per eseguire script indipendenti su thread in background, liberando il thread principale per gestire le attività di elaborazione dell'interfaccia utente e migliorare le prestazioni. I web worker sono più adatti per ridurre il carico dell'elaborazione JavaScript, anziché il 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 su un thread in background. È possibile utilizzare una libreria di terze parti leggera, PartyTown, per isolare questi script in un worker web.
Con l'attuale implementazione del componente di script Next.js, ti consigliamo di posticipare questi script sul thread principale impostando la strategia su afterInteractive o lazyOnload. In futuro, proponiamo l'introduzione di una nuova opzione strategica, 'worker', che consentirà a Next.js di utilizzare PartyTown o una soluzione personalizzata per eseguire script sui web worker. Sono ammessi i commenti degli sviluppatori su questa RFC.
Ridurre al minimo la metrica CLS
Gli incorporamenti di terze parti, come annunci, video o feed di social media, possono causare variazioni del layout con il caricamento lento. Questo influisce sull'esperienza utente e sulla metrica Cumulative Layout Shift (CLS) per la pagina. La metrica CLS può essere ridotta specificando le dimensioni del container in cui verrà caricato l'incorporamento.
È possibile utilizzare il componente Script per caricare incorporamenti che possono causare variazioni del layout. Stiamo valutando la possibilità di aumentarlo per fornire opzioni di configurazione che aiuteranno a ridurre la metrica CLS. Questa opzione può essere resa disponibile all'interno del componente Script stesso o come componente companion.
Componenti wrapper
La sintassi e la strategia di caricamento per l'inclusione di script di terze parti molto diffusi, come Google Analytics o Google Tag Manager (GTM) vengono generalmente risolte. Questi possono essere ulteriormente incapsulati in singoli componenti wrapper per ogni tipo di script. Per gli sviluppatori sarà disponibile solo un insieme minimo di attributi specifici per l'applicazione (come l'ID monitoraggio). I componenti wrapper saranno utili agli sviluppatori:
- Semplificando l'inclusione di tag di script popolari.
- Assicurarsi che il framework utilizzi la strategia ottimale in background.
Conclusione
Gli script di terze parti vengono generalmente creati per includere specifiche funzionalità nel sito web che li utilizza. Per ridurre l'impatto degli script non critici, ti consigliamo di posticiparli, operazione che viene eseguita per impostazione predefinita dal componente Next.js Script. Gli sviluppatori hanno la certezza che gli script inclusi non ritardano la funzionalità critica, a meno che non applichino esplicitamente la strategia beforeInteractive. Come il componente Next.js Script, gli sviluppatori di framework possono anche prendere in considerazione la creazione di queste funzionalità in altri framework. Stiamo esplorando attivamente la destinazione di un componente simile con il team Nuxt.js. In base ai feedback ricevuti, ci auguriamo inoltre di migliorare ulteriormente il componente Script per coprire ulteriori casi d'uso.
Riconoscimenti
Grazie a Kara Erickson, Janicklas Ralph, Katie Hempenius, Philip Walton, Jeremy Wagner e Addy Osmani per il loro feedback su questo post.