Argumentos para Limitar Scripts de Analytics e Rastreamento

Por que os sites usam scripts de analytics e rastreamento

Scripts de analytics e rastreamento servem a um propósito real. O Google Analytics informa 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á apenas adivinhando.

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

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

Qual é o peso desses scripts?

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

• Google Analytics 4 (gtag.js): 134 KB comprimido, 371 KB não comprimido. Carregado de forma assíncrona, por isso não bloqueia o renderizado, mas o JavaScript ainda precisa ser analisado e executado na main thread.
• Google Tag Manager: ~33 KB comprimido para a própria biblioteca, além de quaisquer tags que você colocar dentro dela. O [url=https:\/\/web.dev\/articles\/tag-best-practices]contêiner mediano tem cerca de 50 KB[\/url]. Um contêiner GTM vazio adiciona cerca de 100ms de atraso. Oito tags de rastreamento dentro do GTM adicionam cerca de [url=https:\/\/www.analyticsmania.com\/post\/google-tag-manager-impact-on-page-speed-and-how-to-improve\/]3 segundos em 3G Rápido e 10 segundos em 3G Lento[\/url].
• Facebook\/Meta Pixel: 340 KB não comprimido (95 KB comprimido). Isso é [url=https:\/\/pixely.co.uk\/high-performance-cost-of-facebook-tracking-pixels\/]7 vezes maior que o Google Analytics[\/url]. Ele faz 4 requisições HTTP antes de terminar e adiciona de 1,3 a 1,5 segundos a cada carregamento de página.
• Consent Management Platforms: O OneTrust pode adicionar de 124 a 347 KB, dependendo da configuração. Em um caso, um banner de consentimento [url=https:\/\/www.rumvision.com\/use-cases\/be-wary-a-cookie-banner-may-cause-your-lcp-to-vary\/]tornou-se o elemento LCP[\/url], aumentando o LCP de 1,43s para 3,61s.

  Empilhe GA4 + GTM + Facebook Pixel + um banner de consentimento e você terá cerca de 400 a 600 KB de JavaScript de rastreamento antes de qualquer código seu ser executado. Isso geralmente é mais do que o conteúdo de toda a página em si.

  Como os scripts de rastreamento afetam os Core Web Vitals

  Largest Contentful Paint

  Cada 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 do [url=\/core-web-vitals\/largest-contentful-paint]LCP[\/url] ou CSS crítico. Quando você carrega 8 scripts de rastreamento junto com sua imagem de destaque (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 [url=https:\/\/almanac.httparchive.org\/en\/2025\/performance]Web Almanac de 2025[\/url] 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 [url=\/pagespeed\/14-methods-to-defer-javascript]adiar seus scripts[\/url], mas eles ainda competem por recursos assim que começam a carregar.

  Interaction to Next Paint

  [url=\/core-web-vitals\/interaction-to-next-paint]Interaction to Next Paint (INP)[\/url] é onde os scripts de rastreamento causam mais danos. O [url=https:\/\/almanac.httparchive.org\/en\/2024\/performance]Web Almanac de 2024[\/url] descobriu que o presentation delay é o principal colaborador 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 funcionando muito tempo depois que a página foi carregada. 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 ouvintes de eventos (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 lidar com isso, mas três scripts de rastreamento também disparam ouvintes de eventos que adicionam outros 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 passam. Esses sites principais têm JavaScript mais complexo e mais scripts de terceiros. Se você deseja [url=\/pagespeed\/yield-to-main-thread]manter suas páginas responsivas[\/url], os scripts de rastreamento são o primeiro lugar para olhar.

  Time to First Byte e o excesso de cookies (cookie overhead)

  Cada script de rastreamento pode colocar seus próprios cookies. Cookies individuais são pequenos (mediana de 40 bytes de acordo com o [url=https:\/\/almanac.httparchive.org\/en\/2025\/cookies]capítulo de Cookies do Web Almanac de 2025[\/url]), mas seu impacto coletivo se soma porque os dados dos cookies são enviados com cada requisição HTTP. Se o seu site define 4 KB de cookies e carrega 39 recursos, isso representa 156 KB de dados de upload extras nessas requisições.

  Quando o total de dados de cookies excede cerca de 1.500 bytes, os headers de requisição não cabem mais em um único pacote TCP. Isso força round trips extras, aumentando diretamente o seu [url=\/core-web-vitals\/time-to-first-byte]Time to First Byte[\/url] em navegações subsequentes e carregamentos de recursos estáticos.

  Cumulative Layout Shift

  Banners de consentimento são os piores transgressores aqui. Quando um banner de consentimento de cookies é renderizado tarde e empurra o conteúdo da página para baixo, ele causa um [url=\/core-web-vitals\/cumulative-layout-shift]layout shift[\/url]. Algumas plataformas de consentimento injetam grandes árvores DOM (mais de 200 nodos) que refluem a página. Em um caso documentado, um banner de consentimento foi o elemento LCP para 50% das exibições de página porque foi renderizado 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 individualmente. Para cada uma, pergunte: quem lê esses dados? Quando foram verificados pela última vez? Se ninguém souber responder, remova. Costumo encontrar tags para ferramentas de teste A\/B de campanhas que terminaram há meses, pixels para plataformas de anúncios que a empresa não usa mais e implementações de analytics duplicadas (tanto GA4 via GTM quanto um gtag.js codificado).

  Atrase scripts não essenciais

  Nem tudo precisa carregar na visualização da página. Ninguém jamais ficou desapontado porque um script de mapa de calor levou 3 segundos para começar a gravar. Dispare as tags de analytics e rastreamento no evento Window Loaded ou, melhor ainda, [url=\/pagespeed\/defer-scripts-until-needed]adie-os até que o usuário interaja[\/url] com a página. Os testes da AnalyticsMania mostraram que atrasar o disparo das tags em 1,5 segundos após o carregamento da página economizou 6 segundos em 3G Lento.

  \/\/ Carregar 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 (envios 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 main thread e garante a conclusão mesmo durante a navegação na página. Isso é especialmente importante para [url=\/pagespeed\/datalayer-inp-yield-pattern]manter o INP baixo em interações[\/url] que disparam chamadas de analytics.
  
  \/\/ Enviar dados de analytics sem bloquear a interação
  document.querySelector('.buy-button').addEventListener('click', (e) => {
      \/\/ Use sendBeacon - não bloqueia, sobrevive à navegação da página
      navigator.sendBeacon('\/analytics', JSON.stringify({
          event: 'purchase_click',
          timestamp: Date.now()
      }));
  });
  
  Considere alternativas no lado do servidor (server-side)
  
  A maneira mais eficaz de eliminar o JavaScript de rastreamento é não carregá-lo de forma alguma. O [url=\/pagespeed\/configure-cloudflare-for-passing-the-core-web-vitals]Cloudflare[\/url] Zaraz move a execução do analytics para a borda (edge), substituindo os scripts do gerenciador de tags do lado do cliente por um beacon leve. Contêineres GTM no lado do servidor permitem que seu servidor encaminhe dados para provedores de analytics sem que nenhum JavaScript de fornecedor chegue ao navegador. Essas abordagens exigem mais esforço para configurar, mas seu impacto na performance é próximo de zero.
  
  Para necessidades mais simples, alternativas leves como 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 é um bom resultado
  
  Em todos os sites monitorados pelo [url=https:\/\/coredash.app]CoreDash[\/url], páginas que carregam menos de 5 scripts de terceiros passam no INP em cerca de 88%, em comparação com 64% para páginas que carregam 15 ou mais. A diferença no LCP é igualmente clara: menos requisições competindo 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 carrega, quando carrega e se alguém realmente usa os dados. Comece auditando seu gerenciador de tags. Remova o que não precisa. Adie o que você precisa. Use o [url=https:\/\/coredash.app]Real User Monitoring[\/url] para verificar a melhoria nos field data, 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 de rede e o comportamento real do usuário.
  
  [include]cwv\/authorbio.html[\/include]
  
      
  
      
  [include]sidebar.html[\/include]
  
    
  
  
  [include]blogfooter.html[\/include]