Un sito moderno raramente è fatto solo del proprio codice. Accanto a tema e applicazione convivono strumenti di analisi, tag manager, pixel pubblicitari, chat, widget di recensioni, test A/B, mappe di calore, banner per il consenso, video e mappe incorporati. Ognuno ha una buona ragione per esserci, e ognuno è stato aggiunto in un momento diverso, spesso da persone diverse. Il risultato è una parte consistente della pagina che nessuno del team ha scritto, che cambia senza preavviso e che, in molti siti, pesa sulle Core Web Vitals più di tutto il resto messo insieme.
In questo articolo vediamo come gli script di terze parti incidono su caricamento, reattività e stabilità, come misurarne il costo reale e come governarli senza rinunciare agli strumenti di cui il marketing ha bisogno.
Che cosa sono le terze parti
Si definisce di terze parti qualsiasi risorsa che la pagina carica da un dominio che non controlliamo: uno script di analisi servito dal fornitore, il codice di una chat, il player di un video, un font da un servizio esterno, le immagini di un widget di recensioni. La distinzione non riguarda l’utilità, ma il controllo: il codice può cambiare in qualsiasi momento, può caricare a sua volta altre risorse e dipende dall’infrastruttura del fornitore.
Le categorie più comuni sono sempre le stesse: analisi e misurazione, tag manager, pixel delle piattaforme pubblicitarie e dei social, strumenti di test e personalizzazione, chat e assistenza, recensioni e prova sociale, mappe di calore e registrazione delle sessioni, gestione del consenso, contenuti incorporati come video, mappe e post dei social, e naturalmente la pubblicità.
Come pesano sulle Core Web Vitals
Il costo di una terza parte non si limita ai kilobyte scaricati. Agisce su più fronti contemporaneamente.
- Nuove connessioni. Ogni dominio diverso richiede risoluzione DNS, connessione e negoziazione TLS. Su una rete mobile ciascuna può costare centinaia di millisecondi, e una pagina con quindici domini esterni ne paga molte.
- Lavoro sul thread principale. Il JavaScript va scaricato, analizzato ed eseguito, spesso in task lunghi che bloccano il browser. È il fattore che più incide sull’INP: un tocco che arriva mentre un pixel pubblicitario sta lavorando deve aspettare.
- Blocco del rendering. Uno script sincrono nell’
<head>ferma la costruzione della pagina finché non è stato scaricato ed eseguito, ritardando FCP e LCP. - Spostamenti del layout. Widget, banner e annunci inseriti dopo il primo disegno spingono il contenuto e peggiorano il CLS.
- Imprevedibilità. Il fornitore può aggiornare il proprio codice in qualsiasi momento: una pagina che ieri era veloce può rallentare oggi senza che nessuno abbia toccato il sito.
La cascata: tag che caricano altri tag
Il tag manager ha reso semplicissimo aggiungere strumenti senza passare dagli sviluppatori, ed è una comodità reale. Ma ha anche reso invisibile la crescita: ogni tag è una riga in un pannello, e ogni tag può caricare altri script, che a loro volta ne caricano altri. Il codice effettivamente eseguito nella pagina diventa una cascata che nessuno ha davvero progettato.
Sul thread principale di uno smartphone di fascia media, questa cascata si traduce in lunghi blocchi di lavoro che non hanno nulla a che fare con il contenuto della pagina. È frequente che, in un audit, il codice del sito occupi una frazione del tempo di esecuzione e il resto sia di terze parti.
Il caso dei test A/B
Gli strumenti di test e personalizzazione meritano un’attenzione particolare. Per evitare che l’utente veda per un istante la versione originale prima di quella del test, molti di essi usano uno snippet che nasconde l’intera pagina finché lo script dell’esperimento non è stato caricato, con un tempo massimo che può arrivare a qualche secondo. Dal punto di vista delle metriche è un disastro silenzioso: per tutto quel tempo la pagina è bianca, e l’LCP ne porta il segno. Se un test A/B è necessario, conviene eseguirlo lato server o limitare lo snippet alle sole pagine coinvolte e con il tempo massimo più breve possibile.
Come misurare il costo reale
Prima di intervenire bisogna sapere quanto costa ciascuna terza parte. Gli strumenti non mancano:
- Lighthouse riassume il tempo di esecuzione e il peso delle terze parti raggruppati per fornitore, e segnala quelle che bloccano il thread principale.
- Il pannello Performance dei DevTools mostra nella traccia quali script occupano il thread principale e quando, distinguendo il codice di prima e di terza parte.
- Il blocco delle richieste, disponibile sia nei DevTools sia in WebPageTest, permette di caricare la pagina senza un determinato dominio e confrontare le metriche: è il modo più diretto per misurare il costo di un singolo fornitore.
- Il monitoraggio degli utenti reali, con l’attribuzione dell’INP e dei frame lenti, rivela quali script sono coinvolti nelle interazioni lente sui dispositivi dei visitatori.
Il confronto con e senza un dominio è particolarmente utile nelle discussioni con il marketing: trasformare “questo script rallenta il sito” in “questo script aggiunge 400 millisecondi di blocco su mobile” rende la decisione molto più concreta.
Primo passo: l’inventario
Governare le terze parti comincia con un elenco. Per ogni script: che cosa fa, chi lo ha richiesto e ne è responsabile, su quali pagine serve davvero, quanto costa, e se è ancora usato. In quasi tutti gli audit emergono tag di campagne concluse, strumenti di prova mai disattivati, due soluzioni che fanno la stessa cosa, pixel di piattaforme abbandonate. Rimuovere ciò che non serve è l’ottimizzazione più efficace e l’unica senza controindicazioni.
Caricare meno, e al momento giusto
Per ciò che resta, le leve sono diverse e vanno combinate:
- Solo dove serve. Il pixel di conversione serve nella pagina di conferma d’ordine, la chat forse solo nelle pagine di prodotto e di contatto, la mappa solo nella pagina dei punti vendita. Nel tag manager basta un attivatore limitato alle pagine giuste.
- Mai sincroni. Gli script di terze parti vanno caricati con
asyncodefer, e mai in modo bloccante nell’<head>, salvo rarissime eccezioni documentate. - Dopo il contenuto. Ciò che non serve al primo schermo può partire dopo il caricamento o quando il browser è inattivo. Rinviarlo fino alla prima interazione è possibile, ma sposta il costo proprio su quell’interazione, come abbiamo spiegato parlando del delay al primo clic.
- Rispettando il consenso. Gli strumenti di profilazione non devono partire prima del consenso dell’utente: è un obbligo di legge prima ancora che un’ottimizzazione, e riduce naturalmente il carico per chi non accetta.
- Connessioni anticipate, con misura. Per uno o due domini critici, un
preconnectanticipa DNS e TLS; usato per tutti i domini, invece, disperde risorse.
Le facciate
Per i contenuti incorporati pesanti la tecnica più efficace è la facciata: al posto del componente vero si mostra un’anteprima statica che gli somiglia, e il componente si carica solo quando l’utente mostra di volerlo usare. Un video incorporato, per esempio, può caricare diverse centinaia di kilobyte di script e stili anche se nessuno lo guarderà mai; con una facciata si mostra solo l’immagine di anteprima e un pulsante, e il player arriva al clic.
Lo stesso principio vale per le chat, che possono essere sostituite da un pulsante che carica il widget solo quando viene toccato, per le mappe, che possono partire da un’immagine statica, e per i post dei social incorporati. L’importante è che la facciata abbia le stesse dimensioni del componente finale, per non introdurre spostamenti del layout.
<button class="video-facciata" data-video="ID_DEL_VIDEO" aria-label="Riproduci il video">
<img src="/img/anteprima-video.avif" width="1280" height="720" alt="" loading="lazy">
</button>
<script>
document.querySelectorAll( '.video-facciata' ).forEach( ( el ) => {
el.addEventListener( 'click', () => {
const iframe = document.createElement( 'iframe' );
iframe.src = 'https://www.youtube-nocookie.com/embed/' + el.dataset.video + '?autoplay=1';
iframe.allow = 'autoplay; encrypted-media';
iframe.width = 1280;
iframe.height = 720;
el.replaceWith( iframe );
}, { once: true } );
} );
</script>Spostare il lavoro sul server
Una strada sempre più diffusa è il tracciamento lato server: invece di caricare nel browser un pixel per ogni piattaforma, la pagina invia gli eventi a un unico punto di raccolta sul proprio dominio, che li inoltra poi alle varie piattaforme dal server. Il browser esegue un solo script leggero, le connessioni verso domini esterni diminuiscono e il controllo sui dati inviati aumenta. Richiede un’infrastruttura dedicata e una configurazione attenta, soprattutto per il consenso, ma nei siti con molti pixel pubblicitari il beneficio è sensibile.
Quando la licenza lo consente, anche ospitare sul proprio dominio alcune librerie, invece di caricarle dal servizio del fornitore, elimina connessioni e rende il caricamento più prevedibile. Va fatto con criterio, perché si perde l’aggiornamento automatico del fornitore.
Un esempio di riordino
Per rendere concreto il metodo, immaginiamo un e-commerce di medie dimensioni con un tag manager che, negli anni, ha accumulato una ventina di tag. Il lavoro si svolge in genere in quattro passaggi.
- Fotografia. Si registra lo stato attuale: domini contattati, peso e tempo di esecuzione delle terze parti in laboratorio da mobile, e INP e LCP sui dati degli utenti reali per le pagine principali, cioè home, categorie, schede prodotto e carrello.
- Pulizia. Insieme al marketing si rivede l’elenco: si eliminano i pixel di piattaforme non più usate e gli strumenti di prova dimenticati, si unificano le soluzioni doppie, si disattivano i tag di campagne concluse.
- Riorganizzazione. Ciò che resta viene attivato solo dove serve e dopo il consenso; chat e video passano a una facciata; i tag non necessari al primo schermo partono dopo il caricamento; dove il numero di pixel lo giustifica, si valuta il tracciamento lato server.
- Verifica. Si ripetono le misure di laboratorio e, nelle settimane successive, si confrontano i dati reali sulla stessa finestra di tempo, controllando anche che i report del marketing non abbiano perso eventi.
L’ultimo punto è spesso trascurato ed è invece essenziale: un’ottimizzazione che rompe il tracciamento delle conversioni viene annullata alla prima riunione. Misurare prima e dopo sia le prestazioni sia i dati di marketing è ciò che rende il risultato duraturo.
Un processo, non un intervento
Le terze parti tendono a tornare. Un sito ripulito oggi si riempie di nuovo in pochi mesi, a ogni campagna e a ogni nuovo strumento provato. Per questo servono regole condivise tra sviluppo e marketing: un budget di prestazioni per le pagine principali, un passaggio di verifica prima di aggiungere un nuovo tag, un responsabile per ogni script e una revisione periodica dell’inventario. Il monitoraggio degli utenti reali, con avvisi sulle soglie delle Core Web Vitals, segnala in fretta quando un nuovo strumento, o un aggiornamento di uno esistente, peggiora l’esperienza.
È anche una questione di linguaggio comune. Il marketing ha bisogno di misurare le campagne, e ha ragione; il team tecnico ha bisogno di pagine veloci, e ha ragione anche lui. Mettere sul tavolo il costo di ciascuno strumento, in millisecondi e in impatto sulle conversioni, permette di scegliere insieme che cosa vale la pena tenere.
In sintesi
Gli script di terze parti aggiungono connessioni, occupano il thread principale, possono bloccare il rendering e spostare il layout, e cambiano senza preavviso. Spesso pesano sulle Core Web Vitals più del codice del sito stesso. Governarli significa conoscerli con un inventario, misurarne il costo, eliminare ciò che non serve, caricare il resto solo dove e quando è necessario, usare facciate per i componenti pesanti e, dove ha senso, spostare il lavoro sul server.
Non si tratta di rinunciare agli strumenti di marketing, ma di trattarli per ciò che sono: codice eseguito sui dispositivi dei clienti, con un costo che ricade sull’esperienza e quindi sui risultati. Ogni tag dovrebbe guadagnarsi il proprio posto nella pagina.
