24 de set de 2025
Escrito por
Ira Holubovska
A otimização da velocidade de carregamento das páginas do site foi um dos principais benefícios que os profissionais de marketing e programadores web identificaram quando foi lançada a primeira versão do Google Tag Manager do lado do servidor. Isto devia-se ao facto de os scripts de rastreio deixarem de estar embutidos no código, passando a ser adicionados através do Google Tag Manager.
Neste artigo, mostraremos como a transferência de etiquetas do contentor web do GTM para um contentor de servidor afeta o seu PageSpeed no GTM, como se traduzem os dados na prática e qual a abordagem que faz mais sentido consoante a sua configuração.
Nota:
Não verá melhorias no PageSpeed se executar o rastreio no navegador e no servidor em paralelo. Por exemplo, se utilizar o Pixel do Facebook e a Conversions API em simultâneo, o pixel continuará a carregar no navegador do utilizador e a abrandar o seu site. Este tipo de configuração parcial é uma das razões mais comuns pelas quais o GTM abranda um site, mesmo depois de as equipas acreditarem que já concluíram a migração.
Já em 2016, a Google estabeleceu que o tempo ideal de carregamento de um site é de 3 segundos. Ao mesmo tempo, em média, demora 22 segundos a carregar totalmente uma página em dispositivos móveis.
Vivemos numa época em que as pessoas utilizam mais os telemóveis do que os computadores de secretária, e os smartphones representam mais de 50% de todo o tráfego da Internet. No entanto, de acordo com a Google, as taxas de conversão nos telemóveis são inferiores às dos computadores. É por isso que a velocidade de carregamento do site desempenha um papel essencial no cumprimento dos padrões de desempenho.
Não é segredo que os utilizadores esperam uma experiência rápida no site. Se a página de destino for demasiado lenta, fecharão a página ou abandonarão o carrinho e irão para o site da concorrência. Hoje em dia, num mundo centrado nos dispositivos móveis (mobile-first), criar sites de carregamento rápido é fundamental. Os utilizadores querem poder abrir rapidamente qualquer blogue para ler artigos, comprar roupa, consultar avaliações de hotéis e muito mais.
De acordo com uma pesquisa da Amazon, um atraso de 1 segundo na resposta da página resulta numa perda de 1% nas conversões. Para a empresa, isso equivale a uma perda de 1,6 mil milhões de dólares em receitas anuais.
Como se pode constatar, esperar que páginas pesadas carreguem pode custar muito a qualquer empresa.
Cada etiqueta que adiciona através do Google Tag Manager é executada como JavaScript no navegador do utilizador. Cada script precisa de ser descarregado, analisado e executado antes ou depois do carregamento da página, o que consome tempo.
Nem todas as configurações do GTM funcionam da mesma forma, e é daqui que surge a maior parte da confusão. A forma como o contentor é implementado — web ou no servidor — determina se o GTM sobrecarrega o navegador ou alivia essa carga. No contentor web, cada etiqueta adicionada (analítica, píxeis de anúncios, widgets de chat, mapas de calor) é um script que é carregado e executado diretamente no navegador do visitante.
Cada um compete pelos mesmos recursos limitados: o thread principal, a largura de banda e o tempo de renderização. Quanto mais etiquetas acumular, maior será o impacto cumulativo no desempenho do Google Tag Manager, mesmo sendo o GTM, por si só, um contentor leve.
O GTM do lado do servidor altera o local onde ocorre a execução das etiquetas. Em vez de dezenas de scripts de terceiros a serem executados do lado do cliente, o seu contentor de servidor recebe os dados e reencaminha-os para as suas plataformas de marketing e analítica a partir da nuvem. O navegador só precisa de comunicar com o seu próprio servidor, e não com uma dezena de domínios de terceiros diferentes. Esta é a razão principal pela qual a diferença de PageSpeed no Google Tag Manager entre configurações web e no servidor costuma ser tão acentuada.
Em 2020, a Google lançou um contentor de servidor para o Google Tag Manager e Tag Manager 360. Este permite aos anunciantes mover etiquetas de terceiros dos seus sites para um novo contentor de servidor alojado em servidores na nuvem. Desta forma, o site pode carregar mais depressa, o rastreio pode ser mais preciso e os dados ficam mais seguros. Mover etiquetas para o contentor de servidor pode ajudar a resolver este erro do Google PageSpeed: "Reduce the impact of third-party code — Third-party code blocked the main thread for 550 ms".

Se mover as etiquetas da web para o contentor de servidor, as etiquetas serão carregadas diretamente no contentor de servidor e não nos navegadores. Desta forma, a página carregará mais depressa, gerando um impacto positivo na experiência do utilizador. Como pode verificar, isto permite obter tempos de carregamento de página mais rápidos, maior segurança para os dados dos seus clientes e mais ferramentas de gestão de dados. Este é um dos exemplos mais claros de como o Google Tag Manager do lado do servidor pode melhorar o desempenho do site sem comprometer a precisão do rastreio.
As etiquetas no contentor de servidor só têm acesso às informações enviadas para o servidor. Não conseguem aceder a outros dados que os utilizadores introduzam no site. E, uma vez que estas etiquetas estão alojadas no seu contentor de servidor, pode saber exatamente que etiquetas de dados estão a recolher informações e para onde essas informações são enviadas.
Nem todas as etiquetas afetam o PageSpeed da mesma forma, e esta é uma nuance importante a reter antes de presumir que uma migração resolverá todos os problemas de desempenho. Um snippet analítico leve e um pixel pesado de retargeting publicitário não têm o mesmo custo no tempo de carregamento, ainda que ambos sejam "apenas uma etiqueta". As etiquetas com maior impacto tendem a ser aquelas que acionam múltiplos pedidos de rede, carregam scripts adicionais ou são executadas em cada carregamento de página em vez de em eventos específicos.
A forma mais fiável de comprovar isto por si é verificar o relatório do Google Tag Manager no PageSpeed Insights antes e após uma migração, comparando diretamente a secção de código de terceiros nos resultados.
Para esta experiência, utilizei um site de demonstração e comparei os resultados do Google PageSpeed quando as etiquetas eram adicionadas através do contentor web do GTM vs. o contentor de servidor do GTM. Nem todas as etiquetas têm o mesmo impacto no Google PageSpeed. Ao realizar esta experiência, decidi escolher as etiquetas mais populares utilizadas pelo meu cliente e que podem ser transferidas para o contentor de servidor: Facebook, Bing e Active Campaign.
O contentor de servidor do GTM inclui etiquetas nativas para o GA4. Aqui pode encontrar informações detalhadas sobre como configurar o rastreio do GA4 utilizando o contentor do GTM do lado do servidor. Criámos também um modelo personalizado para ajudar a migrar o pixel do Facebook para o ambiente de servidor.
Abaixo estão os resultados do Google Speed Test. O Google PageSpeed apresentou 95 pontos em dispositivos móveis e 100 em computadores.

Temos estas tags instaladas no contentor de servidor: GA4, Facebook (rastreio base e de conversões), Hubspot e a tag da Klaviyo.
Quando movemos o pixel para o contentor web, os resultados do Google PageSpeed diminuíram para 56 pontos.


Se mover as etiquetas para o contentor de servidor do Google Tag Manager, aumentará a velocidade do seu site. O nível de impacto dependerá das etiquetas que estiver a utilizar. Neste teste, as etiquetas mais populares entre os clientes (GA4, Facebook e Active Campaign ) mostraram uma diferença clara e mensurável assim que foram migradas para o lado do servidor.
Quer começar no lado do servidor?
Experimentar gratuitamente24 de set de 2025
Blog
Descubra como enviar variáveis do dataLayer, parâmetros personalizados ou outros dados da web para o contêiner do servidor com Data Tag.
21 de out de 2025
Comentários