⚡ GTM e velocità della pagina: test, risultati e 8 modi per velocizzare il tuo sito

Ecco la traduzione del frammento:

I marketer ripetono spesso: «Google Tag Manager velocizza i siti, le pagine con GTM si caricano più in fretta». Gli sviluppatori di solito ribattono: «GTM non fa che rallentare le cose». La verità, come sempre, sta nel mezzo.

Abbiamo condotto una serie di test con diverse configurazioni di GTM: un contenitore vuoto, un contenitore con 8 codici di tracciamento, tag inseriti direttamente nel codice, diversi momenti di attivazione dei trigger, decine di tag HTML personalizzati con manipolazioni del DOM. Abbiamo misurato la velocità tramite webpagetest.org e Lighthouse. I risultati si sono rivelati meno netti di quanto sostengano le presentazioni su GTM.

Ecco cosa abbiamo scoperto: il contenitore GTM di per sé non rallenta quasi nulla, ma ciò che ci metti dentro può aggiungere 3 o 10 secondi al caricamento della pagina. E la cosa fondamentale è che puoi controllarlo.

💡 Panoramica rapida:

Un contenitore GTM vuoto aggiunge circa 100 millisecondi al caricamento della pagina
Otto tag di tracciamento via GTM rallentano la pagina di 3 secondi su 3G veloce e fino a 10 secondi su connessioni lente
Gli stessi 8 tag inseriti direttamente nel codice del sito rallentano ancora di più
Più tardi vengono attivati i tag, minore è il loro impatto: un ritardo di 1,5 secondi dopo Window Loaded riduce il tempo di caricamento di 6 secondi su 3G lento
Una configurazione ben pianificata dei trigger e la pulizia del contenitore ripristinano la velocità senza perdita di dati

Come abbiamo testato

La metodologia è semplice ma rigorosa. Abbiamo eseguito ogni test almeno tre volte e calcolato la media.

Strumenti: webpagetest.org (server in Irlanda, EC2, Chrome e Firefox per desktop, OnePlus 5 per i test mobile) e l'audit Lighthouse integrato in Chrome DevTools. In Lighthouse abbiamo esaminato sia i report mobile che desktop. Chrome è stato avviato in modalità incognito, senza estensioni, prestazioni del portatile al massimo.

Metriche misurate:

In webpagetest.org: Document complete (secondi fino al caricamento di contenuti statici, immagini, stili) e Fully loaded (il punto dopo onLoad in cui l'attività di rete si ferma per 2 secondi). In Lighthouse: First Meaningful Paint, Time to Interactive, First CPU Idle e Max Potential First Input Delay (FID).

Codici di tracciamento nei test: Google Analytics (gtag.js), Facebook Pixel, Reddit Pixel, Quora Pixel, LinkedIn Insights, Twitter Universal Tag, Google Ads Remarketing (gtag.js), Hotjar. Otto script ampiamente utilizzati.

Scenari confrontati:

Pagina pulita senza script di terze parti e senza GTM
Pagina con 8 codici di tracciamento inseriti direttamente prima di </head>, senza GTM
Contenitore GTM vuoto senza tag
Tutti gli 8 tag via GTM, trigger All Pages (noto anche come gtm.js)
Gli stessi 8 tag via GTM, trigger DOM Ready (gtm.dom)
Gli stessi 8 tag via GTM, trigger Window Loaded (gtm.load)
Gli stessi 8 tag, attivati 1,5 secondi dopo Window Loaded
Contenitore GTM con modalità anteprima e debug attiva
Contenitore GTM con 100 tag HTML personalizzati che aggiungono elementi in fondo al <body>
Contenitore GTM con 100 tag HTML personalizzati che aggiungono elementi in un punto specifico della pagina (dopo l'H2)
Contenitore GTM con 100 tag HTML personalizzati che cercano tutti i link e inseriscono un elemento dopo il 21°
Contenitore GTM con 1976 variabili costanti (riempito al massimo, 200 KB)

Cosa hanno mostrato i test

Asincrono non significa «senza conseguenze»

Gli script asincroni non bloccano direttamente il rendering. Ma hanno comunque bisogno di risorse della CPU, il che significa che gli script principali del sito vengono eseguiti più lentamente. In pratica: l'evento Document Complete su una pagina pulita si è verificato dopo 4 secondi. Con otto tag, dopo 7,7 secondi. Una differenza di 3,7 secondi solo perché il processore è occupato con script di terze parti.

Confronto del tempo di Document Complete senza tag e con tag

Anche un contenitore GTM vuoto ha leggermente aumentato il tempo di caricamento, di circa 100 millisecondi.

Impatto di un container GTM vuoto sul tempo di caricamento

Il problema non è GTM, ma cosa ci metti dentro

Un contenitore GTM vuoto aggiunge circa 100 millisecondi al caricamento della pagina, a volte non c'è alcun ritardo. I problemi iniziano quando riempi il contenitore di tag. Ma anche in questo caso, le cose non sono lineari.

Otto tag di tracciamento hanno rallentato la pagina di circa 3 secondi su una connessione 3G veloce e di 10 secondi su connessioni lente. Ogni tag richiama il proprio script e il browser impiega tempo a eseguirli.

Document Complete senza tag e con 8 tag in GTM

Ma un contenitore riempito con 1976 variabili costanti (200 KB, il limite di GTM) ha aggiunto solo 0,1-0,3 secondi. Le variabili non caricano script esterni e non manipolano il DOM, quindi il loro impatto è minimo.

Conclusione: ciò che conta non è la dimensione del contenitore, ma quali azioni eseguono i suoi elementi.

I tag inseriti direttamente nel codice rallentano più degli stessi tag via GTM

Quando abbiamo aggiunto 8 script di tracciamento direttamente nel codice del sito, la pagina ha rallentato in modo ancora più evidente. Su 3G veloce, i tag inseriti direttamente hanno aggiunto circa 600 millisecondi di ritardo in più rispetto agli stessi tag lanciati tramite GTM.

Confronto tra tag hard-coded e tag via GTM

Nel secondo grafico, la stessa situazione da un'altra angolazione: gli script inseriti direttamente perdono costantemente contro GTM nel tempo di Document Complete.

Document Complete tag hard-coded contro GTM

GTM aiuta davvero le pagine a caricarsi leggermente più velocemente rispetto a quando gli script sono aggiunti direttamente al codice. Ma questa non è una regola universale. Ci sono scenari in cui lanciare JS senza GTM può essere implementato in modo più efficiente, e Simo Ahava, uno dei massimi esperti di GTM, concorda su questo punto.

Il momento di attivazione del tag è importante

Più tardi un tag viene attivato, meno influisce sul caricamento iniziale della pagina. Abbiamo testato quattro momenti:

Page View (gtm.js), immediatamente al caricamento del contenitore
DOM Ready (gtm.dom), quando il DOM è costruito
Window Loaded (gtm.load), quando tutte le risorse sono caricate
afterLoad, 1,5 secondi dopo Window Loaded (trigger personalizzato)

Codice del trigger personalizzato afterLoad:

1 <script>
2   (function() {
3     try {
4       window.setTimeout(function(){
5         dataLayer.push({
6           'event': 'afterLoad'
7         });
8       }, 1500);
9     } catch (err) {}
10   })();
11 </script>

Risultato: DOM Ready e Window Loaded hanno dato un piccolo miglioramento. Ma il guadagno più significativo è arrivato da afterLoad. Su 3G lento, il ritardo si è ridotto di 6 secondi rispetto al trigger Page View. Su 3G veloce, di 600 millisecondi.

Confronto del Fully Loaded per diversi momenti di attivazione dei tag

Perché funziona? La pagina può avere elementi che vengono caricati dinamicamente solo dopo che tutte le risorse sono state caricate completamente. Se i tag rallentano il caricamento iniziale, anche questi elementi appariranno più tardi. Ritardando i tag non critici, permetti al contenuto principale di caricarsi senza interferenze.

Ma c'è un avvertimento: se ritardi tag la cui accuratezza dipende da questo (Google Analytics), alcuni visitatori potrebbero lasciare la pagina prima che il contatore venga attivato. I tuoi report perderanno alcuni dati. La decisione di ritardare i tag va presa con il team, non unilateralmente da uno sviluppatore o da un marketer.

I tag di tracciamento non sono gli unici colpevoli

Un altro gruppo di tag "pesanti" sono quelli che manipolano il DOM. Ad esempio, i tag HTML personalizzati che aggiungono o modificano elementi sulla pagina.

Abbiamo testato diverse varianti:

100 tag HTML personalizzati che aggiungono elementi alla fine del <body>. Ogni tag eseguiva un semplice script console.log('hello') e creava un <div>Hello!</div>. Senza specificare una posizione di inserimento particolare. L'impatto sulla velocità di caricamento della pagina si è rivelato minimo, gli elementi venivano semplicemente aggiunti in fondo.

100 tag HTML personalizzati che aggiungono elementi in un punto specifico della pagina. Ogni tag cercava il primo h2 e inseriva un h3 dopo di esso. Script:

1 <script>
2   (function() {
3     var h3 = document.createElement('h3');
4     h3.innerText = "An additional element";
5     var title = document.querySelector('h2');
6     if (title) {
7       title.parentElement.insertBefore(h3, title.nextSibling);
8     }
9   })();
10 </script>

Questo ha aggiunto diverse centinaia di millisecondi al caricamento della pagina. Sebbene lo script sia primitivo, cercare un elemento e inserirlo richiede risorse.

Impatto di 100 tag con manipolazioni DOM sul Fully Loaded

100 tag HTML personalizzati che cercano tutti i link sulla pagina e inseriscono un elemento dopo il ventunesimo. Script:

1 <script>
2   (function() {
3     var h3 = document.createElement('h3');
4     h3.innerText = "An additional element";
5     var element = document.querySelectorAll('a')[20];
6     if (element) {
7       element.parentElement.insertBefore(h3, element.nextSibling);
8     }
9   })();
10 </script>

Differenza rispetto all'esperimento precedente: querySelectorAll itera su tutti gli elementi della pagina, controllandoli uno per uno, il che è più oneroso. Su webpagetest.org la differenza era minima (100-200 ms), ma Lighthouse ha mostrato un aumento di 2-3 secondi del Time to Interactive. Questo significa che durante il caricamento della pagina, il browser è così impegnato a inserire elementi da non rispondere alle azioni dell'utente.

Time to Interactive con pesanti manipolazioni DOM

Certo, 100 script identici sono un'esagerazione. Ma il punto è che anche pochi tag complessi che manipolano il DOM possono produrre un effetto simile.

Come ridurre l'impatto di GTM sulla velocità: 8 tecniche

Pulisci regolarmente il container dai tag abbandonati

L'esperienza degli audit mostra che fino a un terzo dei codici di tracciamento sui siti appartiene a strumenti che l'azienda non usa più. Siete passati dallo strumento di analytics X a Z, ma i codici di X si caricano ancora su ogni pagina e la rallentano.

Cosa fare:

Chiedi a uno sviluppatore di fornire un elenco di tutte le richieste HTTP e gli script sulla pagina
Cerca su Google i domini di queste richieste, identifica a quali strumenti appartengono
Chiedi ai colleghi dei diversi reparti quali strumenti sono ancora in uso
Trova gli script "orfani" che non compaiono nell'elenco degli strumenti utilizzati
Se uno script è implementato tramite GTM, mettilo in pausa per un mese; se nessuno si lamenta, eliminalo definitivamente
Se uno script è hard-coded, chiedi allo sviluppatore di commentarlo temporaneamente, poi eliminalo dopo un mese

Container GTM prima dell'audit per tag abbandonati

Ritarda i tag non critici

Meno tag usano il trigger All Pages, più veloce è il caricamento iniziale. Non tutti i tag possono essere ritardati, ma se applichi questo approccio almeno ad alcuni di essi, il miglioramento sarà percepibile.

Come implementare il ritardo (metodo di Pavel Brechik):

Passo 1. Crea un tag HTML personalizzato con il codice:

1 <script>
2   (function() {
3    try {
4      window.setTimeout(
5       function(){
6        dataLayer.push({'event': 'afterLoad'});
7       }, 1500);
8     } catch (err) {}
9   })();
10 </script>

Passo 2. Attiva questo tag con il trigger Window Loaded.

Configurazione del trigger Window Loaded per tag HTML personalizzato

Passo 3. Crea un trigger personalizzato per l'evento afterLoad.

Creazione di un trigger afterLoad personalizzato in GTM

Passo 4. Assegna questo trigger ai tag che possono essere ritardati.

Risultato su 3G lento: ritardo ridotto di 6 secondi, su 3G veloce, di 600 millisecondi.

Fully Loaded in diversi momenti di attivazione dei tag

Quali tag possono essere ritardati e quali no va deciso con il team. Gli sviluppatori idealmente rimuoverebbero tutto per la velocità, i marketer aggiungerebbero tutto per l'accuratezza dei dati. La verità sta nel mezzo.

Usa i tag solo sulle pagine che ti servono

Non tutti i tag devono attivarsi sull'intero sito. Un pixel di remarketing Google Ads può partire solo sulle landing page di campagna, non su tutto il sito. LinkedIn Insights, solo sulle pagine dove arriva traffico da LinkedIn. Imposta esclusioni nei trigger, questo ridurrà il numero di script eseguiti su una pagina tipica.

Configurazione di un trigger solo per pagine specifiche in GTM

Evita manipolazioni pesanti del DOM

Se ti serve un tag HTML personalizzato che aggiunge qualcosa alla pagina, cerca di farlo nel modo più leggero possibile. Evita querySelectorAll con iterazione su tutti gli elementi. Non inserire decine di elementi identici in punti diversi della pagina. Ogni manipolazione del DOM consuma risorse del browser in un momento in cui è già impegnato a renderizzare la pagina.

Esempio di tag HTML personalizzato ottimizzato in GTM

Non misurare la velocità con la modalità anteprima attiva

La modalità Anteprima e Debug di GTM aggiunge un carico extra sul browser che i visitatori reali non hanno. Se misuri la velocità con l'anteprima attiva, i risultati saranno peggiori della realtà. Prima di un audit di velocità, disattiva sempre la modalità debug.

Disattivazione della modalità anteprima GTM per test di velocità

Testa la velocità dopo ogni modifica al container

Hai aggiunto un nuovo tag o modificato un trigger, verifica subito la velocità della pagina con webpagetest.org o Lighthouse. Fai misurazioni prima e dopo. Questo ti permetterà di individuare subito un tag problematico, invece di chiederti dopo perché il sito ha iniziato a caricarsi 2 secondi più lentamente.

Mantieni il container snello

Elimina tag, trigger e variabili inutilizzati. Non è tanto una questione di velocità (come ha mostrato il test con 1976 variabili), ma di gestibilità. In un container con un centinaio di tag, è facile perdere di vista uno script problematico. In un container con due dozzine, ogni elemento è visibile.

Separa il grano dal loglio: cosa fa davvero risparmiare tempo di caricamento

Tiriamo le somme degli esperimenti. Ecco cosa dà il massimo effetto in ordine decrescente:

Tabella riepilogativa dell'impatto di diversi fattori sulla velocità di caricamento

Secondo le nostre misurazioni, il miglioramento più significativo viene dal ritardare i tag tramite afterLoad, fino a 6 secondi su connessioni lente. Al secondo posto, la rimozione dei codici di tracciamento abbandonati. Al terzo posto, la limitazione dell'ambito dei tag a pagine specifiche.

⁉️🤔 Domande frequenti

Un GTM vuoto rallenta un sito?

Praticamente no. Nei nostri test, un container vuoto ha aggiunto circa 100 millisecondi al caricamento della pagina. A volte non c'è stato alcun ritardo. È un margine di errore, impercettibile sia per gli utenti che per i motori di ricerca.

Cosa rallenta di più: GTM o gli script hard-coded?

Gli script hard-coded rallentano un po' di più. Nel nostro test, 8 tag di tracciamento aggiunti direttamente al codice hanno rallentato la pagina di circa 600 millisecondi in più rispetto agli stessi tag via GTM. Ma non è una regola universale, un JS personalizzato ben scritto può essere più efficiente di GTM.

Si possono ritardare tutti i tag?

Tecnicamente sì. Ma perderai dati: alcuni visitatori lasceranno la pagina prima che i contatori si attivino. Google Analytics e strumenti simili sottostimeranno il traffico. Ritarda solo i tag che non richiedono alta precisione, ad esempio i widget di chat o i pixel di remarketing. È meglio lasciare l'analytics su Page View.

Come si verificano quali tag in GTM stanno davvero rallentando il sito?

Esegui un audit Lighthouse con la scheda Network aperta. Guarda quali script si caricano più a lungo e quali bloccano il rendering. Abbina i domini di questi script ai tag nel container. Oppure esegui un test A/B: disattiva temporaneamente i tag sospetti uno per uno e misura la velocità.

Cosa dire del GTM lato server?

Il GTM lato server sposta l'elaborazione dei tag dal browser dell'utente al tuo server. Il browser riceve un solo container invece di una dozzina di script di terze parti. Questo riduce radicalmente il carico lato client. Se hai decine di tag di tracciamento, vale la pena considerare il GTM lato server. La tecnologia è disponibile dal 2020, e entro il 2026 la sua implementazione è diventata notevolmente più semplice.

In conclusione: GTM accelera o rallenta?

Né nella forma pura. GTM è uno smistatore: di per sé è quasi senza peso, e la velocità della pagina è determinata da quali tag e in che quantità lanci attraverso di esso.

Otto tag di tracciamento standard attraverso GTM aggiungono 3-10 secondi al caricamento della pagina. Ma gli stessi tag inseriti direttamente nel codice rallentano ancora di più. Il lancio ritardato tramite afterLoad recupera fino a 6 secondi. Rimuovendo i tag abbandonati, qualche altro secondo. In totale, con una configurazione intelligente GTM può superare gli script inseriti direttamente, e senza configurazione, perdere del tutto contro una pagina vuota.

La regola principale è semplice: non è GTM a fare il sito, ma tu stesso. Fai l'audit del container, rimuovi la spazzatura, ritarda i tag non critici, imposta le esclusioni di pagina, e la velocità del tuo sito ti ringrazierà.

1	<script>
2	(function() {
3	try {
4	window.setTimeout(function(){
5	dataLayer.push({
6	'event': 'afterLoad'
7	});
8	}, 1500);
9	} catch (err) {}
10	})();
11	</script>

1	<script>
2	(function() {
3	var h3 = document.createElement('h3');
4	h3.innerText = "An additional element";
5	var title = document.querySelector('h2');
6	if (title) {
7	title.parentElement.insertBefore(h3, title.nextSibling);
8	}
9	})();
10	</script>

Tutto per WordPress, lo sviluppo web — e non solo

🚀 Google Tag Manager e velocità del sito: cosa dicono i test