Otimize tags e gerenciadores de tags para as Core Web Vitals.
Tags são snippets de código de terceiros inseridos em um site, geralmente por meio de um gerenciador de tags. As tags são usadas com mais frequência para marketing e análise.
O impacto no desempenho das tags e dos gerenciadores de tags varia muito de site para site. Os gerenciadores de tags podem ser comparados a um envelope: o gerenciador de tags oferece um espaço, mas o que você usa nele e como ele é usado depende de você.
Este artigo discute técnicas de otimização de tags e gerenciadores de tags para desempenho e Métricas da Web. Embora este artigo faça referência ao Gerenciador de tags do Google, muitas das ideias discutidas também se aplicam a outros gerenciadores.
Impacto nas Core Web Vitals
Muitas vezes, os Gerenciadores de tags podem afetar indiretamente suas Core Web Vitals usando os recursos necessários para carregar sua página rapidamente e mantê-la responsiva. É possível usar a largura de banda com o download do JavaScript do Gerenciador de tags dos seus sites ou com as 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 gerenciador de tags e nas tags.
A Maior exibição de conteúdo (LCP, na sigla em inglês) é vulnerável à contenção de largura de banda durante o tempo crítico de carregamento da página. Além disso, bloquear a linha de execução principal pode atrasar o tempo de renderização da LCP.
A mudança de layout cumulativa (CLS, na sigla em inglês) pode ser afetada pelo atraso no carregamento de recursos críticos antes da primeira renderização ou por gerenciadores de tags injetando conteúdo na página.
A latência na primeira entrada (FID, na sigla em inglês) é suscetível à contenção da CPU na linha de execução principal. Isso também pode afetar a métrica mais recente de Interação com a próxima exibição (INP, na sigla em inglês). Percebemos uma correlação entre o tamanho dos gerenciadores de tags e pontuações de INP mais baixas.
Tipos de tag
O impacto das tags no desempenho varia de acordo com o tipo de tag. De modo geral, as tags de imagem ("pixels") têm a melhor performance, seguidas pelos modelos personalizados e, por último, pelas tags HTML personalizadas. As tags do fornecedor variam de acordo com a funcionalidade que permitem.
No entanto, o uso de uma tag influencia muito o impacto no desempenho. Os "pixels" têm alto desempenho, principalmente porque a natureza desse tipo de tag impõe restrições rígidas sobre como elas podem ser usadas. As tags HTML personalizadas não são necessariamente sempre ruins para o desempenho, mas, devido ao nível de liberdade que oferecem aos usuários, podem ser fáceis de usar e prejudicar o desempenho.
Ao pensar em tags, tenha em mente a escala: o impacto no desempenho de uma única tag 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 usando um gerenciador de tags.
Os gerenciadores de tags normalmente não são um bom mecanismo para carregar recursos que implementam aspectos visuais ou funcionais imediatos da experiência do usuário, por exemplo, avisos de cookies, imagens principais ou recursos do site. Usar um gerenciador de tags para carregar esses recursos normalmente atrasa a entrega. Isso é ruim para a experiência do usuário e também pode aumentar as métricas como LCP e CLS. Lembre-se também de que alguns usuários bloqueiam gerenciadores de tags. Usar um gerenciador de tags para implementar recursos de UX pode resultar na cor do site para alguns usuários.
Cuidado com 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 uso principal 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 no desempenho varia significativamente. Ao medir a performance do seu site, lembre-se de que a maioria das ferramentas atribui o impacto no desempenho de uma tag HTML personalizada ao gerenciador de tags que a injetou, e não à própria tag.
As tags HTML personalizadas podem inserir um elemento na página ao redor. A inserção de elementos na página pode ser uma fonte de problemas de performance e, em alguns casos, também causa mudanças de layout.
- Na maioria das situações, se um elemento for inserido na página, o navegador precisará recalcular o tamanho e a posição de cada item na página. Esse processo é conhecido como layout. O impacto na performance de um único layout é mínimo, mas quando ocorre excessivamente, 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á tiver sido renderizada.
Considere usar modelos personalizados
Os modelos personalizados oferecem suporte a algumas das mesmas operações que as tags HTML personalizadas, mas são criados com base em uma versão do JavaScript em sandbox que fornece APIs para casos de uso comuns, como injeção de script e injeção de pixels. Como o nome indica, eles permitem que um usuário avançado crie um modelo pensando no desempenho. Os usuários com menos recursos técnicos podem usar o modelo. Geralmente, isso é mais seguro do que fornecer acesso total a HTML personalizado.
Devido às maiores restrições impostas aos modelos personalizados, essas tags têm muito menos chances de apresentar problemas de desempenho ou segurança. No entanto, por esses 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 atual.
Se você precisar usar uma tag HTML personalizada, lembre-se destes pontos:
- As bibliotecas e os scripts grandes de terceiros precisam ser carregados usando uma tag de script que faça o download de um arquivo externo (por exemplo,
<script src="external-scripts.js">), em vez de copiar e colar diretamente o conteúdo do script na tag. Embora abandonar o uso da tag<script>elimine um trajeto de ida e volta separado 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 pelo gerenciador de tags, essa recomendação geralmente é desnecessária: na maioria das situações, o navegador já terminou de analisar as<head>no momento da execução do gerenciador.
Usar pixels
Em algumas situações, scripts de terceiros podem ser substituídos por "pixels" de imagem ou iframe. Em comparação com os formatos baseados em script, os pixels podem aceitar menos funcionalidades e, 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 acionados em acionadores e transmitir variáveis diferentes. Elas são o tipo de tag com melhor desempenho e segurança porque não há execução de JavaScript depois que ela é disparada. 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 mais informações sobre o suporte a
pixels. Além disso, você pode tentar inspecionar o código em busca de uma tag <noscript>.
Se um fornecedor oferecer suporte a pixels, eles geralmente serão incluídos na
tag <noscript>.
Alternativas aos pixels
Os pixels se tornaram populares em grande parte porque, anteriormente, 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 lidar com esse mesmo caso de uso, mas são possivelmente mais confiáveis
do que pixels.
Não há nada de errado em continuar usando pixels. Eles têm um bom suporte e têm um impacto mínimo na performance. No entanto, se você estiver criando seus próprios beacons, considere o uso de uma dessas APIs.
sendBeacon()
A API
navigator.sendBeacon()
foi criada 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: oferece suporte apenas a solicitações POST, e não
à configuração de cabeçalhos personalizados. Ele tem
suporte de todos os navegadores mais recentes.
fetch() keepalive
keepalive
é uma sinalização que permite que a API
Fetch seja
usada para fazer solicitações sem bloqueio, como relatórios e análises de eventos. 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
são. Na verdade, nos navegadores Chromium, a sendBeacon() agora tem como base a fetch()
keepalive.
Ao escolher entre fetch() keepalive e sendBeacon(), é importante considerar os recursos e a compatibilidade com o navegador necessários. A API fetch() é significativamente mais flexível. No entanto, keepalive tem menos suporte ao navegador do que sendBeacon().
Esclarecimentos
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, considere perguntar a alguém que saiba. Uma segunda opinião pode ajudar a identificar se uma tag pode causar problemas de desempenho ou segurança.
Rotular tags com um proprietário no gerenciador de tags também é recomendado. É muito fácil esquecer quem é o proprietário de uma tag e ter medo de removê-la, por precaução.
Gatilhos
Em geral, otimizar os acionadores de tag geralmente consiste em não acionar tags mais do que o necessário e escolher um acionador que equilibre as necessidades da empresa com os custos de desempenho.
Os acionadores são códigos JavaScript que aumentam o tamanho e o custo de execução do Gerenciador de tags. Embora a maioria dos acionadores sejam pequenos, o efeito cumulativo pode aumentar. Ter muitos eventos de clique, por exemplo, ou acionadores de tempo pode aumentar drasticamente a carga de trabalho do Gerenciador de tags.
Escolher um evento acionador apropriado
O impacto no desempenho de uma tag não é fixo: em geral, quanto mais cedo uma tag for disparada, maior será o impacto dela no desempenho. Normalmente, os recursos são restritos durante o carregamento inicial da página. Portanto, o carregamento ou a execução de um recurso (ou tag) específico tira os recursos de outra coisa.
Embora seja importante escolher acionadores apropriados para todas as tags, isso é ainda mais importante para tags que carregam recursos grandes ou executam scripts longos.
As tags podem ser acionadas em visualizações de página (geralmente Page load, em DOM Ready, em Window Loaded) ou com base em um evento personalizado. Para evitar impacto no carregamento da página, é recomendável disparar tags não essenciais após Window Loaded.
Usar eventos personalizados
Os eventos personalizados permitem que você dispare acionadores em resposta a eventos da página que não são cobertos pelos acionadores integrados do Gerenciador de tags do Google. Por exemplo, muitas tags usam acionadores de visualização de página. No entanto, o período entre DOM Ready e Window Loaded pode ser longo em muitas páginas, e isso dificulta o ajuste quando uma tag é disparada. Os eventos personalizados são uma solução para esse problema.
Para utilizar eventos personalizados, primeiro crie um acionador de evento personalizado e atualize suas tags para utilizar esse acionador.
Para disparar o acionador, envie o evento correspondente para a 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
O uso de condições de acionador específicas ajuda a evitar disparar uma tag desnecessariamente. Embora existam muitas maneiras de aplicar esse conceito, uma das coisas mais simples e úteis é garantir que uma tag só seja disparada nas páginas em que é realmente usada.
As variáveis incorporadas também podem ser incorporadas às condições do acionador para limitar o disparo de tags.
No entanto, esteja ciente de que ter condições ou exceções de acionamento complexas leva o tempo de processamento por si só, por isso não os torne muito complexos.
Carregue seu Gerenciador de tags em um momento adequado.
Ajustar quando o Gerenciador de tags é carregado pode afetar significativamente a performance. Os acionadores, independentemente de como estão configurados, não podem ser disparados até que um gerenciador de tags seja carregado. Embora seja importante escolher bons acionadores para tags individuais (como explicado acima), testar o carregamento do gerenciador de tags geralmente pode ter um impacto igual ou maior, já que essa decisão única afetará todas as tags de uma página.
Carregar o Gerenciador de tags posteriormente também adiciona uma camada de controle e pode evitar problemas de desempenho futuros, já que impede que um usuário do Gerenciador de tags carregue acidentalmente uma tag muito cedo, sem perceber o impacto que isso pode ter.
Variáveis
Elas permitem que os dados sejam lidos na página. Elas são úteis em acionadores e nas próprias tags.
Assim como os acionadores, as variáveis resultam na adição do código JavaScript ao Gerenciador de tags, causando problemas de desempenho. As variáveis podem ser tipos integrados relativamente simples que podem, por exemplo, ler partes do URL, cookies, camada de dados ou DOM. Ou eles podem ser um JavaScript personalizado com capacidade ilimitada de execução.
Mantenha as variáveis simples e mínimas, já que elas precisarão ser avaliadas continuamente pelo Gerenciador de tags. Remova as variáveis antigas que não são mais usadas para reduzir o tamanho do script do Gerenciador de tags e o tempo de processamento que ele usa.
Gerenciador de tags
Usar as tags de forma eficiente reduzirá o risco de problemas de desempenho.
Usar a camada de dados
A camada de dados "contém todas as informações que você quer transmitir ao Gerenciador de tags do Google". Mais concretamente, é uma matriz JavaScript de objetos que contém informações sobre a página. Ele também pode ser usado 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 Gerenciador de tags do Google possa ser usado sem a camada de dados, ele é altamente recomendado. A camada de dados oferece uma maneira de consolidar os dados acessados por scripts de terceiros em um único local, proporcionando melhor visibilidade sobre o uso deles. Entre outras coisas, isso pode ajudar a reduzir os cálculos de variáveis redundantes e a execução de scripts. O uso de uma camada de dados também controla os dados acessados pelas tags, em vez de conceder acesso total à variável JavaScript ou ao DOM.
Remover tags duplicadas e não usadas
Tags duplicadas podem ocorrer quando uma tag é incluída na marcação HTML de uma página e injetada por um Gerenciador de tags.
As tags não usadas 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 usadas são removidas, os acionadores e as variáveis também precisam ser revisados para ver se algum deles pode ser removido se for usado apenas por essas tags.
Usar listas de permissão e negação
Com as listas de permissão e negação, você pode configurar restrições altamente granulares nas tags, nos acionadores e nas variáveis permitidas em uma página. Isso pode ser usado para ajudar a aplicar práticas recomendadas de desempenho e outras políticas.
As listas de permissão e negação são configuradas pela camada de dados.
window.dataLayer = [{
'gtm.allowlist': ['<id>', '<id>', ...],
'gtm.blocklist': ['customScripts']
}];
Por exemplo, é possível não permitir tags HTML personalizadas, variáveis JavaScript ou acesso direto ao DOM. Isso significa que apenas pixels e tags predefinidas podem ser usados com informações da camada de dados. Embora isso seja certamente restritivo, pode resultar em uma implementação do gerenciador de tags muito mais eficiente e segura.
Considere usar a inclusão de tags no servidor
Mudar para a inclusão de tags no servidor não é uma tarefa trivial, mas vale a pena considerar, 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 ela, descarrega 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 exige que o cliente inicie solicitações separadas para cada endpoint. Por outro lado, com a inclusão de tags no servidor, o cliente faz uma única solicitação ao contêiner do servidor, e esses dados são encaminhados para diferentes contas do Analytics.
A inclusão de tags no servidor só funciona com algumas tags. A compatibilidade delas 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 ou "contêineres" na configuração. Dessa forma, vários contêineres podem ser controlados em uma única conta de administrador de tags.
Use apenas um contêiner por página
O uso de vários containers em uma única página pode criar problemas significativos de desempenho, já que gera mais sobrecarga e execução de scripts. No mínimo, ela duplica o próprio código da tag principal que, por ser fornecido 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 maneira eficaz. No entanto, pode haver instâncias em que isso funciona (se bem controlado), incluindo:
- Ter um contêiner de "carregamento antecipado" mais leve e um de "carregamento posterior" mais pesado, em vez de um contêiner grande.
- Ter um contêiner restrito usado por usuários menos técnicos, com um contêiner menos restrito, mas mais rigorosamente controlado, para tags que não podem ser usadas no contêiner restrito.
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.
Use contêineres separados, se necessário
Se você utiliza um gerenciador de tags em várias propriedades (por exemplo, um app da Web e um para dispositivos móveis), o número de contêineres pode ajudar ou prejudicar a produtividade do seu fluxo de trabalho. Isso também pode afetar o desempenho.
De modo geral, um único contêiner pode ser usado de maneira eficiente em vários sites se eles forem semelhantes em uso e estrutura. Por exemplo, mesmo que os apps para dispositivos móveis e da Web de uma marca sirvam a funções semelhantes, é provável que eles sejam estruturados de maneira diferente e, portanto, gerenciados com mais eficiência por meio de contêineres separados.
Tentar reutilizar um único contêiner de maneira muito ampla normalmente aumenta desnecessariamente a complexidade e o tamanho dele, forçando a adoção de lógica complexa para gerenciar tags e acionadores.
Monitorar o tamanho do contêiner
O tamanho de um contêiner é determinado por suas tags, acionadores e variáveis. Um contêiner pequeno ainda pode afetar negativamente o desempenho da página, mas é quase certo que um contêiner grande sim.
O tamanho do contêiner não pode ser uma métrica principal ao otimizar o uso da tag. No entanto, um tamanho de contêiner grande geralmente é um sinal de que um contêiner não está sendo bem mantido e possivelmente usado de forma indevida.
O Gerenciador de tags do Google limita o tamanho do contêiner para 200 KB e vai avisar sobre um tamanho a partir de 140 KB. No entanto, a maioria dos sites precisa manter os contêineres muito menores do que isso. Em perspectiva, o contêiner médio do site tem cerca de 50 KB.
Para determinar o tamanho do contêiner, observe o tamanho da resposta
retornada por https://www.googletagmanager.com/gtag/js?id=YOUR_ID. Essa resposta contém a biblioteca do Gerenciador de tags do Google e o conteúdo do contêiner. A biblioteca do Gerenciador de tags do Google, sozinha, tem cerca de 33 KB compactada.
Nomear as versões do contêiner
Uma versão de contêiner é um resumo do conteúdo de um contêiner em um determinado momento. Usar um nome significativo e incluir uma breve descrição de mudanças significativas pode facilitar a depuração de problemas de desempenho futuras.
Fluxos de trabalho de inclusão de tag
Gerenciar as alterações feitas nas tags é importante para garantir que elas não tenham um impacto negativo no desempenho da página.
Teste as tags antes da implantação
Testar as tags antes da implantação pode ajudar a detectar problemas, como desempenho e outros, antes do envio.
Os itens a serem considerados ao testar uma tag incluem:
- 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
Com o modo de visualização, você pode testar alterações de tags no seu site real sem precisar implantá-las publicamente. O modo de visualização inclui um console de depuração que fornece informações sobre tags.
O tempo de execução do Gerenciador de tags do Google será diferente (um pouco mais lento) no modo de visualização. Isso acontece devido à sobrecarga adicional necessária para expor informações no console de depuração. Portanto, não é recomendável comparar as medidas das Métricas da Web coletadas no modo de visualização com aquelas coletadas na produção. No entanto, essa discrepância não afeta o comportamento de execução das próprias tags.
Testes autônomos
Uma abordagem alternativa para o teste de tags é configurar uma página vazia com um contêiner com uma única tag, ou seja, 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), embora possa facilitar o isolamento e a medição do impacto da tag em coisas como a execução do script. Confira como o Telegraph usa essa abordagem de isolamento para melhorar o desempenho de códigos de terceiros.
Monitorar o desempenho das tags
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 relatadas a um endpoint de sua escolha.
Para mais informações, consulte Como criar um monitor do Gerenciador de tags do Google.
Exigir aprovação para alterações 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. Adicionar a verificação em duas etapas, que requer aprovação do administrador para alterações no contêiner, é uma maneira de fazer isso. Como alternativa, se você não quiser exigir a verificação em duas etapas, mas ainda quiser acompanhar as alterações, configure as notificações de contêiner para receber alertas por e-mail sobre os eventos de contêiner de sua escolha.
Audite periodicamente o uso de tags
Um dos desafios de trabalhar com tags é que elas tendem a se acumular ao longo do tempo: 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 isso depende da frequência de atualização das tags do seu site.
Rotular cada tag para que o proprietário fique óbvio facilita a identificação de quem é responsável por ela e pode dizer se ela ainda é necessária.
Ao auditar as tags, não se esqueça de limpar também acionadores e variáveis. Eles também podem ser facilmente a causa de problemas de desempenho.
Para mais informações, consulte Como manter scripts de terceiros sob controle.