⚡ GTM e velocidade de página: testes, conclusões e 8 formas de acelerar o seu site

Os profissionais de marketing repetem frequentemente: «O Google Tag Manager acelera os websites, as páginas com GTM carregam mais depressa.» Os developers costumam argumentar: «O GTM só atrasa as coisas.» A verdade, como sempre, está entre estes extremos.

Realizámos uma série de testes com diferentes configurações do GTM: um contentor vazio, um contentor com 8 códigos de tracking, tags inseridas diretamente no código, diferentes momentos de disparo dos acionadores, dezenas de tags HTML personalizadas com manipulações do DOM. Medimos a velocidade através do webpagetest.org e do Lighthouse. Os resultados revelaram-se menos lineares do que aquilo que as apresentações do GTM afirmam.

Eis o que descobrimos: o contentor do GTM em si quase não atrasa nada, mas aquilo que se coloca lá dentro pode adicionar 3 ou 10 segundos ao carregamento da página. E o ponto fundamental é que é possível controlar isto.

💡 Resumo rápido:

Um contentor GTM vazio adiciona cerca de 100 milissegundos ao carregamento da página
Oito tags de tracking através do GTM atrasam a página em 3 segundos em 3G rápido e até 10 segundos em ligações lentas
As mesmas 8 tags inseridas diretamente no código do site atrasam ainda mais
Quanto mais tarde as tags disparam, menor é o impacto: um atraso de 1,5 segundos após o Window Loaded reduz o tempo de carregamento em 6 segundos em 3G lento
Uma configuração de acionadores bem planeada e a limpeza do contentor restauram a velocidade sem perda de dados

Como testámos

A metodologia é simples, mas minuciosa. Executámos cada teste pelo menos três vezes e calculámos a média.

Ferramentas: webpagetest.org (servidor na Irlanda, EC2, Chrome e Firefox para desktop, OnePlus 5 para testes móveis) e a auditoria integrada do Lighthouse nas Chrome DevTools. No Lighthouse, analisámos os relatórios para dispositivos móveis e desktop. O Chrome foi iniciado em modo de navegação anónima, sem extensões, com o desempenho do portátil no máximo.

Métricas que medimos:

No webpagetest.org: Document complete (segundos até o conteúdo estático, imagens e estilos estarem carregados) e Fully loaded (o ponto após o onLoad em que a atividade de rede estabiliza durante 2 segundos). No Lighthouse: First Meaningful Paint, Time to Interactive, First CPU Idle e Max Potential First Input Delay (FID).

Códigos de tracking nos testes: Google Analytics (gtag.js), Facebook Pixel, Reddit Pixel, Quora Pixel, LinkedIn Insights, Twitter Universal Tag, Google Ads Remarketing (gtag.js), Hotjar. Oito scripts amplamente utilizados.

Cenários que comparámos:

Página limpa, sem scripts de terceiros e sem GTM
Página com 8 códigos de tracking inseridos diretamente antes de </head>, sem GTM
Contentor GTM vazio, sem tags
Todas as 8 tags através do GTM, acionador All Pages (também conhecido como gtm.js)
As mesmas 8 tags através do GTM, acionador DOM Ready (gtm.dom)
As mesmas 8 tags através do GTM, acionador Window Loaded (gtm.load)
As mesmas 8 tags, a disparar 1,5 segundos após o Window Loaded
Contentor GTM com o modo de pré-visualização e depuração ativado
Contentor GTM com 100 tags HTML personalizadas a adicionar elementos ao final do <body>
Contentor GTM com 100 tags HTML personalizadas a adicionar elementos num local específico da página (após o H2)
Contentor GTM com 100 tags HTML personalizadas a procurar todos os links e a inserir um elemento após o 21.º
Contentor GTM com 1976 variáveis constantes (preenchido até ao limite, 200 KB)

O que os testes mostraram

Assíncrono não significa «sem consequências»

Os scripts assíncronos não bloqueiam a renderização diretamente. Mas continuam a precisar de recursos da CPU, o que significa que os scripts principais do site são executados mais lentamente. Na prática: o evento Document Complete numa página limpa ocorreu após 4 segundos. Com oito tags, após 7,7 segundos. Uma diferença de 3,7 segundos apenas porque o processador está ocupado com scripts de terceiros.

Comparação do tempo de Document Complete sem tags e com tags

Mesmo um contentor GTM vazio aumentou ligeiramente o tempo de carregamento, em cerca de 100 milissegundos.

Impacto de um contentor GTM vazio no tempo de carregamento

Não se trata do GTM, mas do que se coloca lá dentro

Um contentor GTM vazio adiciona cerca de 100 milissegundos ao carregamento da página, por vezes não há atraso nenhum. Os problemas começam quando se enche o contentor com tags. Mas mesmo aqui, as coisas não são lineares.

Oito tags de tracking atrasaram a página em cerca de 3 segundos numa ligação 3G rápida e em 10 segundos em ligações lentas. Cada tag carrega o seu próprio script e o browser gasta tempo a executá-los.

Document Complete sem tags e com 8 tags no GTM

Mas um contentor preenchido com 1976 variáveis constantes (200 KB, o limite do GTM) adicionou apenas 0,1 a 0,3 segundos. As variáveis não carregam scripts externos nem manipulam o DOM, pelo que o seu impacto é mínimo.

Conclusão: o que importa não é o tamanho do contentor, mas as ações que os seus elementos executam.

Tags inseridas diretamente no código atrasam mais do que as mesmas tags através do GTM

Quando adicionámos 8 scripts de tracking diretamente no código do site, a página ficou ainda mais lenta de forma notória. Em 3G rápido, as tags inseridas diretamente no código adicionaram cerca de 600 milissegundos de atraso adicional em comparação com as mesmas tags lançadas através do GTM.

Comparação entre tags hard-coded e tags via GTM

No segundo gráfico, a mesma imagem de um ângulo diferente: os scripts inseridos diretamente no código perdem consistentemente para o GTM no tempo de Document Complete.

Document Complete com tags hard-coded versus GTM

O GTM ajuda realmente as páginas a carregar ligeiramente mais depressa do que quando os scripts são adicionados diretamente ao código. Mas isto não é uma regra universal. Há cenários em que o lançamento de JS sem GTM pode ser implementado de forma mais eficiente, e o Simo Ahava, um dos principais especialistas em GTM, concorda com isto.

O momento do disparo das tags é importante

Quanto mais tarde uma tag dispara, menos afeta o carregamento inicial da página. Testámos quatro momentos:

Page View (gtm.js), imediatamente quando o contentor carrega
DOM Ready (gtm.dom), quando o DOM é construído
Window Loaded (gtm.load), quando todos os recursos são carregados
afterLoad, 1,5 segundos após o Window Loaded (acionador personalizado)

Código do acionador personalizado 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>

Resultado: DOM Ready e Window Loaded proporcionaram uma pequena melhoria. Mas o ganho mais significativo veio do afterLoad. Em 3G lento, o atraso foi reduzido em 6 segundos em comparação com o acionador Page View. Em 3G rápido, em 600 milissegundos.

Comparação do Fully Loaded em diferentes momentos de disparo das tags

Porque é que isto funciona? A página pode ter elementos que carregam dinamicamente apenas depois de todos os recursos estarem totalmente carregados. Se as tags atrasarem o carregamento inicial, estes elementos também aparecem mais tarde. Ao adiar tags não críticas, permite que o conteúdo principal carregue sem interferências.

Mas há uma ressalva: se adiar tags das quais a precisão depende (Google Analytics), alguns visitantes podem sair da página antes de o contador ser acionado. Os seus relatórios perderão alguns dados. A decisão de adiar tags deve ser tomada com a equipa, e não unilateralmente por um developer ou marketeer.

As tags de tracking não são as únicas culpadas

Outro grupo de tags «pesadas» são as que manipulam o DOM. Por exemplo, tags HTML personalizadas que adicionam ou alteram elementos na página.

Testámos várias variações:

100 tags HTML personalizadas a adicionar elementos ao final do <body>. Cada tag executava um script simples de console.log('hello') e criava um <div>Hello!</div>. Sem especificar um local de inserção específico. O impacto na velocidade de carregamento da página revelou-se mínimo, os elementos eram simplesmente anexados ao final.

100 tags HTML personalizadas a adicionar elementos num local específico da página. Cada tag procurava o primeiro h2 e inseria um h3 depois dele. 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>

Isto adicionou várias centenas de milissegundos ao carregamento da página. Embora o script seja primitivo, procurar um elemento e inseri-lo requer recursos.

Impacto de 100 tags com manipulações de DOM no Fully Loaded

100 tags HTML personalizadas que procuram todos os links na página e inserem um elemento depois do 21.º. 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>

Diferença em relação à experiência anterior: querySelectorAll itera por todos os elementos na página, verifica cada um, o que é mais dispendioso. No webpagetest.org a diferença foi pequena (100-200 ms), mas o Lighthouse mostrou um aumento de 2-3 segundos no Time to Interactive. Isto significa que durante o carregamento da página, o browser está tão ocupado a inserir elementos que não responde às ações do utilizador.

Time to Interactive com manipulações pesadas de DOM

Sim, 100 scripts idênticos é um exagero. Mas a questão é que mesmo algumas tags complexas que manipulam o DOM podem produzir um efeito semelhante.

Como reduzir o impacto do GTM na velocidade: 8 técnicas

Limpe regularmente o contentor de tags abandonadas

A experiência das auditorias mostra: até um terço dos códigos de rastreamento nos sites pertencem a ferramentas que a empresa já não utiliza. Mudou da ferramenta de análise X para a Z, mas os códigos da X continuam a carregar em cada página e a torná-la mais lenta.

O que fazer:

Peça a um programador para fornecer uma lista de todos os pedidos HTTP e scripts na página
Pesquise no Google os domínios desses pedidos, identifique a que ferramentas pertencem
Pergunte a colegas de diferentes departamentos quais as ferramentas que ainda são usadas
Encontre scripts «órfãos» que não estão na lista de ferramentas utilizadas
Se um script estiver implementado através do GTM, faça uma pausa de um mês; se ninguém se queixar, elimine-o completamente
Se um script estiver codificado diretamente, peça ao programador para o comentar temporariamente e depois eliminá-lo após um mês

Contentor GTM antes da auditoria para tags abandonadas

Adie tags não críticas

Quanto menos tags no acionador All Pages, mais rápido é o carregamento inicial. Nem todas as tags podem ser adiadas, mas se aplicar esta abordagem a pelo menos algumas delas, a melhoria será notória.

Como implementar o adiamento (método de Pavel Brechik):

Passo 1. Crie uma tag HTML personalizada com o código:

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. Lance esta tag no acionador Window Loaded.

Configurar o acionador Window Loaded para uma tag HTML personalizada

Passo 3. Crie um acionador personalizado para o evento afterLoad.

Criar um acionador afterLoad personalizado no GTM

Passo 4. Atribua este acionador às tags que podem ser adiadas.

Resultado em 3G lento: atraso reduzido em 6 segundos, em 3G rápido, em 600 milissegundos.

Fully Loaded em diferentes momentos de disparo das tags

Quais as tags que podem ser adiadas e quais as que não podem deve ser decidido com a equipa. Idealmente, os programadores removeriam tudo em prol da velocidade, os marketeers adicionariam tudo pela precisão dos dados. A verdade está no meio.

Use tags apenas nas páginas necessárias

Nem todas as tags precisam de ser disparadas em todo o site. Um pixel de remarketing do Google Ads pode ser lançado apenas nas páginas de destino da campanha, e não em todo o site. O LinkedIn Insights, apenas nas páginas onde chega tráfego do LinkedIn. Configure exclusões nos acionadores, isto reduzirá o número de scripts executados numa página típica.

Configurar um acionador apenas para páginas específicas no GTM

Evite manipulações pesadas do DOM

Se precisar de uma tag HTML personalizada que adicione algo à página, tente fazê-lo da forma mais leve possível. Evite querySelectorAll com iteração por todos os elementos. Não insira dezenas de elementos idênticos em locais diferentes da página. Cada manipulação do DOM consome recursos do navegador num momento em que este já está ocupado a renderizar a página.

Exemplo de tag HTML personalizada otimizada no GTM

Não meça a velocidade com o modo de pré-visualização ativado

O modo de Pré-visualização e Depuração no GTM adiciona uma carga extra ao navegador que os visitantes reais não têm. Se medir a velocidade com a pré-visualização ativada, os resultados serão piores do que a realidade. Antes de uma auditoria de velocidade, desligue sempre o modo de depuração.

Desativar o modo de pré-visualização do GTM para testes de velocidade

Teste a velocidade após cada alteração no contentor

Adicionou uma nova tag ou alterou um acionador, verifique imediatamente a velocidade da página através do webpagetest.org ou do Lighthouse. Faça medições antes e depois. Isto permitir-lhe-á detetar uma tag problemática de imediato, em vez de se perguntar mais tarde porque é que o site começou a carregar 2 segundos mais lento.

Mantenha o contentor enxuto

Elimine tags, acionadores e variáveis não utilizados. Isto não é tanto pela velocidade (como o teste com 1976 variáveis mostrou), mas pela facilidade de gestão. Num contentor com uma centena de tags, é fácil perder um script problemático. Num contentor com duas dúzias, cada unidade é visível.

Separar o trigo do joio: o que realmente poupa tempo de carregamento

Vamos tirar as conclusões das experiências. Eis o que dá o máximo efeito por ordem decrescente:

Tabela-resumo do impacto de diferentes fatores na velocidade de carregamento

De acordo com as nossas medições, a melhoria mais significativa vem do adiamento de tags através do afterLoad, até 6 segundos em ligações lentas. Em segundo lugar, a remoção de códigos de rastreamento abandonados. Em terceiro lugar, limitar o âmbito das tags a páginas específicas.

⁉️🤔 Perguntas frequentes

Um GTM vazio torna o site mais lento?

Praticamente não. Nos nossos testes, um contentor vazio adicionou cerca de 100 milissegundos ao carregamento da página. Por vezes, não houve atraso algum. Isto é margem de erro, impercetível tanto para os utilizadores como para os motores de busca.

O que torna as coisas mais lentas: o GTM ou os scripts codificados diretamente?

Os scripts codificados diretamente tornam as coisas um pouco mais lentas. No nosso teste, 8 tags de rastreamento adicionadas diretamente ao código atrasaram a página cerca de 600 milissegundos mais do que as mesmas tags através do GTM. Mas isto não é uma regra universal, JS personalizado bem escrito pode ser mais eficiente do que o GTM.

Pode adiar todas as tags?

Tecnicamente, sim. Mas perderá dados: alguns visitantes sairão da página antes de os contadores serem disparados. O Google Analytics e ferramentas semelhantes subcontarão o tráfego. Adie apenas tags que não exijam alta precisão, por exemplo, widgets de chat ou pixels de remarketing. É melhor deixar a análise em Page View.

Como verificar quais as tags no GTM que estão realmente a tornar as coisas mais lentas?

Execute uma auditoria Lighthouse com o separador Rede aberto. Veja quais os scripts que demoram mais a carregar e quais bloqueiam a renderização. Faça corresponder os domínios desses scripts com as tags no contentor. Ou faça um teste A/B: desative temporariamente as tags suspeitas, uma a uma, e meça a velocidade.

E quanto ao GTM do lado do servidor?

O GTM do lado do servidor transfere o processamento das tags do navegador do utilizador para o seu servidor. O navegador recebe apenas um contentor em vez de uma dúzia de scripts de terceiros. Isto reduz radicalmente a carga no lado do cliente. Se tem dezenas de tags de rastreamento, vale a pena considerar o GTM do lado do servidor. A tecnologia está disponível desde 2020 e, em 2026, a sua implementação tornou-se notoriamente mais simples.

Conclusão: o GTM acelera ou torna mais lento?

Nem na forma pura. O GTM é um despachante: por si só é quase sem peso, e a velocidade da página é determinada pelas tags que lança através dele e em que quantidade.

Oito tags de rastreio padrão através do GTM acrescentam 3 a 10 segundos ao carregamento da página. Mas as mesmas tags em hard-code tornam tudo ainda mais lento. O lançamento diferido através de afterLoad recupera até 6 segundos. Remover tags abandonadas, mais alguns segundos. No total, com uma configuração inteligente, o GTM pode superar os scripts em hard-code e, sem configuração, perder completamente para uma página vazia.

A regra principal é simples: não é o GTM que faz o site, é você. Faça uma auditoria ao contentor, remova o lixo, adie as tags não críticas, defina exclusões de página e a velocidade do seu site agradecer-lhe-á.

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>

Tudo para WordPress, desenvolvimento web — e não só

🚀 Google Tag Manager e velocidade do site: o que dizem os testes