NextJS Core Web Vitals - come risolvere i problemi degli script di terze parti

Come risolvere gli Script di terze parti in NextJS

Gli Script di terze parti sono script che aggiungono funzionalità di terze parti ai tuoi siti web. Spesso questi script sono ospitati da una terza parte, anche se di solito non è strettamente necessario (puoi, ad esempio, ospitare autonomamente il file JavaScript di analytics). Gli script di terze parti forniscono un'ampia gamma di funzionalità utili, rendendo il web più dinamico, interattivo e interconnesso. Questi script possono essere cruciali per la funzionalità del tuo sito web o per il flusso di entrate. Ma gli script di terze parti comportano anche molti rischi che dovrebbero essere presi in considerazione per minimizzare il loro impatto pur continuando a fornire valore.

Immagina: sei il fiero proprietario di un sito Next.js ottimizzato. Hai ottimizzato tutto il tuo codice, implementato una qualche forma di generazione statica, ottimizzato tutte le tue immagini, implementato il Critical CSS ma il tuo sito ancora non supera i Core Web Vitals. Cosa sta succedendo?

Potrebbe essere a causa degli script di terze parti come annunci, analytics, pulsanti per i social media, widget, script di A/B testing, video player e così via.

Come gli Script di terze parti influenzano i Core Web Vitals

Gli Script di terze parti possono compromettere i tuoi Core Web Vitals in più modi di quanti tu possa probabilmente immaginare. Ecco alcuni dei problemi che ho riscontrato su siti web reali.

• Rallentano la rete. Gli script di terze parti possono inviare molteplici richieste a molteplici server, scaricare file grandi e non ottimizzati come immagini e video, scaricare framework e librerie più volte.
• Il JavaScript di terze parti può bloccare il DOM in qualsiasi momento (o anche più volte durante una visita alla pagina), ritardando la velocità di rendering delle pagine e utilizzando troppo tempo CPU, il che può ritardare l'interazione dell'utente e causare un consumo eccessivo della batteria.
• Gli script di terze parti che bloccano il rendering possono rappresentare un singolo punto di errore (SPOF)
• Gli script di terze parti possono causare problemi di rete a causa di cache HTTP mal configurata, mancanza di sufficiente compressione del server e protocolli HTTP lenti/obsoleti
• Danneggiare la user experience in molti altri modi, come nascondere contenuti, bloccare eventi del browser (come l'evento window load) o utilizzare API obsolete come document.write

Risolvere gli script di terze parti e i Core Web Vitals in Next.js

Idealmente, vorrai assicurarti che gli script di terze parti non influenzino il percorso di rendering critico. La tua soluzione predefinita sarebbe usare l'attributo defer o async. Sfortunatamente, in termini di tempistica, questa non è una buona opzione per la maggior parte dei siti Next.js. Un sito Next.js si basa pesantemente su JavaScript per idratare la pagina.

Questo significa che non appena i bundle di Next.js sono stati scaricati, il browser eseguirà quel JavaScript. Questo richiede tempo e risorse. Questo processo rallenterà quando il browser è troppo impegnato a compilare ed eseguire JavaScript di terze parti.

Introduzione al componente Script di Next.js

Il componente Script di Next.js, next/script, è un'estensione dell'elemento HTML <script>. Permette agli sviluppatori di impostare la priorità di caricamento degli script di terze parti ovunque nella loro applicazione, al di fuori di next/head, risparmiando tempo agli sviluppatori e migliorando le prestazioni di caricamento.

Per aggiungere uno script di terze parti alla tua applicazione, importa il componente next/script:

import Script from 'next/script'

Strategy

Con next/script, decidi quando caricare il tuo script di terze parti utilizzando la proprietà strategy:

Ci sono tre diverse strategie di caricamento che possono essere utilizzate:

• beforeInteractive: Carica uno script prima che la pagina sia interattiva
• afterInteractive: Carica uno script immediatamente dopo che la pagina diventa interattiva
• lazyOnload: Carica uno script durante il tempo di inattività
• worker: Carica uno script in un web worker

La strategia beforeInteractive

Gli script che si caricano con la strategia beforeInteractive vengono iniettati nell'HTML iniziale dal server con l'attributo defer abilitato e vengono eseguiti prima che il JavaScript auto-impacchettato venga eseguito.

Dal punto di vista dei Core Web Vitals, questo è esattamente il tipo di comportamento che vorremmo evitare! La strategia beforeInteractive dovrebbe essere utilizzata solo per script assolutamente critici per la pagina. Gli script di terze parti non dovrebbero mai essere critici!

<Script
  id="bootstrap-cdn"
  src="https://cdn.jsdelivr.net/npm/bootstrap@5.1.3/dist/js/bootstrap.bundle.min.js"
  strategy="beforeInteractive"
 />

In questo caso la libreria JavaScript bootstrap viene aggiunta all'HTML generato con l'attributo defer appena prima dei bundle di next.js. Questo significa che il browser probabilmente scaricherà ed eseguirà la libreria bootstrap prima del bundle di next.js. Questo ritarderà l'idratazione di next.js e probabilmente bloccherà il thread principale quando il browser dovrebbe scaricare ed eseguire i chunk di next.js. Per i Core Web Vitals questo significa che il First Input Delay sarà probabilmente influenzato.

La strategia afterInteractive

Gli script che utilizzano la strategia afterInteractive vengono iniettati lato client e verranno scaricati dopo che Next.js ha idratato la pagina.

Dal punto di vista dei Core Web Vitals questa è una posizione molto migliore (ma non ancora perfetta) per iniettare script di terze parti. Questa strategia dovrebbe essere utilizzata per script che non hanno bisogno di caricarsi il prima possibile e possono essere scaricati ed eseguiti immediatamente dopo che la pagina è interattiva.

<Script
  strategy="afterInteractive"
  dangerouslySetInnerHTML={{
    __html: `
    (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
    new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
    j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
    'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
    })(window,document,'script','dataLayer', 'GTM-XXXXXX');
  `,
  }}
/>

La strategia lazyOnload

Con la strategia lazyOnload le cose iniziano finalmente a diventare interessanti! Il modo in cui penso agli script di terze parti è semplice: 'non dovrebbero essere critici per una pagina'. Se non puoi vivere senza un determinato script di terze parti, probabilmente non dovresti affidarti a una terza parte.

Gli script che utilizzano la strategia lazyOnload vengono caricati tardi, dopo che tutte le risorse sono state scaricate e durante il tempo di inattività. Questo significa che lo script di terze parti non interferirà con i chunk di next.js e minimizzerà l'impatto che questo script ha sul First Input Delay (FID)

<Script
  id="some-chat-script"
  src="https://example.com/chatscript.js"
  strategy="lazyOnload"
 />

La strategia worker