Remover Parâmetros de Rastreamento com Cloudflare Workers e Transform Rules

Por que os parâmetros de rastreamento destroem sua taxa de acerto de cache

Parâmetros de rastreamento como utm_source, gclid e fbclid ajudam os profissionais de marketing a medir o desempenho das campanhas. Para o Core Web Vitals eles são um pesadelo porque quebram o cache. Cada URL exclusiva cria uma entrada de cache separada. Uma única página compartilhada no Facebook recebe um fbclid exclusivo para cada clique, o que significa que cada visitante do Facebook recebe uma falha de cache e um Time to First Byte lento.

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

O problema de cache com parâmetros de rastreamento

Os sistemas de cache usam a URL completa como chave de cache. Se uma URL inclui ?utm_source=google ou ?fbclid=abc123, o cache a trata como uma página diferente, mesmo que o conteúdo seja idêntico. Isso é uma falha de cache. O servidor reconstrói uma página que já possui em cache, apenas porque a URL tem um valor diferente na string de consulta.

A escala deste problema é maior do que a maioria das pessoas imagina. Existem 129 parâmetros de rastreamento conhecidos em todo o ecossistema de marketing. O parâmetro fbclid é o mais destrutivo porque o Facebook o anexa a cada clique em link de saída, não apenas em anúncios pagos. Cada compartilhamento orgânico, cada link em um comentário, cada postagem que vincula ao seu site recebe um valor fbclid exclusivo.

De acordo com o Web Almanac de 2025, apenas 44% das origens móveis têm um bom TTFB. A Cloudflare relatou que corrigir o comportamento de cache da string de consulta melhorou as taxas de acerto de cache em 3% em média e reduziu os bytes de origem em 5%. Isso se traduz diretamente em um Largest Contentful Paint mais rápido para os seus visitantes.

Nem todos os parâmetros de consulta são lixo de rastreamento. Parâmetros como ?q=laptops ou ?color=blue alteram o conteúdo da página. O objetivo é remover os parâmetros que não afetam o conteúdo, mantendo aqueles que afetam.

Quais parâmetros de rastreamento você deve remover?

Aqui estão os parâmetros de rastreamento mais comuns agrupados por plataforma. Eles criam URLs exclusivas e não armazenáveis em cache sem alterar o conteúdo da página:

Esta não é a lista completa. O registro de parâmetros de consulta de rastreamento documenta todos os 129 parâmetros conhecidos. Para a maioria dos sites, cobrir os parâmetros do Google, Meta e Microsoft resolve 95% do problema.

Opção 1: Transform Rules (sem necessidade de código)

A Cloudflare possui uma função integrada chamada remove_query_args() que remove parâmetros de consulta específicos da URL antes que ela chegue ao cache. Isso é executado como uma Transform Rule, não requer código e está disponível em todos os planos, incluindo o nível gratuito.

Para configurar isso:

1. No painel da Cloudflare, acesse Rules, depois Transform Rules e então URL Rewrite
2. Crie uma nova regra
3. Defina o filtro para corresponder ao seu domínio, por exemplo (http.host eq "example.com")
4. Para Query, selecione Rewrite to e depois Dynamic
5. Insira a expressão:
   remove_query_args(http.request.uri.query, "utm_source", "utm_medium", "utm_campaign", "utm_term", "utm_content", "utm_id", "gclid", "gclsrc", "wbraid", "gbraid", "dclid", "gad_source", "fbclid", "msclkid", "ttclid", "twclid", "li_fat_id", "epik", "srsltid", "_ga", "_gl")
6. Para Path, selecione Preserve

É isso. Sem Worker, sem implantação de código. O plano gratuito permite 10 Transform Rules, o Pro permite 25. Para a maioria dos sites, esta é a melhor opção.

Opção 2: Cloudflare Workers

A Cloudflare possui opções prontas para uso para ignorar strings de consulta, mas suas configurações conservadoras não são suficientes para aproveitar ao máximo o seu plano da Cloudflare. Se você precisa de mais controle do que as Transform Rules oferecem (por exemplo, correspondência de regex, lógica condicional ou registro de logs), um Cloudflare Worker oferece flexibilidade total.

Os Workers interceptam as solicitações na borda (edge) e executam o seu código antes que a solicitação chegue ao cache ou à origem. A Cloudflare carrega os Workers durante o handshake TLS, portanto, a sobrecarga efetiva é inferior a 1 milissegundo.

O código

Abaixo está o script completo do Worker usando a sintaxe atual de módulos ES:

export default {
  async fetch(request) {
    const url = new URL(request.url)

    const trackingParams = /^(utm_|gad_|gclid|gclsrc|wbraid|gbraid|dclid|fbclid|fb_action_|srsltid|msclkid|ttclid|twclid|li_fat_id|epik|igshid|_ga$|_gl$|mc_[ce]id|_hs[em])/

    // Colete as chaves correspondentes primeiro (não exclua durante a iteração)
    const keysToDelete = [...url.searchParams.keys()].filter(
      key => trackingParams.test(key)
    )

    keysToDelete.forEach(key => url.searchParams.delete(key))

    return fetch(url.toString(), request)
  }
}

O Worker analisa a URL, testa cada parâmetro de consulta em relação a uma regex e remove as correspondências. A URL limpa então vai para o cache e a origem. Dois detalhes importam aqui: o código coleta chaves em um array antes de excluí-las, porque a exclusão durante a iteração de URLSearchParams pode pular entradas (este é um problema de especificação conhecido com iteradores ativos). E o script usa o formato de módulos ES (export default) porque a Cloudflare descontinuou a sintaxe mais antiga de addEventListener.

Implantação

1. Faça login na Cloudflare. Entre no painel da sua conta Cloudflare.
2. Crie um Worker. Ainda não navegue até o seu site. Navegue até a seção Workers e crie um novo Worker.
   
3. Nomeie o worker e implante. Este passo pode parecer um pouco contra-intuitivo, mas não se preocupe. Apenas nomeie o seu worker vazio de 'hello world' e clique em deploy.
   
4. Edite o seu worker. Na próxima página, clique em Edit Code.
   
5. Cole o script. Copie e cole o script acima no editor. Em seguida, clique em deploy.
   
6. Vincule o Worker a uma rota. Agora volte e navegue até o seu site na Cloudflare. Clique em worker routes e depois em 'Add Route'. Selecione o worker recém-criado e aplique-o ao seu site.
   

Personalização

Você pode modificar a regex para incluir ou excluir parâmetros específicos. Se quiser preservar certos parâmetros utm_ para processamento no lado do servidor, remova-os da regex. Se você usa uma plataforma de marketing não coberta pela regex padrão, adicione os parâmetros dela.

Opção 3: Personalização de Cache Key (Enterprise)

Se você estiver em um plano Cloudflare Enterprise, pode configurar chaves de cache personalizadas para excluir parâmetros de consulta específicos sem removê-los da URL. O cache simplesmente os ignora ao calcular a chave. Esta é a abordagem mais limpa porque a URL permanece inalterada, mas requer o plano Enterprise.

Para planos não-Enterprise, a abordagem de Transform Rule ou Worker atinge o mesmo benefício de cache.

Qual abordagem você deve usar?

Para a maioria dos sites, comece com as Transform Rules. Se você atingir o limite de regras ou precisar de mais flexibilidade, mude para os Workers.

Se você usa o WordPress com Cloudflare APO, talvez não precise de nada disso. O APO mantém uma lista de permissões de mais de 25 parâmetros de marketing que ele ignora ao calcular as chaves de cache. Verifique se os seus parâmetros específicos estão cobertos antes de adicionar um Worker ou Transform Rule.

Remover parâmetros prejudica o analytics?

Não. A remoção acontece na borda (edge), entre a CDN e o seu servidor de origem. A URL do navegador ainda contém os parâmetros de rastreamento originais. O Google Analytics, o rastreamento de conversões do Google Ads e o pixel do Facebook leem a partir do document.location no lado do cliente, que ainda possui a URL completa com todos os parâmetros intactos.

O único cenário onde isso poderia causar problemas é se o seu código no lado do servidor ler parâmetros de rastreamento da URL (por exemplo, uma implementação de analytics no lado do servidor). Nesse caso, exclua esses parâmetros da remoção ou capture-os em um cabeçalho de solicitação antes que o Worker os remova.

Para uma visão mais ampla de como os scripts de rastreamento e analytics afetam o desempenho além do cache, consulte O argumento a favor da limitação de scripts de analytics e rastreamento.

Como descobrir quais parâmetros de URL remover

Descobrir quais parâmetros de URL remover é fácil se você usar a ferramenta certa. Ferramentas de Real User Monitoring como o CoreDash monitoram o seu site 24 horas por dia, 7 dias por semana, e registram todas as strings de consulta, juntamente com o seu impacto no desempenho. No CoreDash, navegue até Largest Contentful Paint e veja os resultados por string de consulta.

Em todos os sites monitorados pelo CoreDash, as páginas com parâmetros de rastreamento removidos mostram taxas de acerto de cache de 8 a 15% melhores. Para os visitantes que, de outra forma, receberiam uma falha de cache, isso se traduz em um TTFB de 200 a 500 ms mais rápido.

Se você estiver na Cloudflare e a sua subparte de TTFB de duração de cache estiver alta, a poluição de parâmetros de rastreamento é uma das primeiras coisas a verificar. Combine a remoção de parâmetros com a configuração correta da Cloudflare e você verá uma melhoria mensurável em seus dados de campo.