Su molti siti il codice scritto dagli sviluppatori è solo una parte di ciò che il browser esegue. Il resto arriva da fornitori esterni: piattaforme di analytics, pixel pubblicitari, strumenti di heatmap, widget di chat, sistemi di recensioni, gestori del consenso. Ognuno sembra innocuo preso da solo, ma insieme possono occupare il main thread per secondi, aprire connessioni verso decine di domini e peggiorare tutti i Core Web Vitals.
Il problema è anche organizzativo: questi script vengono spesso aggiunti da reparti diversi, tramite un tag manager, senza che nessuno ne valuti il costo complessivo.
Perché pesano così tanto
Uno script esterno costa in più modi:
- connessioni: ogni nuovo dominio richiede risoluzione DNS, connessione e negoziazione TLS prima del primo byte;
- download: molti script sono voluminosi e caricano a loro volta altri script, in catene che non si vedono dal codice della pagina;
- esecuzione: il JavaScript va analizzato, compilato ed eseguito sul main thread, generando task lunghi che peggiorano l'INP;
- effetti sul layout: banner, widget e annunci che compaiono dopo il caricamento spostano i contenuti e aumentano il CLS;
- imprevedibilità: il fornitore può cambiare lo script in qualsiasi momento, e una pagina veloce oggi può diventare lenta domani senza che sia stato modificato nulla.
C'è infine il rischio di dipendenza: uno script caricato in modo sincrono nell'head che non risponde può bloccare la visualizzazione della pagina finché la richiesta non va in timeout.
Fare l'inventario
Il primo passo è sapere cosa c'è davvero. Un metodo pratico:
- apri il pannello Network di DevTools, carica la pagina e ordina per dominio: tutto ciò che non appartiene al sito è terza parte;
- nel pannello Performance, registra un caricamento e guarda il riepilogo per entità, che attribuisce il tempo di esecuzione ai singoli fornitori;
- in Lighthouse, il controllo sulle terze parti elenca i fornitori con dimensione trasferita e tempo di blocco del main thread;
- esporta l'elenco dei tag dal tag manager e confrontalo con ciò che vedi in rete: spesso emergono tag dimenticati di campagne concluse.
Per ogni voce annota a cosa serve, chi l'ha richiesta e chi usa davvero i dati raccolti. È frequente scoprire due strumenti di analytics che misurano la stessa cosa, o un pixel di una piattaforma pubblicitaria non più usata.
Misurare l'impatto per sottrazione
Il modo più convincente per dimostrare il costo di uno script è toglierlo e misurare. In DevTools, nel pannello Network, si può bloccare un dominio o un singolo URL con il comando di blocco delle richieste, poi ricaricare la pagina e confrontare i tempi. Strumenti di test sintetico come WebPageTest permettono di fare lo stesso in modo ripetibile, eseguendo più prove con e senza i domini indicati.
Presentare un confronto del tipo «con il widget l'LCP è X, senza è Y» rende la discussione concreta e sposta la decisione dal gusto personale ai numeri.
Tecniche di caricamento
Una volta deciso cosa tenere, conta il modo in cui lo si carica.
| Situazione | Tecnica |
|---|---|
| Script non necessario al primo rendering | async o defer, mai sincrono nell'head |
| Widget usato solo da alcuni utenti | caricamento al primo clic o interazione |
| Script utile solo dopo il caricamento | iniezione dopo l'evento load o in un momento di inattività |
| Dominio esterno critico | preconnect per anticipare la connessione |
| Libreria stabile e versionata | ospitarla sul proprio dominio |
Ospitare una copia sul proprio dominio elimina una connessione e mette lo script sotto le proprie regole di cache, ma ha senso solo per file che non devono aggiornarsi da soli: molti script di analytics e pubblicità vanno invece caricati dall'origine del fornitore.
Esistono anche librerie, come Partytown, che spostano l'esecuzione di alcuni script di terze parti in un web worker per liberare il main thread. Funzionano bene con certi tipi di script e meno con altri, quindi vanno provate caso per caso.
Il ruolo del consenso
Dove serve il consenso dell'utente, gli script di tracciamento non devono partire prima della scelta. Questo, oltre a essere corretto, è anche un vantaggio di prestazioni: il primo caricamento è più leggero. Attenzione però al banner stesso: deve avere uno spazio riservato o comparire in sovrimpressione, altrimenti diventa una fonte di CLS, e il suo script non deve bloccare il rendering.
Una regola per il futuro
Il controllo una tantum non basta, perché nuovi tag arrivano continuamente. Funziona meglio una piccola procedura: ogni nuova terza parte richiede una motivazione scritta, un responsabile e una misura dell'impatto; ogni trimestre si rivede l'elenco e si rimuove ciò che non serve. Nel mio lavoro questa revisione periodica porta quasi sempre a togliere qualcosa.
In sintesi
- Le terze parti costano in connessioni, download, esecuzione e stabilità del layout.
- Fai l'inventario con DevTools, Lighthouse e l'elenco del tag manager.
- Dimostra il costo bloccando lo script e misurando la differenza.
- Carica in modo asincrono, rimanda ciò che non serve subito e valuta l'hosting locale.
- Stabilisci una procedura di approvazione e una revisione periodica dei tag.
