Supprimer les paramètres de suivi avec Cloudflare Workers et Transform Rules

Pourquoi les paramètres de suivi détruisent votre taux de réussite de cache

Les paramètres de suivi comme utm_source, gclid et fbclid aident les spécialistes du marketing à mesurer les performances des campagnes. Pour les Core Web Vitals, ils sont un cauchemar car ils cassent la mise en cache. Chaque URL unique crée une entrée de cache distincte. Une seule page partagée sur Facebook obtient un fbclid unique pour chaque clic, ce qui signifie que chaque visiteur provenant de Facebook subit un échec de cache et un Time to First Byte lent.

Cloudflare vous offre trois moyens de supprimer ces paramètres à la périphérie (edge) avant qu'ils ne polluent votre cache : les Transform Rules (sans code), les Workers (contrôle total) et la personnalisation de la Cache Key (Enterprise). Je vais couvrir les trois.

Dernière révision par Arjen Karel en mars 2026

Le problème de mise en cache avec les paramètres de suivi

Les systèmes de mise en cache utilisent l'URL complète comme clé de cache. Si une URL inclut ?utm_source=google ou ?fbclid=abc123, le cache la traite comme une page différente, même si le contenu est identique. Il s'agit d'un échec de cache. Le serveur reconstruit une page qu'il a déjà mise en cache, simplement parce que l'URL a une valeur de chaîne de requête différente.

L'ampleur de ce problème est plus grande que la plupart des gens ne le réalisent. Il existe 129 paramètres de suivi connus dans l'écosystème du marketing. Le paramètre fbclid est le plus destructeur car Facebook l'ajoute à chaque clic sur un lien sortant, et non pas seulement aux publicités payantes. Chaque partage organique, chaque lien dans un commentaire, chaque publication qui pointe vers votre site obtient une valeur fbclid unique.

Selon le Web Almanac 2025, seulement 44 % des origines mobiles ont un bon TTFB. Cloudflare a signalé que la correction du comportement de mise en cache des chaînes de requête a amélioré les taux de réussite de cache de 3 % en moyenne et réduit les octets d'origine de 5 %. Cela se traduit directement par un Largest Contentful Paint plus rapide pour vos visiteurs.

Tous les paramètres de requête ne sont pas des déchets de suivi. Les paramètres comme ?q=laptops ou ?color=blue modifient le contenu de la page. L'objectif est de supprimer les paramètres qui n'affectent pas le contenu tout en conservant ceux qui le font.

Quels paramètres de suivi devez-vous supprimer ?

Voici les paramètres de suivi les plus courants regroupés par plateforme. Ceux-ci créent des URL uniques et non mémorisables en cache sans modifier le contenu de la page :

Il ne s'agit pas de la liste complète. Le registre des paramètres de requête de suivi documente l'ensemble des 129 paramètres connus. Pour la plupart des sites, couvrir les paramètres de Google, Meta et Microsoft résout 95 % du problème.

Option 1 : Transform Rules (aucun code requis)

Cloudflare possède une fonction intégrée appelée remove_query_args() qui supprime des paramètres de requête spécifiques de l'URL avant qu'elle n'atteigne le cache. Cela s'exécute en tant que Transform Rule, ne nécessite aucun code et est disponible sur tous les forfaits, y compris le niveau gratuit.

Pour configurer cela :

1. Dans votre tableau de bord Cloudflare, allez dans Rules puis Transform Rules puis URL Rewrite
2. Créez une nouvelle règle
3. Définissez le filtre pour qu'il corresponde à votre domaine, par exemple (http.host eq "example.com")
4. Pour Query, sélectionnez Rewrite to puis Dynamic
5. Saisissez l'expression :
   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. Pour Path, sélectionnez Preserve

C'est tout. Aucun Worker, aucun déploiement de code. Le forfait gratuit autorise 10 Transform Rules, le forfait Pro en autorise 25. Pour la plupart des sites, c'est la meilleure option.

Option 2 : Cloudflare Workers

Cloudflare dispose d'options prêtes à l'emploi pour ignorer les chaînes de requête, mais leurs paramètres conservateurs ne suffisent pas pour tirer le meilleur parti de votre forfait Cloudflare. Si vous avez besoin de plus de contrôle que ce qu'offrent les Transform Rules (par exemple, la correspondance par expression régulière, la logique conditionnelle ou la journalisation), un Cloudflare Worker vous offre une flexibilité totale.

Les Workers interceptent les requêtes à la périphérie (edge) et exécutent votre code avant que la requête n'atteigne le cache ou l'origine. Cloudflare charge les Workers pendant le handshake TLS, de sorte que la surcharge effective est inférieure à 1 milliseconde.

Le code

Vous trouverez ci-dessous le script complet du Worker utilisant la syntaxe actuelle des modules 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])/

    // Collecter d'abord les clés correspondantes (ne pas supprimer pendant l'itération)
    const keysToDelete = [...url.searchParams.keys()].filter(
      key => trackingParams.test(key)
    )

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

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

Le Worker analyse l'URL, teste chaque paramètre de requête par rapport à une expression régulière (regex) et supprime les correspondances. L'URL propre va ensuite vers le cache et l'origine. Deux détails ont leur importance ici : le code rassemble les clés dans un tableau avant de les supprimer, car la suppression pendant l'itération de URLSearchParams peut sauter des entrées (il s'agit d'un problème de spécification connu avec les itérateurs en direct). Et le script utilise le format des modules ES (export default) car Cloudflare a déprécié l'ancienne syntaxe addEventListener.

Déploiement

1. Connectez-vous à Cloudflare. Connectez-vous à votre tableau de bord Cloudflare.
2. Créez un Worker. Ne naviguez pas encore vers votre site. Accédez à la section Workers et créez un nouveau Worker.
   
3. Nommez le worker et déployez-le. Cette étape peut sembler un peu contre-intuitive, mais ne vous inquiétez pas. Nommez simplement votre worker vide 'hello world' et cliquez sur déployer.
   
4. Modifiez votre worker. Sur la page suivante, cliquez sur Edit Code.
   
5. Collez le script. Copiez et collez le script ci-dessus dans l'éditeur. Cliquez ensuite sur déployer.
   
6. Liez le Worker à une route. Revenez maintenant en arrière et accédez à votre site dans Cloudflare. Cliquez sur worker routes puis sur 'Add Route'. Sélectionnez le worker nouvellement créé et appliquez-le à votre site.
   

Personnalisation

Vous pouvez modifier la regex pour inclure ou exclure des paramètres spécifiques. Si vous souhaitez conserver certains paramètres utm_ pour un traitement côté serveur, supprimez-les de la regex. Si vous utilisez une plateforme marketing non couverte par la regex par défaut, ajoutez ses paramètres.

Option 3 : Personnalisation de la Cache Key (Enterprise)

Si vous possédez un forfait Cloudflare Enterprise, vous pouvez configurer des clés de cache personnalisées pour exclure des paramètres de requête spécifiques sans les supprimer de l'URL. Le cache les ignore simplement lors du calcul de la clé. C'est l'approche la plus propre car l'URL reste inchangée, mais elle nécessite le forfait Enterprise.

Pour les forfaits non-Enterprise, l'approche Transform Rule ou Worker offre les mêmes avantages pour le cache.

Quelle approche devez-vous utiliser ?

Pour la plupart des sites, commencez avec les Transform Rules. Si vous atteignez la limite de règles ou si vous avez besoin de plus de flexibilité, passez aux Workers.

Si vous utilisez WordPress avec Cloudflare APO, vous n'aurez peut-être besoin de rien de tout cela. APO maintient une liste blanche de plus de 25 paramètres marketing qu'il ignore lors du calcul des clés de cache. Vérifiez si vos paramètres spécifiques sont couverts avant d'ajouter un Worker ou une Transform Rule.

La suppression des paramètres casse-t-elle l'analyse de données (analytics) ?

Non. La suppression s'effectue à la périphérie (edge), entre le CDN et votre serveur d'origine. L'URL du navigateur contient toujours les paramètres de suivi d'origine. Google Analytics, le suivi des conversions Google Ads et le pixel de Facebook lisent tous à partir de document.location côté client, qui conserve l'URL complète avec tous ses paramètres intacts.

Le seul scénario où cela pourrait causer des problèmes est si votre code côté serveur lit les paramètres de suivi depuis l'URL (par exemple, une implémentation d'analyse côté serveur). Dans ce cas, vous devez soit exclure ces paramètres de la suppression, soit les capturer dans un en-tête de requête avant que le Worker ne les supprime.

Pour un aperçu plus large de la manière dont les scripts de suivi et d'analyse affectent les performances au-delà de la mise en cache, consultez L'argument en faveur de la limitation des scripts d'analyse et de suivi.

Comment trouver quels paramètres d'URL supprimer

Il est facile de découvrir quels paramètres d'URL supprimer si vous utilisez le bon outil. Les outils de Real User Monitoring comme CoreDash surveillent votre site 24h/24 et 7j/7 et journalisent toutes les chaînes de requête ainsi que leur impact sur les performances. Dans CoreDash, accédez à Largest Contentful Paint et affichez les résultats par chaîne de requête.

Sur l'ensemble des sites surveillés par CoreDash, les pages dont les paramètres de suivi ont été supprimés affichent des taux de réussite de cache d'environ 8 à 15 % supérieurs. Pour les visiteurs qui auraient autrement subi un échec de cache, cela se traduit par un TTFB plus rapide de 200 à 500 ms.

Si vous êtes sur Cloudflare et que la sous-partie TTFB de la durée du cache est élevée, la pollution par les paramètres de suivi est l'une des premières choses à vérifier. Combinez la suppression des paramètres avec la bonne configuration de Cloudflare et vous constaterez une amélioration mesurable de vos données de terrain.