Publicado em: 29 de julho de 2021
As tags são snippets de código de terceiros inseridos em um site, geralmente com um Tag Manager. As tags são usadas com frequência para marketing e análise.
O impacto das tags e dos gerenciadores de tags na performance varia muito entre os sites. Os gerenciadores de tags podem ser comparados a um envelope: eles fornecem um recipiente, mas o que você coloca nele e como o usa depende principalmente de você.
Aqui, discutimos técnicas para otimizar tags e gerenciadores de tags para desempenho e Core Web Vitals. Embora este documento faça referência ao Google Tag Manager, muitas das ideias discutidas são aplicáveis a outros gerenciadores de tags.
Impacto nas Core Web Vitals
Os gerenciadores de tags geralmente podem afetar as Core Web Vitals de forma indireta, consumindo recursos necessários para carregar a página rapidamente e mantê-la responsiva. A largura de banda pode ser gasta no download do JavaScript do Gerenciador de tags para seus sites ou nas chamadas subsequentes que ele faz. O tempo de CPU na linha de execução principal pode ser gasto avaliando e executando o JavaScript contido no Tag Manager e nas tags.
A Largest Contentful Paint (LCP) é vulnerável à contenção de largura de banda durante o tempo crítico de carregamento da página. Além disso, o bloqueio da linha de execução principal pode atrasar o tempo de renderização da LCP.
A Cumulative Layout Shift (CLS) pode ser afetada pelo atraso no carregamento de recursos críticos antes da primeira renderização ou por Tag Managers que injetam conteúdo na página.
A Interaction to Next Paint (INP) é suscetível à contenção de CPU na linha de execução principal, e observamos uma correlação entre o tamanho dos gerenciadores de tags e pontuações de INP mais baixas.
Escolher o tipo de tag certo
O impacto das tags na performance varia de acordo com o tipo de tag. De modo geral, as tags de imagem ("pixels") são as que têm melhor desempenho, seguidas pelos modelos personalizados e, por último, pelas tags HTML personalizadas. As tags de fornecedor variam de acordo com a funcionalidade que permitem.
Lembre-se de que a forma como você usa uma tag influencia muito o impacto dela na performance. Os pixels têm um desempenho excelente, em grande parte porque a natureza desse tipo de tag impõe restrições rígidas sobre como eles podem ser usados. As tags HTML personalizadas nem sempre são ruins para o desempenho, mas, devido ao nível de liberdade que oferecem aos usuários, podem ser facilmente usadas de maneira prejudicial ao desempenho.
Ao pensar em tags, considere a escala: o impacto de uma única tag na performance pode ser insignificante, mas pode se tornar significativo quando dezenas ou centenas de tags são usadas na mesma página.
Nem todos os scripts devem ser carregados com um Tag Manager
Os gerenciadores de tags geralmente não são a melhor maneira de carregar recursos que implementam aspectos visuais ou funcionais imediatos da experiência do usuário, como avisos de cookies, imagens principais ou recursos do site. O uso de um gerenciador de tags para carregar esses recursos geralmente atrasa a entrega deles. Isso é ruim para a experiência do usuário e também pode aumentar métricas como LCP e CLS.
Além disso, alguns usuários bloqueiam os Tag Managers. Usar um gerenciador de tags para implementar recursos de UX pode resultar em um site corrompido para alguns usuários.
Tenha cuidado com as tags HTML personalizadas
As tags HTML personalizadas existem há muitos anos e são muito usadas na maioria dos sites. As tags HTML personalizadas permitem que você insira seu próprio código com poucas restrições, já que, apesar do nome, o principal uso dessa tag é adicionar elementos <script> personalizados a uma página.
As tags HTML personalizadas podem ser usadas de várias maneiras, e o impacto delas na performance varia significativamente. Ao medir a performance do seu site, lembre-se de que a maioria das ferramentas atribui o impacto de uma tag HTML personalizada ao gerenciador de tags que a injetou, e não à tag em si.
As tags HTML personalizadas podem inserir um elemento na página em que estão. O ato de inserir elementos na página pode ser uma fonte de problemas de desempenho e, em alguns casos, também causar mudanças de layout.
- Na maioria das situações, se um elemento é inserido na página, o navegador precisa recalcular o tamanho e a posição de cada item na página. Esse processo é conhecido como layout. O impacto de um único layout no desempenho é mínimo, mas, quando ocorre em excesso, pode se tornar uma fonte de problemas de desempenho. O impacto desse fenômeno é maior em dispositivos mais simples e páginas com um grande número de elementos DOM.
- Se um elemento de página visível for inserido no DOM depois que a área ao redor já tiver sido renderizada, isso poderá causar uma mudança de layout. Esse fenômeno não é exclusivo dos gerenciadores de tags. No entanto, como as tags normalmente são carregadas depois de outras partes da página, é comum que elas sejam inseridas no DOM depois que a página ao redor já foi renderizada.
Usar modelos personalizados
Os modelos personalizados são compatíveis com algumas das mesmas operações que as tags HTML personalizadas, mas são criados com base em uma versão em sandbox do JavaScript que oferece APIs para casos de uso comuns, como injeção de script e de pixel. Como o nome indica, eles permitem que um modelo seja criado por um usuário avançado que pode criá-lo com o desempenho em mente. Os usuários menos técnicos podem usar o modelo. Isso costuma ser mais seguro do que fornecer acesso total ao HTML personalizado.
Devido às restrições maiores impostas aos modelos personalizados, essas tags têm muito menos probabilidade de apresentar problemas de desempenho ou segurança. Pelos mesmos motivos, os modelos personalizados não funcionam para todos os casos de uso.
Injetar scripts corretamente
Usar um gerenciador de tags para injetar um script é um caso de uso muito comum. A
maneira recomendada de fazer isso é usar um modelo personalizado e a
API
injectScript.
Para saber como usar a API injectScript para converter uma tag HTML personalizada, consulte Converter uma tag.
Se você precisar usar uma tag HTML personalizada, lembre-se:
- As bibliotecas e os scripts grandes de terceiros precisam ser carregados com uma tag script
(por exemplo,
<script src="external-scripts.js">) que faz o download de um arquivo externo, em vez de copiar e colar diretamente o conteúdo do script na tag. Embora a não utilização da tag<script>elimine uma ida e volta separada para fazer o download do conteúdo do script, essa prática aumenta o tamanho do contêiner e impede que o script seja armazenado em cache separadamente pelo navegador. - Muitos fornecedores recomendam colocar a tag
<script>na parte de cima do<head>. No entanto, para scripts carregados com o Gerenciador de tags, isso geralmente é desnecessário. Na maioria das situações, o navegador já terminou de analisar o<head>quando o Tag Manager é executado.
Usar pixels
Às vezes, os scripts de terceiros podem ser substituídos por pixels de imagem ou iframe. Em comparação com os scripts, os pixels podem oferecer menos funcionalidades, por isso costumam ser vistos como uma implementação menos preferida. No entanto, quando usados em gerenciadores de tags, os pixels podem ser mais dinâmicos, já que podem ser disparados em acionadores e transmitir variáveis diferentes.
Os pixels são o tipo de tag mais eficiente e seguro porque não há execução de JavaScript após o acionamento. Os pixels têm um tamanho de recurso muito pequeno (menos de 1 KB) e não causam mudanças de layout.
Consulte seu provedor terceirizado para saber mais sobre o suporte a pixels. Além disso, você pode tentar inspecionar o código deles para encontrar uma tag <noscript>.
Se um fornecedor for compatível com pixels, ele geralmente vai incluir o pixel na tag <noscript>.
Alternativas aos pixels
Os pixels se tornaram populares principalmente porque, em uma época, eram uma das maneiras mais baratas
e confiáveis de fazer uma solicitação HTTP em situações em que a resposta do servidor
não é relevante ( por exemplo, ao enviar dados para provedores de
análise). As APIs
navigator.sendBeacon()
e fetch() keepalive
foram projetadas para atender a esse mesmo caso de uso, mas são indiscutivelmente mais confiáveis
do que os pixels.
Não há problema em continuar usando pixels, já que eles são bem aceitos e têm um impacto mínimo no desempenho. No entanto, se você estiver criando seus próprios beacons, vale a pena considerar o uso de uma dessas APIs.
sendBeacon()
A API
navigator.sendBeacon()
foi projetada para enviar pequenas quantidades de dados a servidores da Web em situações
em que a resposta do servidor não importa.
const url = "https://example.com/analytics";
const data = JSON.stringify({
event: "checkout",
time: performance.now()
});
navigator.sendBeacon(url, data);
sendBeacon() tem uma API limitada: ela só aceita solicitações POST e não
permite definir cabeçalhos personalizados. Ele é
compatível com todos os navegadores modernos.
API Fetch keepalive
keepalive
é uma flag que permite que a API
Fetch seja
usada para fazer solicitações não bloqueantes, como relatórios de eventos e análises. Ele é
usado incluindo keepalive: true nos parâmetros transmitidos para 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() parecem muito semelhantes, é porque eles
são. Na verdade, nos navegadores Chromium, sendBeacon() agora é baseado em fetch()
keepalive.
Ao escolher entre fetch() keepalive e sendBeacon(), é importante
considerar os recursos e o suporte do navegador de que você precisa. A API fetch() é
significativamente mais flexível. No entanto, o keepalive tem menos suporte
do navegador do que o sendBeacon().
Entender o que as tags fazem
As tags geralmente são criadas seguindo as orientações de um fornecedor terceirizado. Se não estiver claro o que o código de um fornecedor faz, pergunte a alguém que saiba. Uma segunda opinião pode ajudar a identificar se uma tag tem o potencial de criar problemas de desempenho ou segurança.
Recomendamos rotular as tags com um proprietário no Tag Manager. É fácil esquecer quem é o proprietário de uma tag, o que gera medo de removê-la caso ela quebre algo.
Gatilhos
Em geral, a otimização de acionadores de tags consiste em garantir que as tags não sejam acionadas mais do que o necessário e escolher um acionador que equilibre as necessidades comerciais com os custos de desempenho.
Os acionadores são códigos JavaScript que aumentam o tamanho e o custo de execução do Tag Manager. Embora a maioria dos gatilhos seja pequena, o efeito cumulativo pode se somar. Por exemplo, ter vários eventos de clique ou acionadores de timer pode aumentar drasticamente a carga de trabalho do Tag Manager.
Escolha um evento acionador adequado
O impacto de uma tag na performance pode variar. Em geral, quanto mais cedo uma tag é disparada, maior é o impacto dela na performance. Os recursos geralmente são limitados durante o carregamento inicial da página. Portanto, carregar ou executar um recurso (ou tag) específico consome recursos de outra coisa.
Embora seja importante escolher acionadores adequados para todas as tags, isso é especialmente importante para tags que carregam recursos grandes ou executam scripts longos.
As tags podem ser acionadas em
Visualizações de página
(normalmente Page load, em DOM Ready, em Window Loaded) ou com base em um
evento personalizado. Para evitar impactos no carregamento de página, acione tags não essenciais após
Window Loaded.
Usar eventos personalizados
Use eventos personalizados para disparar acionadores em resposta a eventos de página que não são cobertos pelos acionadores integrados do Google Tag Manager. Por exemplo, muitas tags usam acionadores de visualização de página. No entanto,
o tempo entre DOM Ready e Window Loaded pode ser longo, o que dificulta
o ajuste de quando uma tag é disparada. Os eventos personalizados podem ser uma solução para
esse problema.
Primeiro, crie um acionador de evento personalizado e atualize suas tags para usá-lo.
Para disparar o acionador, envie o evento correspondente à camada de dados.
// Custom event trigger that fires after 2 seconds
setTimeout(() => {
dataLayer.push({
'event' : 'my-custom-event'
});
}, 2000);
Usar condições de acionamento específicas
Defina condições de acionamento específicas para evitar o disparo de tags quando não for necessário. Uma das maneiras mais simples e eficazes de fazer isso é garantir que uma tag seja disparada apenas nas páginas em que ela é realmente usada.
As variáveis incorporadas podem ser incluídas nas condições do acionador para limitar o disparo de tags.
Carregar o Tag Manager no momento certo
Para melhorar a performance, ajuste o momento em que o próprio Gerenciador de tags é carregado. Os acionadores, independentemente de como são configurados, só podem ser disparados depois que um Tag Manager é carregado. Faça testes com o momento em que você carrega o Gerenciador de tags, já que isso pode ter um impacto igual ou maior. Essa decisão afeta todas as tags em uma página.
Ao carregar o Gerenciador de tags mais tarde, você evita problemas de desempenho futuros, já que isso impede o carregamento inadvertido de uma tag muito cedo.
Variáveis
Use variáveis para ler dados da página. Elas são úteis em acionadores e nas próprias tags.
Assim como os acionadores, as variáveis adicionam código JavaScript ao Gerenciador de tags e, portanto, podem causar problemas de desempenho. As variáveis podem ser relativamente pequenas, como códigos para ler partes do URL, cookies, camada de dados ou DOM. Eles também podem incluir JavaScript personalizado com capacidade (e tamanho) ilimitados.
Mantenha o uso de variáveis no mínimo, já que elas são avaliadas continuamente pelo Tag Manager. Remova as variáveis antigas que não são mais usadas para reduzir o tamanho do script do Tag Manager e o tempo de processamento que ele usa.
Gerenciamento de tags
O uso eficiente das tags reduz o risco de problemas de desempenho.
Usar a camada de dados
A camada de dados é uma matriz JavaScript de objetos que contêm informações sobre a página. Esses objetos contêm todas as informações que você quer transmitir ao Google Tag Manager.
A camada de dados também pode ser usada para acionar tags.
// 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'});
Embora o Google Tag Manager possa ser usado sem a camada de dados, é altamente recomendável usá-la. A camada de dados consolida os dados que podem ser acessados por scripts de terceiros em um único lugar, proporcionando melhor visibilidade do uso. Entre outras coisas, isso pode ajudar a reduzir cálculos de variáveis redundantes e a execução de scripts.
Ao usar uma camada de dados, você pode controlar quais dados são acessados pelas tags, em vez de conceder acesso total à variável JavaScript ou ao DOM.
Os benefícios de desempenho da camada de dados podem não ser intuitivos, já que a atualização da camada de dados faz com que o Google Tag Manager reavalie todas as variáveis do contêiner e, possivelmente, acione acionadores, o que envolve a execução de JavaScript. Embora seja possível usar a camada de dados de maneira incorreta, em geral, se ela parecer ser a origem dos problemas de desempenho, é provável que o próprio contêiner tenha problemas de desempenho. A camada de dados torna esses problemas mais evidentes.
Remover tags duplicadas e não usadas
As tags duplicadas podem ocorrer quando uma tag é incluída na marcação HTML de uma página, além de ser injetada por um gerenciador de tags.
As tags não utilizadas precisam ser pausadas ou removidas, em vez de bloqueadas com uma exceção de acionador. Pausar ou remover uma tag remove o código do contêiner, mas o bloqueio não.
Quando as tags não utilizadas forem removidas, revise os acionadores e as variáveis para determinar se eles também podem ser removidos.
As tags pausadas afetam o tamanho do contêiner, mas o payload total é menor do que quando as tags estão ativas.
Usar listas de permissão e negação
Use listas de permissão e de bloqueio para configurar restrições altamente granulares nas tags, nos acionadores e nas variáveis permitidos em uma página. Isso pode ser usado para ajudar a aplicar as práticas recomendadas de desempenho e outras políticas.
As listas de permissão e de bloqueio são configuradas pela camada de dados.
window.dataLayer = [{
'gtm.allowlist': ['<id>', '<id>', ...],
'gtm.blocklist': ['customScripts']
}];
Por exemplo, é possível impedir o uso de tags HTML personalizadas, variáveis JavaScript ou acesso direto ao DOM. Isso significa que apenas pixels e tags predefinidas podem ser usados, com dados da camada de dados. Embora isso seja restritivo, pode resultar em uma implementação mais eficiente e segura do Tag Manager.
Considere usar a inclusão de tags no servidor
Vale a pena considerar a mudança para a inclusão de tags no servidor, principalmente para sites maiores que querem mais controle sobre os dados. A inclusão de tags no servidor remove o código do fornecedor do cliente e, com isso, transfere o processamento do cliente para o servidor.
Por exemplo, ao usar a inclusão de tags do lado do cliente, o envio de dados para várias contas de análise implica que o cliente inicia solicitações separadas para cada endpoint. Com a inclusão de tags no servidor, o cliente faz uma única solicitação ao contêiner do servidor e, a partir daí, esses dados são encaminhados para diferentes contas do Google Analytics.
A inclusão de tags no servidor só funciona com algumas tags. A compatibilidade da tag varia de acordo com o fornecedor.
Para mais informações, consulte Introdução à inclusão de tags no servidor.
Contêineres
Os gerenciadores de tags normalmente permitem várias instâncias, geralmente chamadas de contêineres, na configuração. É possível controlar vários contêineres em uma conta do Gerenciador de tags.
Use apenas um contêiner por página
Vários contêineres em uma única página podem causar problemas significativos de desempenho, já que isso introduz mais sobrecarga e execução de scripts. No mínimo, ele duplica o próprio código da tag principal que, por ser entregue como parte do JavaScript do contêiner, não pode ser reutilizado entre os contêineres.
É raro que vários contêineres sejam usados de forma eficaz. No entanto, há casos em que isso pode funcionar, se bem controlado. Exemplo:
- Incluir um contêiner mais leve de "carregamento antecipado" e um mais pesado de "carregamento posterior", em vez de um único contêiner grande.
- Usar um contêiner restrito para usuários menos técnicos e um contêiner menos restrito, mas mais controlado, para tags mais complexas.
Se você precisar usar vários contêineres por página, siga as orientações do Gerenciador de tags do Google para configurar vários contêineres.
Usar contêineres separados, se necessário
Se você usa um gerenciador de tags para várias propriedades, como um app da Web e um app para dispositivos móveis, o número de contêineres usados pode ajudar ou prejudicar a produtividade do seu fluxo de trabalho. Isso também pode afetar o desempenho.
Um único contêiner pode ser usado em vários sites se eles forem semelhantes em uso e estrutura. Por exemplo, embora os apps para dispositivos móveis e web apps de uma marca possam ter funções semelhantes, é provável que eles sejam estruturados de maneira diferente e, portanto, gerenciados de forma mais eficaz por meio de contêineres separados.
Reutilizar um único contêiner de forma muito ampla pode aumentar a complexidade e o tamanho dele, forçando uma lógica complexa para gerenciar tags e acionadores.
Fique de olho no tamanho do contêiner
O tamanho de um contêiner é determinado pelas tags, acionadores e variáveis dele. Embora um contêiner pequeno ainda possa afetar negativamente o desempenho da página, um contêiner grande quase certamente o fará.
O tamanho do contêiner não deve ser a métrica mais importante ao otimizar o uso de tags. No entanto, um tamanho de contêiner grande geralmente é um sinal de alerta de que um contêiner não está bem mantido e possivelmente está sendo usado de forma incorreta.
O Google Tag Manager limita o tamanho do contêiner a 300 kB e avisa sobre o tamanho do contêiner depois que ele atinge 70% do limite.
A maioria dos sites deve manter os contêineres menores que o limite. Para comparação, o contêiner de site médio tem cerca de 50 KB. Por si só, a biblioteca do Google Tag Manager tem cerca de 33 kB compactados.
Nomear as versões do contêiner
Uma versão do contêiner é um snapshot do conteúdo de um contêiner em um momento específico. Usar um nome significativo e incluir uma breve descrição das mudanças significativas pode facilitar muito a depuração de problemas de desempenho no futuro.
Incluir tags em fluxos de trabalho
É importante gerenciar as mudanças nas tags para que elas não tenham um impacto negativo na performance da página.
Teste antes de implantar
Teste as tags antes da implantação para detectar problemas, de desempenho e outros, antes do envio.
Ao testar uma tag, considere o seguinte:
- A tag está funcionando corretamente?
- A tag causa mudanças de layout?
- A tag carrega algum recurso? Qual é o tamanho desses recursos?
- A tag aciona um script de longa duração?
Modo de visualização
O modo de visualização permite testar as mudanças de tags no seu site sem precisar implantá-las para o público primeiro. O modo de visualização inclui um console de depuração que fornece informações sobre as tags.
O tempo de execução do Google Tag Manager é diferente (um pouco mais lento) quando executado no modo de visualização devido à sobrecarga adicional necessária para expor informações no console de depuração. Portanto, não é recomendável comparar as medições dos Web Vitals coletadas no modo de visualização com as coletadas na produção. No entanto, essa discrepância não deve afetar o comportamento de execução das tags.
Teste independente
Uma abordagem alternativa para testar tags é configurar uma página vazia com um contêiner que tenha uma única tag, que é a que você está testando. Essa configuração de teste é menos realista e não detecta alguns problemas (por exemplo, se uma tag causa mudanças de layout), mas pode facilitar o isolamento e a medição do impacto da tag em itens como a execução de scripts. Confira como o Telegraph usa essa abordagem de isolamento para melhorar a performance do código de terceiros.
Monitorar a performance da tag
A API Monitoring do Gerenciador de tags do Google pode ser usada para coletar informações sobre o tempo de execução de uma tag específica. Essas informações são enviadas para um endpoint escolhido por você.
Para mais informações, consulte Como criar um monitor do Google Tag Manager.
Exigir aprovação para mudanças no contêiner
O código próprio normalmente passa por revisão e teste antes da implantação. Trate suas tags da mesma forma.
Uma maneira de fazer isso é adicionar a verificação em duas etapas, que exige a aprovação do administrador para mudanças no contêiner. Como alternativa, se você não quiser exigir a verificação em duas etapas, mas ainda quiser ficar de olho nas mudanças, configure as notificações de contêiner para receber alertas por e-mail sobre os eventos de contêiner que escolher.
Auditar periodicamente o uso de tags
Um dos desafios de trabalhar com tags é que elas tendem a se acumular ao longo do tempo: as tags são adicionadas, mas raramente são removidas. Auditar as tags periodicamente é uma maneira de reverter essa tendência. A frequência ideal para fazer isso depende da frequência com que as tags do site são atualizadas.
Rotular cada tag para que o proprietário seja óbvio permite identificar com mais facilidade quem é responsável por essa tag e pode dizer se ela ainda é necessária.
Ao auditar tags, lembre-se de limpar acionadores e variáveis. Muitas vezes, eles também podem ser a causa de problemas de desempenho.
Para mais informações, consulte Como manter scripts de terceiros sob controle.