Otimizar tags e gerenciadores de tags para as Core Web Vitals.
Tags são snippets de códigos de terceiros inseridos em um site, normalmente por meio de um gerenciador de tags. As tags são usadas com mais frequência para marketing e análises.
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: eles oferecem uma embutido, mas o que você o preencherá e como usá-lo depende, na maior parte, de você.
Este artigo discute técnicas para otimizar tags e gerenciadores de tags em o desempenho do seu site e as Métricas da Web. Embora este artigo faça referência ao Gerenciador de tags do Google, muitas das ideias discutidas também são aplicáveis a outros gerenciadores de tags.
Impacto nas Core Web Vitals
Muitas vezes, o Gerenciador de tags pode afetar suas Core Web Vitals de forma indireta usando 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 feitas por ele. 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 Cumulative Layout Shift (CLS, na sigla em inglês) pode ser afetada pelo atraso do carregamento de recursos críticos antes da primeira renderização ou pelos gerenciadores de tags que injetam conteúdo na página.
A interação com a Next Paint (INP) é suscetível à contenção de CPU na linha de execução principal. Além disso, notamos 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 imagens tags ("pixels") têm o melhor desempenho, seguidas por modelos personalizados, e por fim, as tags HTML personalizadas. As tags dos fornecedores variam de acordo com a funcionalidade permitir.
No entanto, o uso da tag influencia muito a performance dela. impacto. "Pixels" têm alto desempenho em grande parte porque a natureza dessa tag tipo impõe restrições rígidas em relação ao uso deles; as tags HTML personalizadas necessariamente sempre ruim para o desempenho, mas devido ao nível de liberdade que oferecem aos usuários, eles podem ser fáceis de usar de forma indevida e prejudicar o desempenho.
Ao pensar em tags, tenha em mente a escala: o impacto no desempenho de qualquer tag única pode ser insignificante, mas pode se tornar importante quando dezenas ou centenas são usadas na mesma página.
Nem todos os scripts precisam ser carregados usando um gerenciador de tags.
Os gerenciadores de tags geralmente não são um bom mecanismo para carregar recursos que implementar aspectos visuais ou funcionais imediatos da experiência do usuário, por por exemplo, avisos de cookies, imagens principais ou recursos do site. Usar um Gerenciador de tags para carregar esses recursos geralmente atrasa a entrega. Isso é ruim para o usuário experiência do usuário e também pode aumentar métricas como LCP e CLS. Além disso, mantenha lembre-se de que alguns usuários bloqueiam os gerenciadores de tags. Usar um Gerenciador de tags para implementar a UX pode resultar em um site corrompido para alguns dos seus usuários.
Cuidado com tags HTML personalizadas
HTML personalizado
tags
já existem há muitos anos e são muito usados na maioria dos sites. HTML personalizado
permitem que você insira seu próprio código com poucas restrições, já que, apesar do nome,
o principal uso dessa tag é para adicionar elementos <script> personalizados a uma página.
As tags HTML personalizadas podem ser usadas de diversas formas e têm impacto no desempenho varia significativamente. Ao avaliar o desempenho do seu site, esteja ciente de que a maioria das ferramentas atribui o impacto no desempenho de uma tag HTML personalizada à tag que o injetou, em vez da tag em si.
As tags HTML personalizadas podem inserir um elemento na página ao redor. O ato de inserir elementos na página pode ser uma fonte de problemas de desempenho, e em alguns casos, também causam trocas 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 no desempenho de um único layout é mínimo, mas quando ocorre em excesso, pode se tornar uma fonte de problemas de desempenho. O impacto dessa é maior em dispositivos mais simples e em páginas com um alto número de Elementos DOM.
- Se um elemento de página visível for inserido no DOM após o elemento área já foi renderizada, isso pode causar uma mudança de layout. Esse fenômeno não é exclusivo dos gerenciadores de tags. No entanto, as tags costumam carregar mais tarde do que outras partes da página, é comum que elas sejam inseridas DOM depois que a página ao redor já tiver sido renderizada.
Considere usar modelos personalizados
Suporte a modelos personalizados algumas das operações das tags HTML personalizadas, mas são criadas com base em uma do JavaScript que oferece APIs para uso comum casos como injeção de script e injeção de pixels. Como o nome indica, eles permitem um modelo a ser criado, por um usuário avançado capaz de construí-lo com desempenho em em mente. Usuários menos técnicos podem usar o modelo. Geralmente, essa opção é mais segura do que fornecer acesso HTML personalizado completo.
Devido às maiores restrições impostas aos modelos personalizados, essas tags são muito menos probabilidade de apresentar problemas de desempenho ou segurança; No entanto, para essas mesmas motivos, os modelos personalizados não funcionarão para todos os casos de uso.
Injetar scripts corretamente
Usar um gerenciador de tags para injetar um script é um caso de uso muito comum. O
recomendada de fazer isso é usar um modelo personalizado e a
injectScript
API.
Para informações sobre como usar a API injectScript para converter um HTML personalizado existente tag, consulte Converter uma tag tag.
Se você precisar usar uma tag HTML personalizada, lembre-se do seguinte:
- Bibliotecas e scripts grandes de terceiros precisam ser carregados por uma tag de script
que faz o download de um arquivo externo (por exemplo,
<script src="external-scripts.js">), em vez de copiar e colar diretamente na tag. Embora abandonar o uso da tag<script>elimina uma ida e volta separada para baixar o conteúdo do script, isso aumenta o tamanho do contêiner e evita que o script seja armazenado em cache. separadamente pelo navegador. - Muitos fornecedores recomendam colocar a tag
<script>na parte superior<head>. No entanto, para scripts carregados pelo Gerenciador de tags, geralmente é desnecessária: na maioria das situações, o navegador já terminou analisando<head>no momento da execução do gerenciador de tags.
Usar pixels
Em algumas situações, scripts de terceiros podem ser substituídos por imagem ou iframe "pixels". Em comparação com seus equivalentes baseados em script, os pixels podem oferecer suporte têm menos funcionalidade, por isso são frequentemente vistas como uma implementação menos preferida porque disso. No entanto, quando usados em gerenciadores de tags, os pixels podem ser mais dinâmicos. pois podem ser disparadas em acionadores e transmitir variáveis diferentes. Eles são os mais de tag com alto desempenho e segurança, porque não há execução de JavaScript depois ele é acionado. Os pixels têm um tamanho de recurso muito pequeno (menos de 1 KB) e não causar mudanças de layout.
Consulte seu provedor terceirizado para mais informações sobre o suporte dele para
pixels. Além disso, você pode verificar se há uma tag <noscript> no código.
Se um fornecedor oferece suporte a pixels, ele geralmente os inclui no campo
<noscript>.
Alternativas aos pixels
Os pixels se tornaram populares em grande parte porque já eram um dos dispositivos mais baratos
mais confiáveis de se fazer uma solicitação HTTP em situações em que o servidor
resposta não é relevante ( por exemplo, ao enviar dados para análise
provedores de rede). O
navigator.sendBeacon()
e fetch()
keepalive
As APIs são projetadas para abordar esse mesmo caso de uso, mas são possivelmente mais confiáveis
de pixels.
Não há nada de errado em continuar usando pixels. Eles são bem compatíveis têm impacto mínimo no desempenho. No entanto, se você estiver criando seus próprios sensores, vale a pena considerar o uso de uma dessas APIs.
sendBeacon()
O
navigator.sendBeacon()
A API 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: ele só aceita fazer solicitações POST e não
não são compatíveis com a configuração de cabeçalhos personalizados. É
compatível com todos os navegadores modernos.
fetch() keepalive
keepalive
é uma sinalização que permite que o recurso Buscar
API para
ser usada para fazer solicitações sem bloqueio, como relatórios e análises de eventos. É
usado pela inclusão de 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
os dados. Na verdade, nos navegadores Chromium, o sendBeacon() agora é baseado no fetch()
keepalive.
Ao escolher entre fetch() keepalive e sendBeacon(), é importante
considere os recursos e o suporte para navegadores que você precisa. A API fetch() é
muito mais flexível, No entanto, keepalive tem menos restrições
support do que sendBeacon().
Esclarecimento
Em geral, as tags são criadas seguindo a orientação 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. Ter uma segunda opinião ajuda a identificar se uma tag pode criar problemas de desempenho ou segurança.
Também é recomendável rotular as tags com um proprietário no Gerenciador de tags. É longe é muito fácil esquecer quem é o proprietário da tag, e ter medo de removê-la por precaução!
Gatilhos
De modo geral, otimizar a tag gatilhos geralmente consiste em não acionar tags mais do que o necessário e escolher um gatilho que equilibre as necessidades comerciais com os custos de performance.
Os próprios gatilhos são códigos JavaScript que aumentam o tamanho e a execução do Gerenciador de tags. Embora a maioria dos acionadores sejam pequenos, o efeito cumulativo pode se somam. Ter muitos eventos de clique, por exemplo, ou acionadores de temporizador pode aumentar a carga de trabalho do Gerenciador de tags.
Escolher um evento acionador apropriado
O impacto no desempenho de uma tag não é fixo: de modo geral, quanto mais cedo que uma tag dispara, maior é o impacto no desempenho. Os recursos normalmente são restritos durante o carregamento inicial da página e, portanto, carregar ou executar determinado recurso (ou tag) tire os recursos de outra coisa.
Embora seja importante escolher acionadores apropriados para todas as tags, é especialmente importante para tags que carregam recursos grandes ou são executadas scripts.
As tags podem ser acionadas
Visualizações de página
(normalmente 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
Eventos personalizados
permitem disparar acionadores em resposta a eventos da página que não são cobertos pelo
acionadores integrados do Gerenciador de tags do Google. Por exemplo, muitas tags usam visualização de página
gatilhos No entanto,
o período entre DOM Ready e Window Loaded pode ser longo em muitos
páginas, e isso pode dificultar o ajuste fino quando uma tag é disparada. Personalizado
oferecem uma solução para esse problema.
Para usar eventos personalizados, primeiro crie um acionador de evento personalizado e atualize suas tags para usar esse acionador.
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
O uso de condições específicas de acionamento ajuda a evitar disparar uma tag desnecessariamente. Embora existam muitas maneiras de aplicar esse conceito, uma das mais simples Você pode garantir que uma tag só seja disparada nas páginas usados.
As variáveis incorporadas podem também podem ser incorporadas às condições de acionamento para limitar o disparo de tags.
No entanto, tenha em mente que ter condições ou exceções de acionamento complexas leva o tempo de processamento automaticamente. Portanto, não os torne muito complexos.
Carregue o Gerenciador de tags em um momento adequado
Ajustar o momento em que o próprio Gerenciador de tags é carregado pode ter um impacto significativo na desempenho. Independentemente de como estão configurados, os gatilhos não podem ser disparados até após o carregamento de um Gerenciador de tags. Embora seja importante escolher bons gatilhos para tags individuais (conforme explicado acima), experimentando quando você carrega sua tag de projeto muitas vezes pode ter um impacto igual ou maior, já que esse único afeta todas as tags de uma página.
Carregar o Gerenciador de tags mais tarde também adiciona uma camada de controle e evita problemas futuros problemas de desempenho, já que impede o carregamento acidental de usuários do Gerenciador de tags uma tag muito cedo, sem perceber o impacto que isso pode ter.
Variáveis
As variáveis permitem que os dados sejam lidos na página. São úteis em gatilhos e nas próprias tags.
Assim como os acionadores, as variáveis resultam na adição de código JavaScript ao Gerenciador de tags, o que pode causar problemas de desempenho. As variáveis podem ser integradas que podem, por exemplo, ler partes do URL, cookies, camada de dados ou DOM. Ou podem ser um JavaScript personalizado com uma capacidade ilimitada de ação.
Manter as variáveis simples e mínimas, porque 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 usa.
Gerenciador de tags
O uso eficiente das tags reduz 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 da 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, sua utilização é altamente recomendado. A camada de dados permite consolidar as informações por scripts de terceiros em um único local, possibilitando assim melhor visibilidade do uso. Entre outras coisas, isso pode ajudar a reduzir cálculos de variáveis redundantes e execução de script. Usar uma camada de dados também controla os dados que estão sendo acessados pelas tags em vez de fornecer código JavaScript completo variável ou o acesso DOM.
Remova tags duplicadas e não usadas
Tags duplicadas podem ocorrer quando uma tag é incluída na marcação HTML de uma página por um gerenciador de tags.
As tags não utilizadas devem ser pausadas ou removidas, em vez de bloqueadas com o uso de uma exceção de acionador. Pausar ou remover uma tag remove o código do contêiner. o bloqueio faz não.
Quando tags não usadas são removidas, os acionadores e as variáveis também precisam ser analisamos se algum deles pode ser removido caso seja usado apenas por .
Usar listas de permissão e negação
Listas de permissão e negação permitem configurar restrições altamente granulares nas tags, acionadores e variáveis permitidas em uma página. Isso pode ser usado para ajudar a aplicar as práticas recomendadas 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, JavaScript variáveis ou acesso direto ao DOM. Ou seja, apenas pixels e tags predefinidas pode ser usado com dados da camada de dados. Embora isso seja certamente restritivo, pode resultar em uma implementação do Gerenciador de tags com muito mais desempenho e segurança.
Usar a inclusão de tags no servidor
Mudar para a inclusão de tags no servidor não é uma tarefa simples, mas vale a pena considerando, especialmente para sites maiores que querem mais controle sobre dados. A inclusão de tags no servidor remove o código do fornecedor do cliente e, com ele, descarrega o processamento do cliente para o servidor.
Por exemplo, ao usar a inclusão de tags do lado do cliente, enviar dados para várias análises implica que o cliente inicie solicitações separadas para cada ponto de extremidade. Já com a inclusão de tags no servidor, o cliente faz uma única solicitação no contêiner do servidor e, a partir daí, esses dados são encaminhados do Google Analytics.
A inclusão de tags no servidor só funciona com algumas tags. marcar a compatibilidade varia de acordo com o fornecedor.
Para mais informações, consulte Introdução à abordagem do lado do servidor inclusão de tag.
Contêineres
Os gerenciadores de tags geralmente permitem várias instâncias ou "contêineres" em suas configurar. Isso permite que vários contêineres sejam controlados na mesma tag conta de administrador.
Usar apenas um contêiner por página
Usar várias contêineres em uma única página pode criar problemas significativos de desempenho, pois introduz sobrecarga adicional e a execução do script. No mínimo, ela duplica código da tag principal que, como é entregue como parte do JavaScript, não pode ser reutilizado entre os contêineres.
É raro que vários contêineres sejam usados de forma eficaz. No entanto, pode haver instâncias em que isso pode funcionar (se bem controlado), incluindo:
- Ter uma "carga antecipada" mais leve e um "carregamento posterior" mais pesado container, em vez de um grande contêiner.
- Ter um contêiner restrito usado por usuários menos técnicos, com uma um contêiner mais restrito, mas mais 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 o Gerenciador de tags do Google da configuração de várias contêineres.
Use contêineres separados, se necessário
Se você usa um gerenciador de tags para várias propriedades (por exemplo, um app da Web e uma aplicativo para dispositivos móveis), a quantidade de contêineres que você usa pode ajudar ou prejudicar seu fluxo de trabalho produtividade. Isso também pode afetar o desempenho.
De modo geral, um único contêiner pode ser usado com eficiência em vários se os sites forem semelhantes em termos de uso e estrutura. Por exemplo, embora um aplicativos móveis e da web da marca podem servir a funções semelhantes, é provável que os apps serão estruturados de forma diferente e, portanto, gerenciados usando contêineres separados.
A tentativa de reutilizar um único contêiner de forma muito ampla normalmente aumenta desnecessariamente a complexidade e o tamanho do contêiner, forçando a adoção de lógica complexa para gerenciar tags e acionadores.
Acompanhe o tamanho do contêiner
O tamanho de um contêiner é determinado pelas tags, acionadores e variáveis. Um contêiner pequeno ainda pode afetar negativamente o desempenho da página, mas um contêiner grande contêiner certamente vai.
O tamanho do contêiner não deve ser a principal métrica ao otimizar sua tag uso No entanto, um tamanho de contêiner grande geralmente é um sinal de aviso não seja bem mantida e possivelmente mal utilizada.
Gerenciador de tags do Google contêiner limits tamanho máximo de 200 KB e um aviso sobre o tamanho do contêiner a partir de 140 KB. No entanto, a maioria dos sites deve manter seus contêineres muito menores do que isso. Para o contêiner médio do site tem cerca de 50 KB.
Para determinar o tamanho do seu contêiner, observe o tamanho da resposta
retornado por https://www.googletagmanager.com/gtag/js?id=YOUR_ID. Isso
resposta contém a biblioteca do Gerenciador de tags do Google e o conteúdo da
contêiner do Docker. Sozinha, a biblioteca do Gerenciador de tags do Google tem cerca de 33 KB
compactado.
Nomeie as versões do contêiner
Um contêiner versão é um instantâneo do conteúdo de um contêiner em um momento específico. Ao usar um um nome significativo e incluindo uma breve descrição de nomes pode facilitar a depuração do desempenho futuro problemas.
Fluxos de trabalho de inclusão de tag
Gerenciar alterações em suas tags é importante para garantir que elas não tenham um um impacto negativo no desempenho da página.
Testar as tags antes da implantação
Testar as tags antes da implantação pode ajudar a detectar problemas (como antes do envio.
Ao testar uma tag, considere os seguintes pontos:
- A tag está funcionando corretamente?
- A tag causa alguma mudança 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 para testar as alterações de tag no seu site sem ter que implantá-las no público. O modo de visualização inclui um console de depuração informações sobre tags.
O tempo de execução do Gerenciador de tags do Google será diferente (um pouco mais lento) quando executados no modo de visualização, devido à sobrecarga adicional necessária para expor informações no console de depuração. Assim, comparar as medições das Métricas da Web coletados no modo de visualização àqueles coletados na produção não é recomendado. No entanto, essa discrepância não deve afetar o comportamento de execução das tags. por conta própria.
Testes autônomos
Uma abordagem alternativa ao teste de tags é configurar uma página vazia contendo uma contêiner com uma única tag: a que você está testando. Essa configuração de teste é menos realista e não detectará alguns problemas (por exemplo, se uma tag faz com que o layout mudanças), no entanto, pode facilitar o isolamento e a medição do impacto do a tags em coisas como a execução de scripts. Veja como o Telegraph usa isso abordagem de isolamento para melhorar performance de código de terceiros.
Monitorar a performance das tags
Monitoramento do Gerenciador de tags do Google API pode ser usada. para coletar informações sobre a execução horário de uma tag específica. Essas informações são enviadas a um endpoint da que você escolher.
Para mais informações, consulte Como criar um Gerenciador de tags do Google Monitorar.
Exigir aprovação para alterações de contêiner
O código próprio geralmente passa por revisão e teste antes da implantação. as tags da mesma forma. Adicionando o processo verificação, 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 ficar de olho nas alterações, você poderá configurar configuração notificações para receber alertas por e-mail sobre eventos de contêiner que você escolher.
Faça auditorias periódicas do uso de tags
Um dos desafios de trabalhar com tags é que elas tendem a se acumular time: as tags são adicionadas, mas raramente são removidas. A auditoria periódica de tags é uma para reverter essa tendência. A frequência ideal para fazer isso dependerá de quão as tags do seu site são atualizadas com frequência.
Rotular cada tag de forma que o proprietário fique claro para facilitar a identificação de quem é responsivo para essa tag e pode dizer se ela ainda é necessária.
Ao auditar tags, não se esqueça de limpar acionadores e variáveis, muito bem. Eles também podem ser facilmente a causa de problemas de desempenho.
Para mais informações, consulte Manter scripts de terceiros controle.