Best practice per tag e gestori tag

Ottimizza tag e tag manager per Core Web Vitals.

I tag sono snippet di codice di terze parti che vengono inseriti in un sito, in genere tramite un gestore di tag. I tag sono più comunemente utilizzati per il marketing e l'analisi.

L'impatto sulle prestazioni dei tag e dei gestori di tag varia notevolmente da un sito all'altro. I tag manager possono essere paragonati a una busta: il gestore di tag è un contenitore, ma sei tu a decidere cosa inserire e come utilizzarlo.

Questo articolo illustra le tecniche per ottimizzare tag e tag manager per il rendimento e i Segnali web. Sebbene questo articolo faccia riferimento a Google Tag Manager, molte delle idee discusse sono applicabili anche ad altri gestori di tag.

Impatto sui Segnali web essenziali

Tag Manager spesso può influire indirettamente sui Segnali web essenziali consumando le risorse necessarie per caricare rapidamente la pagina e mantenerla reattiva. La larghezza di banda può essere utilizzata per scaricare il codice JavaScript di Tag Manager per i tuoi siti o per le chiamate successive effettuate. Il tempo di CPU nel thread principale può essere speso per valutare ed eseguire il codice JavaScript contenuto in Tag Manager e nei tag.

La metrica Largest Contentful Paint (LCP) è vulnerabile al conflitto di larghezza di banda durante il tempo di caricamento critico della pagina. Inoltre, il blocco del thread principale può ritardare il tempo di rendering LCP.

La metrica Cumulative Layout Shift (CLS) può essere interessata dal ritardo nel caricamento delle risorse fondamentali prima del primo rendering o dall'inserimento dei contenuti nella pagina da parte dei gestori di tag.

Il First Input Delay (FID) è suscettibile alla contesa della CPU nel thread principale. Ciò può influire anche sulla più recente metrica Interaction to Next Paint (INP) e abbiamo notato una correlazione tra le dimensioni dei tag manager e i punteggi INP più bassi.

Tipi di tag

L'impatto dei tag sul rendimento varia a seconda del tipo di tag. In linea di massima, i tag immagine ("pixel") sono i più efficaci, seguiti dai modelli personalizzati e infine dai tag HTML personalizzati. I tag del fornitore variano a seconda della funzionalità consentita.

Tuttavia, tieni presente che l'utilizzo di un tag influisce notevolmente sulle sue prestazioni. I "pixel" hanno prestazioni elevate in gran parte perché la natura di questo tipo di tag impone rigide restrizioni sul loro utilizzo; i tag HTML personalizzati non sono necessariamente un danno per le prestazioni ma, dato il livello di libertà che offrono agli utenti, possono essere facilmente utilizzati in modo improprio in modo negativo per le prestazioni.

Quando pensi ai tag, tieni presente la scalabilità: l'impatto sul rendimento di ogni singolo tag può essere trascurabile, ma può diventare significativo quando decine o centinaia di tag vengono utilizzati nella stessa pagina.

Non tutti gli script devono essere caricati utilizzando un gestore di tag

In genere, i tag manager non sono un buon meccanismo per caricare risorse che implementano aspetti visivi o funzionali immediati dell'esperienza utente, ad esempio notifiche relative ai cookie, immagini hero o funzionalità del sito. L'utilizzo di un gestore di tag per caricare queste risorse in genere ne ritarda la pubblicazione. Questo peggiora l'esperienza utente e può anche aumentare metriche come LCP e CLS. Inoltre, tieni presente che alcuni utenti bloccano i gestori di tag. L'utilizzo di un gestore di tag per implementare le funzionalità UX potrebbe comportare un malfunzionamento del sito web di alcuni utenti.

Fai attenzione ai tag HTML personalizzati

I tag HTML personalizzati esistono da molti anni e sono molto utilizzati nella maggior parte dei siti. I tag HTML personalizzati ti consentono di inserire il tuo codice con poche restrizioni poiché, nonostante il nome, questo tag viene utilizzato principalmente per aggiungere elementi <script> personalizzati a una pagina.

I tag HTML personalizzati possono essere utilizzati in svariati modi e il loro impatto sul rendimento varia in modo significativo. Quando misuri le prestazioni del tuo sito, tieni presente che la maggior parte degli strumenti attribuirà l'impatto sulle prestazioni di un tag HTML personalizzato al gestore di tag che lo ha inserito, anziché al tag stesso.

I tag HTML personalizzati possono inserire un elemento nella pagina circostante. L'inserimento di elementi nella pagina può essere fonte di problemi di prestazioni e, in alcuni casi, anche causare variazioni del layout.

• Nella maggior parte dei casi, se un elemento viene inserito nella pagina, il browser deve ricalcolare le dimensioni e la posizione di ciascun elemento. Questo processo è noto come layout. L'impatto sulle prestazioni di un singolo layout è minimo, ma quando si verifica in modo eccessivo può diventare causa di problemi di prestazioni. L'impatto di questo fenomeno è maggiore sui dispositivi di fascia bassa e sulle pagine con un numero elevato di elementi DOM.
• Se un elemento di pagina visibile viene inserito nel DOM dopo che è stato già eseguito il rendering dell'area circostante, potrebbe causare una variazione del layout. Questo fenomeno non è esclusivo per i gestori di tag. Tuttavia, poiché i tag vengono generalmente caricati più tardi di altre parti della pagina, di solito vengono inseriti nel DOM dopo il rendering della pagina circostante.

Valuta la possibilità di utilizzare modelli personalizzati

I modelli personalizzati supportano alcune delle stesse operazioni dei tag HTML personalizzati, ma sono basati su una versione di JavaScript con sandbox che fornisce API per i casi d'uso comuni, come script injection e pixel injection. Come suggerisce il nome, consentono di creare un modello da parte di un utente esperto, che può farlo tenendo presente le prestazioni. Gli utenti meno tecnici potranno quindi utilizzare il modello. Questo è spesso più sicuro rispetto a fornire accesso HTML personalizzato completo.

A causa delle maggiori restrizioni imposte ai modelli personalizzati, è molto meno probabile che questi tag presentino problemi di prestazioni o sicurezza. Tuttavia, per gli stessi motivi, i modelli personalizzati non funzionano per tutti i casi d'uso.

Inserisci correttamente gli script

L'utilizzo di un gestore di tag per inserire uno script è un caso d'uso molto comune. A questo scopo, ti consigliamo di utilizzare un modello personalizzato e l'API injectScript.

Per informazioni sull'utilizzo dell'API injectScript per convertire un tag HTML personalizzato esistente, consulta Convertire un tag esistente.

Se devi utilizzare un tag HTML personalizzato, tieni presente quanto segue:

• Le librerie e gli script di terze parti di grandi dimensioni devono essere caricati tramite un tag script che scarichi un file esterno (ad esempio <script src="external-scripts.js">), anziché copiare e incollare direttamente i contenuti dello script nel tag. Sebbene l'eliminazione del tag <script> elimini un round trip separato per scaricare i contenuti dello script, questa pratica aumenta le dimensioni del container ed evita che lo script venga memorizzato separatamente nella cache dal browser.
• Molti fornitori consigliano di posizionare il tag <script> nella parte superiore del <head>. Tuttavia, per gli script caricati tramite Tag Manager, questo consiglio di solito non è necessario: nella maggior parte dei casi, il browser ha già terminato l'analisi di <head> nel momento in cui viene eseguito il gestore di tag.

Utilizzare i pixel

In alcuni casi, gli script di terze parti possono essere sostituiti con "pixel" di immagini o iframe. Rispetto alle controparti basate su script, i pixel potrebbero supportare meno funzionalità e per questo motivo vengono spesso considerati un'implementazione meno preferita. Tuttavia, se utilizzati all'interno di tag manager, i pixel possono essere più dinamici poiché possono attivarsi sugli attivatori e trasmettere variabili diverse. Sono il tipo di tag più sicuro e con le prestazioni più elevate in quanto non c'è alcuna esecuzione di JavaScript dopo l'attivazione. I pixel hanno risorse di dimensioni molto ridotte (meno di 1 kB) e non causano variazioni del layout.

Rivolgiti al tuo provider di terze parti per ulteriori informazioni sul suo supporto per i pixel. Inoltre, puoi provare a controllare il codice per verificare la presenza di un tag <noscript>. Se un fornitore supporta i pixel, spesso li include nel tag <noscript>.

Alternative ai pixel

I pixel sono diventati popolari in gran parte perché un tempo erano uno dei modi più economici e affidabili per effettuare una richiesta HTTP in situazioni in cui la risposta del server non è pertinente ( ad esempio, durante l'invio di dati a provider di analisi). Le API navigator.sendBeacon() e fetch() keepalive sono progettate per questo stesso caso d'uso, ma probabilmente più affidabili dei pixel.

Non c'è niente di sbagliato nel continuare a utilizzare i pixel: sono ben supportati e hanno un impatto minimo sulle prestazioni. Se, invece, crei i tuoi beacon, è consigliabile utilizzare una di queste API.

sendBeacon()

L'API navigator.sendBeacon() è progettata per inviare piccole quantità di dati ai server web in situazioni in cui la risposta del server non è importante.

const url = "https://example.com/analytics";
const data = JSON.stringify({
    event: "checkout",
    time: performance.now()
});

navigator.sendBeacon(url, data);

sendBeacon() ha un'API limitata: supporta solo l'esecuzione di richieste POST e non l'impostazione di intestazioni personalizzate. È supportato da tutti i browser moderni.

fetch() keepalive

keepalive è un flag che consente di utilizzare l'API Fetch per effettuare richieste non bloccate come l'analisi e la generazione di report sugli eventi. Viene utilizzato includendo keepalive: true nei parametri trasmessi a fetch().

const url = "https://example.com/analytics";
const data = JSON.stringify({
  event: "checkout",
  time: performance.now()
});

fetch(url, {
    method: 'POST',
    body: data,
    keepalive: true
});

Se fetch() keepalive e sendBeacon() sembrano molto simili, è perché lo sono. Infatti, nei browser Chromium, ora sendBeacon() si basa su fetch() keepalive.

Quando scegli tra fetch() keepalive e sendBeacon(), è importante considerare le funzionalità e l'assistenza del browser di cui hai bisogno. L'API fetch() è notevolmente più flessibile, ma keepalive ha meno supporto del browser rispetto a sendBeacon().

Ottieni chiarimenti

I tag vengono spesso creati seguendo le indicazioni fornite da un fornitore di terze parti. Se non è chiaro la funzione del codice di un fornitore, considera di chiedere a qualcuno che lo sa. Ottenere un secondo parere può essere utile per capire se un tag ha il potenziale per creare problemi di prestazioni o di sicurezza.

È consigliabile inoltre assegnare ai tag un'etichetta con un proprietario in Tag Manager. È fin troppo facile dimenticare chi è il proprietario di un tag e avere paura di rimuoverlo per sicurezza.

Trigger

A livello generale, l'ottimizzazione degli attivatori di tag consiste in genere nell'assicurarsi di non attivare i tag più del necessario e nella scelta di un attivatore che bilancia le esigenze aziendali con i costi legati al rendimento.

Gli attivatori sono codice JavaScript che aumenta le dimensioni e i costi di esecuzione di Tag Manager. Sebbene la maggior parte degli attivatori siano di piccole dimensioni, l'effetto cumulativo può essere sommato. Ad esempio, avere molti eventi di clic o attivatori di timer possono aumentare notevolmente il carico di lavoro di Tag Manager.

Scegli un evento di trigger appropriato

L'impatto sulle prestazioni di un tag non è fisso: in generale, prima che un tag si attivi, maggiore è il suo impatto sulle prestazioni. In genere le risorse sono limitate durante il caricamento iniziale della pagina, pertanto il caricamento o l'esecuzione di una determinata risorsa (o tag) sottrae risorse ad altre risorse.

Sebbene sia importante scegliere attivatori appropriati per tutti i tag, è particolarmente importante per i tag che caricano risorse di grandi dimensioni o eseguono script lunghi.

I tag possono essere attivati sulle visualizzazioni di pagina (in genere Page load, il giorno DOM Ready, in data Window Loaded) o in base a un evento personalizzato. Per evitare di influire sul caricamento della pagina, ti consigliamo di attivare tag non essenziali dopo il giorno Window Loaded.

Utilizzare eventi personalizzati

Gli eventi personalizzati ti consentono di attivare gli attivatori in risposta agli eventi di pagina non coperti dagli attivatori integrati di Google Tag Manager. Ad esempio, molti tag utilizzano attivatori di visualizzazione di pagina; tuttavia, il periodo di tempo tra il giorno DOM Ready e il giorno Window Loaded può essere lungo su molte pagine e questo può complicare l'ottimizzazione dell'attivazione di un tag. Gli eventi personalizzati possono risolvere questo problema.

Per utilizzare gli eventi personalizzati, devi prima creare un attivatore di evento personalizzato e aggiornare i tag per utilizzare questo attivatore.

Per attivare l'attivatore, esegui il push dell'evento corrispondente al livello dati.

// Custom event trigger that fires after 2 seconds
setTimeout(() => {
  dataLayer.push({
    'event' : 'my-custom-event'
  });
}, 2000);

Utilizza condizioni di attivazione specifiche

L'utilizzo di condizioni di attivazione specifiche consente di evitare l'attivazione non necessaria di un tag. Anche se esistono molti modi per applicare questo concetto, una delle cose più semplici ma più utili che puoi fare è assicurarti che un tag venga attivato solo nelle pagine in cui è effettivamente utilizzato.

Le variabili integrate possono anche essere incorporate nelle condizioni di attivazione per limitare l'attivazione dei tag.

Tuttavia, tieni presente che la presenza di condizioni di attivazione o eccezioni complesse richiede tempo di elaborazione autonomo, quindi non renderle troppo complesse.

Carica Tag Manager al momento giusto

La modifica del caricamento dello stesso Tag Manager può avere un impatto significativo sulle prestazioni. Indipendentemente dalla loro configurazione, gli attivatori non possono attivarsi finché non viene caricato un gestore di tag. Sebbene sia importante scegliere attivatori efficaci per i singoli tag (come spiegato in precedenza), sperimentare con il caricamento di Tag Manager spesso può avere un impatto uguale o maggiore, dato che questa singola decisione influirà su tutti i tag di una pagina.

Il caricamento successivo di Tag Manager aggiunge anche un livello di controllo ed evita futuri problemi di rendimento, impedendo a un utente di Tag Manager di caricare inavvertitamente un tag troppo presto, senza rendersi conto dell'impatto che potrebbe avere.

Variabili

Le variabili consentono di leggere i dati dalla pagina. Sono utili negli attivatori e nei tag stessi.

Come gli attivatori, le variabili comportano l'aggiunta di codice JavaScript a Tag Manager e, di conseguenza, possono causare problemi di rendimento. Le variabili possono essere tipi integrati relativamente semplici in grado di leggere, ad esempio, parti dell'URL, cookie, livello dati o DOM. Oppure possono essere codice JavaScript personalizzato praticamente illimitato.

Mantieni le variabili semplici e al minimo, poiché dovranno essere valutate continuamente da Tag Manager. Rimuovi le vecchie variabili che non vengono più utilizzate per ridurre sia le dimensioni dello script di Tag Manager sia il tempo di elaborazione utilizzato.

Gestione tag

L'utilizzo efficiente dei tag ridurrà il rischio di problemi di rendimento.

Utilizzare il livello dati

Il livello dati contiene tutte le informazioni da trasmettere a Google Tag Manager. Più concretamente, si tratta di un array JavaScript di oggetti che contengono informazioni sulla pagina. Può essere utilizzato anche per attivare i tag.

// Contents of the data layer
window.dataLayer = [{
    'pageCategory': 'signup',
    'visitorType': 'high-value'
  }];

// Pushing a variable to the data layer
window.dataLayer.push({'variable_name': 'variable_value'});

// Pushing an event to the data layer
window.dataLayer.push({'event': 'event_name'});

Sebbene Google Tag Manager possa essere utilizzato senza il livello dati, è vivamente consigliato. Il livello dati consente di consolidare i dati a cui gli script di terze parti accedono in un'unica posizione, fornendo così una migliore visibilità sul loro utilizzo. Tra le altre cose, possono contribuire a ridurre i calcoli delle variabili ridondanti e l'esecuzione degli script. L'utilizzo di un livello dati controlla anche i dati a cui i tag accedono, anziché concedere l'accesso completo alla variabile JavaScript o al DOM.

Rimuovi i tag duplicati e inutilizzati

Possono verificarsi tag duplicati quando un tag viene incluso nel markup HTML di una pagina oltre a essere inserito tramite un gestore di tag.

I tag inutilizzati devono essere messi in pausa o rimossi, anziché bloccati, mediante l'utilizzo di un'eccezione attivatore. La messa in pausa o la rimozione di un tag rimuove il codice dal container, al contrario del blocco.

Quando i tag inutilizzati vengono rimossi, è necessario esaminare anche gli attivatori e le variabili per verificare che possano essere rimossi se sono stati utilizzati solo da quei tag.

Utilizzare liste consentite e bloccate

Gli elenchi di elementi consentiti e non consentiti ti consentono di configurare restrizioni altamente granulari relative a tag, attivatori e variabili consentiti in una pagina. Questa può essere usata per applicare best practice per le prestazioni e altri criteri.

Le liste consentite e non consentite vengono configurate tramite il livello dati.

window.dataLayer = [{
  'gtm.allowlist': ['<id>', '<id>', ...],
  'gtm.blocklist': ['customScripts']
}];

Ad esempio, è possibile non consentire tag HTML personalizzati, variabili JavaScript o accesso diretto a DOM. Ciò significa che possono essere utilizzati solo pixel e tag predefiniti, con i dati del livello dati. Sebbene sia certamente restrittivo, può comportare un'implementazione di Tag Manager più sicura e dal rendimento migliore.

Valuta l'utilizzo del tagging lato server

Il passaggio al tagging lato server non è un'attività banale, ma vale la pena tenerla presente, in particolare per i siti più grandi che vogliono un maggiore controllo sui propri dati. Il tagging lato server rimuove il codice del fornitore dal client e, con questo, trasferisce l'elaborazione dal client al server.

Ad esempio, quando si utilizza il tagging lato client, l'invio di dati a più account Analytics comporta l'avvio da parte del client di richieste separate per ciascun endpoint. Al contrario, con il tagging lato server, il client invia una singola richiesta al contenitore lato server e da lì i dati vengono inoltrati a diversi account Analytics.

Tieni presente che il tagging lato server funziona solo con alcuni tag; la compatibilità dei tag varia in base al fornitore.

Per ulteriori informazioni, consulta Introduzione al tagging lato server.

Container

I gestori di tag in genere consentono più istanze o "container" all'interno della loro configurazione. Ciò consente di controllare più contenitori all'interno di un singolo account gestore dei tag.

Utilizza un solo contenitore per pagina

L'utilizzo di più containers in una singola pagina può creare problemi di prestazioni significativi, poiché introduce un overhead aggiuntivo ed esecuzione di script. Come minimo, duplica il codice del tag principale che, poiché viene inviato come parte del codice JavaScript del container, non può essere riutilizzato tra i container.

È raro che più container vengano utilizzati in modo efficace. Tuttavia, ci possono essere casi in cui questo può funzionare, se controllato bene, tra cui:

• Avere un container "caricamento anticipato" più leggero e un container "caricamento successivo" più pesante, anziché un container di grandi dimensioni.
• Avere un container con restrizioni utilizzato da utenti meno tecnici, con un container meno limitato, ma più strettamente controllato, per i tag che non possono essere utilizzati nel container con limitazioni.

Se devi utilizzare più contenitori per pagina, segui le linee guida di Google Tag Manager per la configurazione di più contenitori.

Se necessario, utilizza container separati

Se utilizzi uno strumento di gestione dei tag per più proprietà (ad esempio, un'app web e un'app mobile), il numero di contenitori utilizzati può essere utile o meno produttivo del tuo flusso di lavoro. Inoltre, può influire sulle prestazioni.

In linea di massima, un singolo container può essere utilizzato in modo efficace su più siti se i siti hanno un utilizzo e una struttura simili. Ad esempio, sebbene le app web e per dispositivi mobili di un brand possano svolgere funzioni simili, è probabile che siano strutturate in modo diverso e, di conseguenza, gestite in modo più efficace tramite container separati.

Il tentativo di riutilizzare un singolo container in modo troppo ampio, di solito, aumenta inutilmente la complessità e le dimensioni del container costringendo l'adozione di logiche complesse per gestire tag e attivatori.

Tieni d'occhio le dimensioni del contenitore

Le dimensioni di un contenitore sono determinate da tag, attivatori e variabili. Sebbene un container di piccole dimensioni possa comunque influire negativamente sulle prestazioni delle pagine, quasi certamente un container di grandi dimensioni lo farà.

Le dimensioni del container non devono essere la metrica più importante per ottimizzare l'utilizzo dei tag; tuttavia, una dimensione del container di grandi dimensioni è spesso un segnale di avviso che un container non è ben gestito e potenzialmente viene utilizzato in modo improprio.

Google Tag Manager limita le dimensioni del contenitore a 200 kB e segnala in caso di dimensioni del contenitore a partire da 140 kB. Tuttavia, la maggior parte dei siti dovrebbe avere lo scopo di mantenere i container molto più piccoli. Per prospettiva, il container mediano del sito è di circa 50 kB.

Per determinare le dimensioni del container, osserva quella della risposta restituita da https://www.googletagmanager.com/gtag/js?id=YOUR_ID. Questa risposta contiene la libreria di Google Tag Manager e i contenuti del contenitore. La libreria di Google Tag Manager è di circa 33 kB compressa.

Assegna un nome alle versioni del contenitore

Una versione del container è uno snapshot dei contenuti di un container in un determinato momento. L'utilizzo di un nome significativo e l'inclusione di una breve descrizione dei cambiamenti significativi possono contribuire notevolmente a semplificare il debug di problemi di rendimento futuri.

Flussi di lavoro di codifica

La gestione delle modifiche apportate ai tag è importante per garantire che non abbiano un impatto negativo sulle prestazioni della pagina.

Verifica i tag prima del deployment

Testare i tag prima del deployment può aiutarti a individuare i problemi (prestazioni e altro) prima che vengano spediti.

Gli aspetti da considerare per il test di un tag includono:

• Il tag funziona correttamente?
• Il tag causa variazioni del layout?
• Il tag carica risorse? Quanto sono grandi queste risorse?
• Il tag attiva uno script di lunga durata?

Modalità di anteprima

La modalità di anteprima ti consente di testare le modifiche ai tag sul sito effettivo senza dover prima implementarle pubblicamente. La modalità di anteprima include una console di debug che fornisce informazioni sui tag.

Il tempo di esecuzione di Google Tag Manager sarà diverso (leggermente più lento) nell'esecuzione in modalità di anteprima a causa dell'overhead aggiuntivo necessario per esporre le informazioni nella console di debug. Pertanto, non è consigliabile confrontare le misurazioni di Segnali web raccolte in modalità di anteprima con quelle raccolte in produzione. Tuttavia, questa discrepanza non dovrebbe influire sul comportamento di esecuzione dei tag stessi.

Test autonomo

Un approccio alternativo per testare i tag consiste nel impostare una pagina vuota contenente un contenitore con un singolo tag, il tag che stai verificando. Questa configurazione di test è meno realistica e non rileva alcuni problemi (ad esempio se un tag causa variazioni del layout), tuttavia può semplificare l'isolamento e la misurazione dell'impatto del tag su aspetti come l'esecuzione dello script. Scopri come Telegraph utilizza questo approccio basato sull'isolamento per migliorare le prestazioni del codice di terze parti.

Monitorare il rendimento dei tag

L'API Monitoring di Google Tag Manager può essere utilizzata per raccogliere informazioni sul tempo di esecuzione di un determinato tag. Queste informazioni vengono segnalate a un endpoint della scelta.

Per saperne di più, consulta Come creare un monitoraggio di Google Tag Manager.

Richiedi l'approvazione per le modifiche al contenitore

In genere, il codice proprietario viene sottoposto a revisione e test prima del deployment; il trattamento dei tag è uguale. A questo scopo, puoi aggiungere la verifica in due passaggi, che richiede l'approvazione dell'amministratore per le modifiche al contenitore. In alternativa, se non vuoi richiedere la verifica in due passaggi ma vuoi comunque tenere d'occhio le modifiche, puoi configurare le notifiche dei container per ricevere avvisi via email sugli eventi dei container di tua scelta.

Controllare periodicamente l'utilizzo dei tag

Una delle sfide dell'utilizzo dei tag è che tendono ad accumularsi nel tempo: vengono aggiunti, ma raramente vengono rimossi. Un modo per invertire questa tendenza è controllare periodicamente i tag. La frequenza ideale di questa operazione dipende dalla frequenza con cui i tag del sito vengono aggiornati.

Assegnare un'etichetta a ogni tag in modo che il proprietario sia evidente, consente di identificare più facilmente chi risponde a quel tag e di indicare se è ancora necessario.

Quando controlli i tag, non dimenticare di eliminare anche attivatori e variabili. Possono essere anche la causa di problemi di prestazioni.

Per ulteriori informazioni, consulta la sezione Tenere sotto controllo gli script di terze parti.