O Argumento para Limitar Scripts de Analytics e Rastreamento

O Argumento para Limitar Scripts de Analytics e Rastreamento

Gasto grande parte do meu tempo auditando sites e, em cerca de 90% dessas auditorias, encontro scripts de rastreamento não utilizados. Scripts que ninguém lembra de ter adicionado, scripts que rastreiam dados que ninguém lê, scripts que eram "apenas mais um pixel" adicionado pelo marketing dois anos atrás. Cada um parecia inofensivo na época. Juntos, eles adicionam segundos a cada carregamento de página.

De acordo com o relatório de rastreamento web de 2024 da Kaspersky, o site médio agora tem 48 rastreadores. O Web Almanac de 2025 mostra que mais de 90% das páginas web incluem pelo menos um script de terceiros, e os 1.000 sites mais visitados disparam uma mediana de 129 requisições de terceiros no desktop. Isso não é uma estratégia de rastreamento. Isso é um problema de performance.

Última revisão por Arjen Karel em março de 2026

Por que os sites usam scripts de analytics e rastreamento

Scripts de analytics e rastreamento servem a um propósito real. O Google Analytics diz de onde vêm seus visitantes. O Facebook Pixel rastreia conversões de anúncios. O Hotjar mostra onde as pessoas clicam. Sem esses dados, você está adivinhando.

O problema não é que essas ferramentas existam. O problema é que a maioria dos sites carrega muito mais rastreamento do que precisa. Ferramentas populares como Google Analytics, Facebook Pixel e Cloudflare analytics adicionam JavaScript, cookies e requisições HTTP. E eles raramente são o único rastreamento na página.

Fato: Em cerca de 90% de todas as auditorias, encontrarei scripts de rastreamento não utilizados. Geralmente, esses scripts são injetados tardiamente através de um gerenciador de tags ou outro script de terceiros.

Quão pesados são esses scripts?

Nem todos os scripts de rastreamento são criados iguais. Aqui está o que os mais comuns realmente custam a você:

• Google Analytics 4 (gtag.js): 134 KB compactado, 371 KB descompactado. Carregado de forma assíncrona, portanto não bloqueia a renderização, mas o JavaScript ainda precisa ser analisado e executado na thread principal.
• Google Tag Manager: ~33 KB compactado para a própria biblioteca, mais quaisquer tags que você coloque dentro dele. O contêiner mediano tem cerca de 50 KB. Um contêiner GTM vazio adiciona cerca de 100ms de atraso. Oito tags de rastreamento dentro do GTM adicionam cerca de 3 segundos em 3G Rápido e 10 segundos em 3G Lento.
• Facebook/Meta Pixel: 340 KB descompactado (95 KB compactado). Isso é 7 vezes maior que o Google Analytics. Ele faz 4 requisições HTTP antes de terminar e adiciona 1.3 a 1.5 segundos a cada carregamento de página.
• Plataformas de Gerenciamento de Consentimento: O OneTrust pode adicionar 124 a 347 KB dependendo da configuração. Em um caso, um banner de consentimento tornou-se o elemento LCP, aumentando o LCP de 1.43s para 3.61s.

Empilhe GA4 + GTM + Facebook Pixel + um banner de consentimento e você está olhando para cerca de 400 a 600 KB de JavaScript de rastreamento antes que qualquer parte do seu próprio código seja executada. Isso geralmente é mais do que o conteúdo inteiro da página em si.

Como scripts de rastreamento afetam os Core Web Vitals

Largest Contentful Paint

Todo script compete por largura de banda da rede e tempo de CPU durante o carregamento da página. Mesmo scripts assíncronos ocupam largura de banda que poderia ser usada para a imagem LCP ou CSS crítico. Quando você carrega 8 scripts de rastreamento junto com sua hero image, você está forçando o navegador a compartilhar sua largura de banda móvel limitada entre todos eles.

Isso é particularmente ruim em redes móveis. O Web Almanac de 2025 relata um Total Blocking Time móvel mediano de 1.916ms (um aumento de 58% em relação a 2024). Grande parte desse bloqueio vem de JavaScript de terceiros. Você pode adiar seus scripts, mas eles ainda competem por recursos assim que começam a carregar.

Interaction to Next Paint

Interaction to Next Paint (INP) é onde os scripts de rastreamento causam o maior dano. O Web Almanac de 2024 descobriu que o atraso de apresentação é o principal contribuinte para um INP ruim, e os scripts que o causam são ferramentas de rastreamento de comportamento, provedores de consentimento e pixels de publicidade.

Muitos scripts de rastreamento continuam trabalhando muito depois da página ter carregado. O Google Analytics pode ser configurado para rastrear cada clique. Ferramentas de mapa de calor como o Hotjar escutam cada movimento do mouse. Cada um desses event listeners adiciona tempo de processamento às interações do usuário. Quando um visitante clica em um botão e seu código leva 50ms para processá-lo, mas três scripts de rastreamento também disparam event listeners que adicionam mais 150ms, a interação parece lenta.

Os números contam a história: 77% de todas as páginas móveis passam no INP, mas apenas 53% dos 1.000 sites mais visitados conseguem. Esses sites de topo têm JavaScript mais complexo e mais scripts de terceiros. Se você deseja manter suas páginas responsivas, os scripts de rastreamento são o primeiro lugar para olhar.

Time to First Byte e sobrecarga de cookies

Cada script de rastreamento pode colocar seus próprios cookies. Cookies individuais são pequenos (mediana de 40 bytes de acordo com o capítulo de Cookies do Web Almanac de 2025), mas seu impacto coletivo se acumula porque os dados do cookie são enviados com cada requisição HTTP. Se o seu site define 4 KB de cookies e carrega 39 recursos, são 156 KB de dados de upload extras através dessas requisições.

Quando o total de dados de cookies excede aproximadamente 1.500 bytes, os cabeçalhos de requisição não cabem mais em um único pacote TCP. Isso força viagens de ida e volta extras, aumentando diretamente o seu Time to First Byte em navegações subsequentes e carregamentos de recursos estáticos.

Cumulative Layout Shift

Os banners de consentimento são os piores infratores aqui. Quando um banner de consentimento de cookies renderiza tarde e empurra o conteúdo da página para baixo, ele causa um layout shift. Algumas plataformas de consentimento injetam grandes árvores DOM (mais de 200 nós) que causam reflow na página. Em um caso documentado, um banner de consentimento foi o elemento LCP para 50% das visualizações de página porque renderizou em cima do conteúdo real.

Estratégias para um rastreamento mais inteligente

Audite o que você realmente usa

Abra seu gerenciador de tags e analise cada tag. Para cada uma, pergunte: quem lê esses dados? Quando foi verificado pela última vez? Se ninguém souber responder, remova. Eu rotineiramente encontro tags para ferramentas de teste A/B de campanhas que terminaram meses atrás, pixels de plataformas de anúncios que a empresa não usa mais e implementações duplicadas de analytics (tanto GA4 via GTM quanto um gtag.js hardcoded).

Atrase scripts não essenciais

Nem tudo precisa carregar na visualização da página. Ninguém jamais ficou desapontado que um script de mapa de calor levou 3 segundos para começar a gravar. Dispare tags de analytics e rastreamento no evento Window Loaded ou, ainda melhor, adie-as até que o usuário interaja com a página. Os testes do AnalyticsMania mostraram que atrasar o disparo de tags em 1.5 segundos após o carregamento da página economizou 6 segundos em 3G Lento.

// Carregue o analytics apenas após a primeira interação do usuário
const events = ['click', 'scroll', 'mousemove', 'touchstart'];
const loadAnalytics = () => {
    events.forEach(e => document.removeEventListener(e, loadAnalytics));
    // Carregue seu script de analytics aqui
    const script = document.createElement('script');
    script.src = 'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX';
    document.head.appendChild(script);
};
events.forEach(e => document.addEventListener(e, loadAnalytics, {once: true}));

Use a API Beacon para eventos personalizados

Se você envia eventos de analytics personalizados (envio de formulários, cliques em botões, profundidade de rolagem), use navigator.sendBeacon() em vez de XMLHttpRequest. A API Beacon envia dados de forma assíncrona sem bloquear a thread principal e tem garantia de conclusão mesmo durante a navegação na página. Isso é especialmente importante para manter o INP baixo em interações que disparam chamadas de analytics.

// Envie dados de analytics sem bloquear a interação
document.querySelector('.buy-button').addEventListener('click', (e) => {
    // Use sendBeacon - não bloqueante, sobrevive à navegação da página
    navigator.sendBeacon('/analytics', JSON.stringify({
        event: 'purchase_click',
        timestamp: Date.now()
    }));
});

Considere alternativas server-side

A maneira mais eficaz de eliminar o JavaScript de rastreamento é não carregá-lo de forma alguma. O Cloudflare Zaraz move a execução do analytics para o edge, substituindo scripts de gerenciadores de tags client-side por um beacon leve. Os Contêineres Server-Side do GTM permitem que seu servidor encaminhe dados para provedores de analytics sem que qualquer JavaScript do fornecedor chegue ao navegador. Essas abordagens exigem mais esforço para serem configuradas, mas seu impacto na performance é próximo a zero.

Para necessidades mais simples, alternativas leves como o Plausible (menos de 1 KB) ou Umami (cerca de 2 KB) fornecem analytics de tráfego por uma fração do custo de 134 KB do GA4.

Como é o cenário ideal

Em sites monitorados pelo CoreDash, as páginas que carregam menos de 5 scripts de terceiros passam no INP em aproximadamente 88%, em comparação com 64% para páginas que carregam 15 ou mais. A diferença no LCP é igualmente clara: menos requisições concorrentes significa que o navegador pode priorizar o que realmente importa para o visitante.

Você não precisa remover todo o rastreamento. Você precisa ser intencional sobre o que você carrega, quando você o carrega, e se alguém realmente usa os dados. Comece auditando seu gerenciador de tags. Remova o que você não precisa. Atrase o que você precisa. Use o Real User Monitoring para verificar a melhoria nos dados de campo, porque os testes de laboratório não mostrarão o quadro completo de como os scripts de rastreamento interagem com as condições reais da rede e o comportamento real do usuário.