Risolvi gli script di terze parti in Next.js per migliorare i Core Web Vitals

Risolvi gli script di terze parti in Next.js

Gli script di terze parti sono la causa più comune di fallimento dei Core Web Vitals su siti Next.js altrimenti ottimizzati. Hai fatto tutto bene: immagini ottimizzate, generazione statica implementata, inlining del critical CSS. Ma la tua Interaction to Next Paint continua a fallire. La causa è quasi sempre JavaScript di terze parti. Secondo il Web Almanac 2025, il 92% delle pagine carica almeno una risorsa di terze parti. Gli script costituiscono il 24,8% di tutte le richieste di terze parti, più di qualsiasi altro tipo di risorsa.

Ultima revisione da parte di Arjen Karel a Marzo 2026

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

Come gli script di terze parti impattano i Core Web Vitals

Gli script di terze parti possono rovinare i tuoi Core Web Vitals in più modi di quanto tu possa probabilmente immaginare. Questi sono alcuni dei problemi che riscontro sui siti web live.

• Rallentano la rete. Gli script di terze parti possono inviare richieste multiple a più server, scaricare file di grandi dimensioni non ottimizzati come immagini e video, scaricare framework e librerie più volte.
• JavaScript di terze parti può bloccare il DOM in qualsiasi momento (o anche più volte durante la visita di una pagina), ritardando la velocità con cui le pagine possono essere renderizzate e utilizzare troppo tempo della CPU, il che può ritardare l'interazione dell'utente e causare il consumo della batteria.
• Gli script di terze parti render blocking possono rappresentare un singolo punto di vulnerabilità (SPOF).
• Gli script di terze parti possono causare problemi di rete dovuti a un HTTP caching mal configurato, alla mancanza di una sufficiente compressione del server e a protocolli HTTP lenti o obsoleti.
• Danneggiano l'UX in molti altri modi, come nascondere i contenuti, bloccare gli eventi del browser (come l'evento window load) o utilizzare API obsolete come document.write.

I numeri fanno riflettere. Il team Chrome Aurora ha scoperto che un contenitore di Google Tag Manager con 18 tag aumenta il Total Blocking Time di quasi 20 volte. Il Web Almanac 2025 riporta un TBT mediano su mobile di 1.916 ms, quasi 10 volte superiore alla best practice di 200 ms. Gli script di terze parti contribuiscono in modo significativo a questo numero.

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

Idealmente, vuoi assicurarti che nessuno script di terze parti abbia un impatto sul critical rendering path. Il tuo primo istinto sarebbe quello di usare l'attributo defer o async. Sfortunatamente, da una prospettiva di timing, questa non è una buona opzione per la maggior parte dei siti Next.js. Un sito Next.js fa grande affidamento 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 occupato a compilare ed eseguire JavaScript di terze parti.

Il componente Script di Next.js

Il componente Script di Next.js (next/script) ti dà il controllo su quando gli script di terze parti si caricano in relazione al codice della tua applicazione. Invece di combattere il comportamento di caricamento predefinito del browser, scegli una strategia che corrisponda all'importanza dello script.

Importalo in qualsiasi componente:

import Script from 'next/script'

Strategia

Con next/script, decidi quando caricare il tuo script di terze parti utilizzando la proprietà strategy. Ci sono quattro strategie di caricamento:

• 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 l'idle time
• worker: Carica uno script in un web worker (sperimentale, solo Pages Router)

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 venga eseguito il JavaScript fornito in bundle (self-bundled).

Dalla prospettiva dei Core Web Vitals, questo è esattamente il tipo di comportamento che vorremmo evitare! La strategia beforeInteractive dovrebbe essere utilizzata solo su script che sono assolutamente critici per la pagina. Non si suppone che gli script di terze parti siano mai 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 di bootstrap viene aggiunta all'HTML generato con l'attributo defer appena prima dei bundle di Next.js. Questo significa che il browser probabilmente recupererà ed eseguirà la libreria bootstrap prima del bundle Next.js. Ciò 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 Interaction to Next Paint ne risentirà probabilmente.

Strategia afterInteractive

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

Da una prospettiva dei Core Web Vitals questo è un posto molto migliore (ma non ancora perfetto) per iniettare script di terze parti. Questa strategia dovrebbe essere utilizzata per gli script che non hanno bisogno di essere caricati il prima possibile e possono essere recuperati ed eseguiti immediatamente dopo che la pagina è diventata 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');
  `,
  }}
/>

Per Google Tag Manager e Google Analytics, ora c'è un'opzione migliore. Consulta la sezione @next/third-parties di seguito.

Strategia lazyOnload

Con la strategia lazyOnload le cose stanno finalmente diventando 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 certo script di terze parti, probabilmente non dovresti affidarti a una terza parte.

Gli script che utilizzano la strategia lazyOnload vengono caricati in ritardo dopo che tutte le risorse sono state recuperate e durante l'idle time. Questo significa che lo script di terze parti non interferirà con i chunk di Next.js e minimizzerà l'impatto che questo script ha sulla Interaction to Next Paint (INP).

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

Strategia worker

La strategia worker è una funzionalità sperimentale che utilizza Partytown per eseguire script in un web worker invece che nel thread principale. Il concetto è interessante: il team Chrome Aurora ha misurato una riduzione del TBT del 92% spostando GTM in un web worker. Ma la strategia worker funziona solo con il Pages Router. Non supporta l'App Router. Il mio consiglio: stanne alla larga finché il progetto non maturerà o finché il DOM non diventerà disponibile per i web worker.

@next/third-parties: l'approccio moderno

Next.js ora fornisce il pacchetto @next/third-parties con componenti ottimizzati per i servizi di terze parti più comuni. Questi componenti gestiscono internamente la strategia di caricamento, quindi non è necessario configurarla da soli.

Installalo:

npm install @next/third-parties

Per Google Tag Manager, aggiungi il componente al tuo layout principale (root layout):

import { GoogleTagManager } from '@next/third-parties/google'

export default function RootLayout({ children }) {
  return (
    <html>
      <GoogleTagManager gtmId="GTM-XXXXXX" />
      <body>{children}</body>
    </html>
  )
}

Per Google Analytics:

import { GoogleAnalytics } from '@next/third-parties/google'

export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        {children}
        <GoogleAnalytics gaId="G-XXXXXX" />
      </body>
    </html>
  )
}

Il team Chrome Aurora riporta che il 66% dei siti Next.js utilizza Google Tag Manager e il 52% utilizza Google Analytics. Se stai caricando uno di questi due, utilizza i componenti dedicati invece del componente Script generico con dangerouslySetInnerHTML. Se utilizzi il dataLayer di GTM, vedi anche il pattern INP di yield per il dataLayer per impedire che gli eventi push blocchino le interazioni.

Quale strategia per quale script?

• GTM e GA: Utilizza i componenti @next/third-parties. Gestiscono il timing internamente.
• Widget di chat (Intercom, HubSpot, Drift): Utilizza lazyOnload. Un widget di chat non è mai critico per la prima interazione.
• A/B testing (Optimizely, VWO): Utilizza beforeInteractive solo se il test influisce sul contenuto above-the-fold. Altrimenti usa afterInteractive.
• Embed social e video player: Utilizza lazyOnload.
• Script per annunci: Utilizza afterInteractive. Gli annunci devono caricarsi ragionevolmente in fretta per le entrate, ma non dovrebbero bloccare l'idratazione.

Nei siti Next.js monitorati da CoreDash, quelli che utilizzano lazyOnload per gli script di analytics mostrano un miglioramento mediano di INP di 27 ms rispetto ad afterInteractive. Questa è la differenza tra il superamento o il fallimento della soglia di INP.

Qualunque strategia tu scelga, verifica i risultati con il Real User Monitoring. I punteggi di laboratorio (lab) ti dicono cosa potrebbe succedere. I dati sul campo (field) ti dicono cosa è successo realmente. E a volte la migliore ottimizzazione è rimuovere gli script di cui non hai bisogno.

Per ulteriori informazioni su come misurare l'impatto, consulta la guida su come misurare i Core Web Vitals in Next.js. Se hai anche a che fare con CSS render blocking in Next.js, risolvilo per primo. Per una visione più ampia su come il browser decide cosa recuperare e quando, consulta la guida alla priorità delle risorse.