I motivi per limitare gli script di analisi e tracciamento

I motivi per limitare gli script di analisi e tracciamento

Trascorro gran parte del mio tempo a controllare siti web e in circa il 90% di questi audit trovo script di tracciamento inutilizzati. Script che nessuno ricorda di aver aggiunto, script che tracciano dati che nessuno legge, script che erano "solo un pixel in più" aggiunti dal marketing due anni fa. Ognuno di essi sembrava innocuo all'epoca. Insieme aggiungono secondi a ogni caricamento della pagina.

Secondo il rapporto sul tracciamento web del 2024 di Kaspersky, il sito web medio ha ora 48 tracker. Il Web Almanac 2025 mostra che oltre il 90% delle pagine web include almeno una terza parte e i 1.000 siti più visitati attivano una mediana di 129 richieste di terze parti su desktop. Questa non è una strategia di tracciamento. Questo è un problema di prestazioni.

Ultima revisione a cura di Arjen Karel nel marzo 2026

Perché i siti usano script di analisi e tracciamento

Gli script di analisi e tracciamento hanno uno scopo reale. Google Analytics ti dice da dove provengono i tuoi visitatori. Facebook Pixel traccia le conversioni degli annunci. Hotjar ti mostra dove le persone cliccano. Senza questi dati, stai procedendo a tentoni.

Il problema non è l'esistenza di questi strumenti. Il problema è che la maggior parte dei siti carica molti più tracciamenti di quelli di cui ha bisogno. Strumenti popolari come Google Analytics, Facebook Pixel e Cloudflare analytics aggiungono tutti JavaScript, cookie e richieste HTTP. E raramente sono l'unico tracciamento sulla pagina.

Fatto: in circa il 90% di tutti gli audit troverò script di tracciamento inutilizzati. Di solito questi script vengono iniettati in ritardo attraverso un tag manager o altri script di terze parti.

Quanto sono pesanti questi script?

Non tutti gli script di tracciamento sono creati uguali. Ecco quanto ti costano effettivamente i più comuni:

• Google Analytics 4 (gtag.js): 134 KB compresso, 371 KB non compresso. Caricato in modo asincrono, quindi non blocca il rendering, ma il JavaScript deve comunque essere analizzato ed eseguito sul thread principale.
• Google Tag Manager: ~33 KB compresso per la libreria stessa, più i tag che ci inserisci. Il contenitore mediano è di circa 50 KB. Un contenitore GTM vuoto aggiunge circa 100 ms di ritardo. Otto tag di tracciamento all'interno di GTM aggiungono circa 3 secondi su 3G veloce e 10 secondi su 3G lento.
• Facebook/Meta Pixel: 340 KB non compresso (95 KB compresso). È 7 volte più grande di Google Analytics. Effettua 4 richieste HTTP prima di terminare e aggiunge da 1,3 a 1,5 secondi a ogni caricamento della pagina.
• Piattaforme di gestione del consenso (CMP): OneTrust può aggiungere da 124 a 347 KB a seconda della configurazione. In un caso, un banner di consenso è diventato l'elemento LCP, portando il LCP da 1,43s a 3,61s.

Sommando GA4 + GTM + Facebook Pixel + un banner di consenso, si arriva a circa 400 - 600 KB di JavaScript di tracciamento prima che venga eseguito il tuo codice. Spesso è più dell'intero contenuto della pagina stessa.

Come gli script di tracciamento influiscono sui Core Web Vitals

Largest Contentful Paint

Ogni script compete per la larghezza di banda della rete e il tempo della CPU durante il caricamento della pagina. Anche gli script asincroni occupano larghezza di banda che potrebbe essere utilizzata per l'immagine LCP o il CSS critico. Quando carichi 8 script di tracciamento insieme alla tua immagine hero, costringi il browser a condividere la sua limitata larghezza di banda mobile tra tutti loro.

Questo è particolarmente grave sulle reti mobili. Il Web Almanac 2025 riporta un Total Blocking Time mediano su dispositivi mobili di 1.916 ms (in aumento del 58% dal 2024). Gran parte di quel blocco deriva da JavaScript di terze parti. Puoi rinviare i tuoi script, ma questi competono comunque per le risorse una volta che iniziano a caricarsi.

Interaction to Next Paint

L'Interaction to Next Paint (INP) è l'area in cui gli script di tracciamento fanno più danni. Il Web Almanac 2024 ha rilevato che il ritardo di presentazione (presentation delay) è il principale responsabile di un INP scadente e gli script che lo causano sono strumenti di tracciamento del comportamento, fornitori di consenso e pixel pubblicitari.

Molti script di tracciamento continuano a funzionare molto tempo dopo il caricamento della pagina. Google Analytics può essere configurato per tracciare ogni clic. Strumenti di mappe di calore (heatmap) come Hotjar ascoltano ogni movimento del mouse. Ognuno di questi event listener aggiunge tempo di elaborazione alle interazioni dell'utente. Quando un visitatore fa clic su un pulsante e il tuo codice impiega 50 ms per gestirlo, ma anche tre script di tracciamento attivano degli event listener che aggiungono altri 150 ms, l'interazione risulta lenta.

I numeri parlano da soli: il 77% di tutte le pagine mobili supera l'INP, ma solo il 53% dei 1.000 siti web più visitati ci riesce. Quei siti principali hanno JavaScript più complesso e più script di terze parti. Se vuoi mantenere reattive le tue pagine, gli script di tracciamento sono il primo posto in cui guardare.

Time to First Byte e sovraccarico dei cookie

Ogni script di tracciamento può inserire i propri cookie. I singoli cookie sono piccoli (una mediana di 40 byte secondo il capitolo Cookies del Web Almanac 2025) ma il loro impatto collettivo si somma perché i dati dei cookie vengono inviati con ogni richiesta HTTP. Se il tuo sito imposta 4 KB di cookie e carica 39 risorse, si tratta di 156 KB di dati di upload extra in tutte quelle richieste.

Quando il totale dei dati dei cookie supera all'incirca 1.500 byte, le intestazioni di richiesta non si adattano più a un singolo pacchetto TCP. Ciò forza viaggi di andata e ritorno (round-trips) extra, aumentando direttamente il tuo Time to First Byte nelle navigazioni successive e nei caricamenti di risorse statiche.

Cumulative Layout Shift

I banner di consenso sono i peggiori trasgressori in questo caso. Quando un banner di consenso sui cookie viene renderizzato in ritardo e spinge verso il basso il contenuto della pagina, causa un layout shift. Alcune piattaforme di consenso iniettano alberi DOM di grandi dimensioni (oltre 200 nodi) che causano il reflow della pagina. In un caso documentato, un banner di consenso era l'elemento LCP per il 50% delle visualizzazioni di pagina perché veniva renderizzato sopra il contenuto effettivo.

Strategie per un tracciamento più intelligente

Verifica cosa usi effettivamente

Apri il tuo tag manager e analizza ogni singolo tag. Per ognuno, chiediti: chi legge questi dati? Quando è stato controllato l'ultima volta? Se nessuno sa rispondere, rimuovilo. Trovo regolarmente tag per strumenti di A/B testing derivanti da campagne terminate mesi fa, pixel per piattaforme pubblicitarie che l'azienda non usa più e implementazioni di analisi duplicate (sia GA4 tramite GTM sia un gtag.js hardcoded).

Ritarda gli script non essenziali

Non tutto ha bisogno di essere caricato alla visualizzazione della pagina. Nessuno è mai rimasto deluso dal fatto che uno script di heatmap abbia impiegato 3 secondi per iniziare a registrare. Attiva i tag di analisi e tracciamento all'evento Window Loaded o, ancora meglio, rinviali finché l'utente non interagisce con la pagina. I test di AnalyticsMania hanno dimostrato che ritardare l'attivazione dei tag di 1,5 secondi dopo il caricamento della pagina fa risparmiare 6 secondi su connessioni 3G lente.

// Carica analytics solo dopo la prima interazione dell'utente
const events = ['click', 'scroll', 'mousemove', 'touchstart'];
const loadAnalytics = () => {
    events.forEach(e => document.removeEventListener(e, loadAnalytics));
    // Carica qui il tuo script di analytics
    const script = document.createElement('script');
    script.src = 'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX';
    document.head.appendChild(script);
};
events.forEach(e => document.addEventListener(e, loadAnalytics, {once: true}));

Usa l'API Beacon per eventi personalizzati

Se invii eventi di analisi personalizzati (invii di moduli, clic su pulsanti, profondità di scorrimento), usa navigator.sendBeacon() invece di XMLHttpRequest. L'API Beacon invia dati in modo asincrono senza bloccare il thread principale ed è garantito che venga completata anche durante la navigazione della pagina. Questo è particolarmente importante per mantenere basso l'INP sulle interazioni che innescano chiamate di analisi.

// Invia dati di analytics senza bloccare l'interazione
document.querySelector('.buy-button').addEventListener('click', (e) => {
    // Usa sendBeacon: non bloccante, sopravvive alla navigazione della pagina
    navigator.sendBeacon('/analytics', JSON.stringify({
        event: 'purchase_click',
        timestamp: Date.now()
    }));
});

Prendi in considerazione alternative lato server

Il modo più efficace per eliminare il JavaScript di tracciamento è non caricarlo affatto. Zaraz di Cloudflare sposta l'esecuzione delle analisi all'edge, sostituendo gli script del tag manager lato client con un beacon leggero. I contenitori Server-Side di GTM consentono al tuo server di inoltrare dati ai fornitori di analisi senza che alcun JavaScript del fornitore raggiunga il browser. Questi approcci richiedono più impegno per essere configurati ma il loro impatto sulle prestazioni è vicino allo zero.

Per esigenze più semplici, alternative leggere come Plausible (sotto 1 KB) o Umami (circa 2 KB) forniscono analisi del traffico a una frazione del costo di 134 KB di GA4.

Qual è il quadro ottimale

Nei siti monitorati da CoreDash, le pagine che caricano meno di 5 script di terze parti superano l'INP all'incirca nell'88% dei casi, rispetto al 64% per le pagine che ne caricano 15 o più. La differenza nel LCP è altrettanto chiara: un minor numero di richieste concorrenti significa che il browser può dare la priorità a ciò che conta davvero per il visitatore.

Non è necessario rimuovere tutto il tracciamento. Devi essere intenzionale su ciò che carichi, su quando lo carichi e se qualcuno usa effettivamente i dati. Inizia controllando il tuo tag manager. Rimuovi ciò che non ti serve. Ritarda ciò di cui hai bisogno. Usa il Real User Monitoring per verificare il miglioramento nei dati di campo, perché i test di laboratorio non ti mostreranno il quadro completo di come gli script di tracciamento interagiscono con le reali condizioni di rete e il reale comportamento degli utenti.