Rimuovi i parametri di tracciamento con Cloudflare Workers e Transform Rules

Perché i parametri di tracciamento distruggono il tuo cache hit rate

I parametri di tracciamento come utm_source, gclid e fbclid aiutano i marketer a misurare le prestazioni delle campagne. Per i Core Web Vitals sono un incubo perché interrompono il caching. Ogni URL univoco crea una voce di cache separata. Una singola pagina condivisa su Facebook ottiene un fbclid univoco per ogni clic, il che significa che ogni visitatore proveniente da Facebook ottiene un cache miss e un Time to First Byte lento.

Cloudflare ti offre tre modi per rimuovere questi parametri all'edge prima che inquinino la tua cache: Transform Rules (nessun codice), Workers (controllo completo) e personalizzazione della Cache Key (Enterprise). Li tratterò tutti e tre.

Ultima revisione di Arjen Karel a marzo 2026

Il problema di caching con i parametri di tracciamento

I sistemi di caching utilizzano l'URL completo come cache key. Se un URL include ?utm_source=google o ?fbclid=abc123, la cache lo tratta come una pagina diversa, anche se il contenuto è identico. Questo è un cache miss. Il server ricostruisce una pagina che ha già in cache, solo perché l'URL ha un valore di query string diverso.

La portata di questo problema è più grande di quanto la maggior parte delle persone realizzi. Ci sono 129 parametri di tracciamento noti nell'ecosistema del marketing. Il parametro fbclid è il più distruttivo perché Facebook lo aggiunge a ogni clic su un link in uscita, non solo agli annunci a pagamento. Ogni condivisione organica, ogni link in un commento, ogni post che linka al tuo sito ottiene un valore fbclid univoco.

Secondo il Web Almanac 2025, solo il 44% delle origin mobile ha un buon TTFB. Cloudflare ha riportato che la correzione del comportamento di caching delle query string ha migliorato i cache hit rate in media del 3% e ha ridotto i byte dell'origin del 5%. Questo si traduce direttamente in un Largest Contentful Paint più veloce per i tuoi visitatori.

Non tutti i parametri di query sono spazzatura di tracciamento. Parametri come ?q=laptops o ?color=blue cambiano il contenuto della pagina. L'obiettivo è rimuovere i parametri che non influiscono sul contenuto mantenendo quelli che lo fanno.

Quali parametri di tracciamento dovresti rimuovere?

Ecco i parametri di tracciamento più comuni raggruppati per piattaforma. Questi creano URL univoci e non memorizzabili in cache senza modificare il contenuto della pagina:

Questa non è la lista completa. Il registro dei parametri di query di tracciamento documenta tutti i 129 parametri noti. Per la maggior parte dei siti, coprire i parametri di Google, Meta e Microsoft risolve il 95% del problema.

Opzione 1: Transform Rules (nessun codice richiesto)

Cloudflare ha una funzione integrata chiamata remove_query_args() che rimuove specifici parametri di query dall'URL prima che raggiunga la cache. Questa viene eseguita come Transform Rule, non richiede codice ed è disponibile su tutti i piani incluso il livello gratuito.

Per configurarlo:

1. Nella tua dashboard di Cloudflare, vai su Rules poi su Transform Rules e quindi su URL Rewrite
2. Crea una nuova regola
3. Imposta il filtro in modo che corrisponda al tuo dominio, ad esempio (http.host eq "example.com")
4. Per Query, seleziona Rewrite to e poi Dynamic
5. Inserisci l'espressione:
   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. Per Path, seleziona Preserve

Questo è tutto. Nessun Worker, nessun deployment di codice. Il piano gratuito consente 10 Transform Rules, il Pro ne consente 25. Per la maggior parte dei siti questa è l'opzione migliore.

Opzione 2: Cloudflare Workers

Cloudflare ha opzioni pronte all'uso per ignorare le query string, ma le loro impostazioni conservative non sono sufficienti per ottenere il massimo dal tuo piano Cloudflare. Se hai bisogno di più controllo rispetto a quanto offerto dalle Transform Rules (ad esempio, corrispondenza regex, logica condizionale o logging), un Cloudflare Worker ti offre la massima flessibilità.

I Workers intercettano le richieste all'edge ed eseguono il tuo codice prima che la richiesta colpisca la cache o l'origin. Cloudflare carica i Workers durante l'handshake TLS, quindi l'overhead effettivo è inferiore a 1 millisecondo.

Il codice

Di seguito è riportato lo script completo del Worker che utilizza l'attuale sintassi dei moduli 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])/

    // Collect matching keys first (do not delete during iteration)
    const keysToDelete = [...url.searchParams.keys()].filter(
      key => trackingParams.test(key)
    )

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

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

Il Worker analizza l'URL, verifica ogni parametro di query con una regex e rimuove le corrispondenze. L'URL pulito va quindi alla cache e all'origin. Qui sono importanti due dettagli: il codice raccoglie le chiavi in un array prima di eliminarle, perché l'eliminazione durante l'iterazione di URLSearchParams può saltare delle voci (questo è un problema noto delle specifiche con i live iterator). Inoltre, lo script utilizza il formato dei moduli ES (export default) perché Cloudflare ha deprecato la vecchia sintassi addEventListener.

Deployment

1. Accedi a Cloudflare. Accedi alla tua dashboard di Cloudflare.
2. Crea un Worker. Non navigare ancora sul tuo sito. Vai alla sezione Workers e crea un nuovo Worker.
   
3. Dai un nome al worker ed effettua il deploy. Questo passaggio potrebbe sembrare un po' controintuitivo ma non preoccuparti. Dai semplicemente un nome al tuo worker vuoto 'hello world' e clicca su deploy.
   
4. Modifica il tuo worker. Nella pagina successiva clicca su Edit Code.
   
5. Incolla lo script. Copia e incolla lo script precedente nell'editor. Quindi clicca su deploy.
   
6. Associa il Worker a una route. Ora torna indietro e naviga sul tuo sito in Cloudflare. Clicca su worker routes e poi su 'Add Route'. Seleziona il worker appena creato e applicalo al tuo sito.
   

Personalizzazione

Puoi modificare la regex per includere o escludere parametri specifici. Se vuoi preservare determinati parametri utm_ per l'elaborazione lato server, rimuovili dalla regex. Se utilizzi una piattaforma di marketing non coperta dalla regex predefinita, aggiungi i suoi parametri.

Opzione 3: Personalizzazione della Cache Key (Enterprise)

Se hai un piano Cloudflare Enterprise, puoi configurare delle custom cache keys per escludere parametri di query specifici senza rimuoverli affatto dall'URL. La cache semplicemente li ignora durante il calcolo della chiave. Questo è l'approccio più pulito perché l'URL rimane invariato, ma richiede un piano Enterprise.

Per i piani non Enterprise, l'approccio tramite Transform Rule o Worker ottiene lo stesso vantaggio per la cache.

Quale approccio dovresti usare?

Per la maggior parte dei siti, inizia con le Transform Rules. Se raggiungi il limite di regole o hai bisogno di maggiore flessibilità, passa ai Workers.

Se usi WordPress con Cloudflare APO, potresti non aver bisogno di nulla di tutto questo. APO mantiene una allowlist di oltre 25 parametri di marketing che ignora durante il calcolo delle cache keys. Verifica se i tuoi parametri specifici sono coperti prima di aggiungere un Worker o una Transform Rule.

La rimozione dei parametri danneggia le analisi?

No. La rimozione avviene all'edge, tra la CDN e il tuo origin server. L'URL nel browser contiene ancora i parametri di tracciamento originali. Google Analytics, il monitoraggio delle conversioni di Google Ads e il pixel di Facebook leggono tutti da document.location lato client, che ha ancora l'URL completo con tutti i parametri intatti.

L'unico scenario in cui questo potrebbe causare problemi è se il tuo codice lato server legge i parametri di tracciamento dall'URL (ad esempio, un'implementazione di analytics lato server). In quel caso, escludi quei parametri dalla rimozione o catturali in un request header prima che il Worker li rimuova.

Per uno sguardo più ampio su come gli script di tracciamento e analytics influiscono sulle prestazioni oltre al caching, vedi The Case for Limiting Analytics and Tracking Scripts.

Come scoprire quali parametri dell'URL rimuovere

Scoprire quali parametri dell'URL rimuovere è facile se usi lo strumento giusto. I tool di Real User Monitoring come CoreDash monitorano il tuo sito 24/7 e registrano tutte le query string insieme al loro impatto sulle prestazioni. In CoreDash, vai su Largest Contentful Paint e visualizza i risultati per query string.

Nei siti monitorati da CoreDash, le pagine con parametri di tracciamento rimossi mostrano cache hit rate migliori di circa l'8-15%. Per i visitatori che altrimenti otterrebbero un cache miss, questo si traduce in un TTFB più veloce di 200-500 ms.

Se usi Cloudflare e la sub-part del TTFB relativa alla durata della cache è alta, l'inquinamento da parametri di tracciamento è una delle prime cose da controllare. Combina la rimozione dei parametri con la giusta configurazione di Cloudflare e vedrai un miglioramento misurabile nei tuoi dati sul campo.