Marketing query parameter impact

This health check detects marketing query parameters that significantly slow down requests based on real user data.

It compares requests with and without specific query parameters and flags cases where parameters (e.g. utm_*, gclid, fbclid) cause noticeably worse performance.

Each todo represents a single query parameter that is associated with slower responses.

About this check

When this check is triggered

You’ll see this check when:

  • A query parameter consistently increases response time (TTFB)
  • The impact is visible in real user data (p75)
  • There are enough events to validate the pattern
  • Requests with the parameter are significantly slower than those without it

What you’ll see

Each todo includes:

  • Query parameter
  • Performance impact compared to requests without parameters
  • Based on real user sessions

Example:

Investigate slow marketing query parameters for utm_campaign
Pages with the marketing query parameter "utm_campaign" are experiencing slower load times compared to requests without parameters.

Why this matters

Marketing parameters are often appended to URLs for tracking, but they can unintentionally:

  • Break caching (CDN or server)
  • Trigger unnecessary backend logic
  • Increase Time to First Byte (TTFB)

This leads to slower page loads for a large portion of traffic, especially from campaigns.

How to fix it

Most issues come from:

  • Cache misses due to unique query strings
  • Backend logic triggered by parameters
  • Personalization or tracking logic executed server-side
  • CDN not configured to ignore marketing parameters
  • Duplicate cache entries per parameter variation
  • Newly introduced parameter keys (like srsltid) by third parties

Possible causes and fixes:

1. Ignore marketing parameters in caching

Ensure tracking parameters do not create separate cache entries.

What to do

  • Configure CDN to ignore query parameters like:
  • utm_source, utm_medium, utm_campaign
  • gclid, fbclid (and other ad-related query string keys)
  • Use cache key normalization

Example (conceptual)

Instead of:

/page?utm_source=google
  /page?utm_source=linkedin

Cache as:

/page

2. Prevent backend processing of tracking parameters

Marketing parameters should not trigger heavy logic.

What to check

  • Avoid parsing query params unnecessarily in controllers
  • Do not trigger database queries based on tracking params
  • Strip parameters early in the request lifecycle if not needed

3. Normalize URLs early

Handle parameters before they reach expensive parts of your stack.

What to do

  • Redirect to a clean URL (optional, depends on tracking needs)
  • Or internally normalize request handling

4. Improve CDN configuration

Many regressions are caused at the CDN layer.

What to check

  • Cache key settings
  • Query string handling (ignore vs include)
  • Edge caching rules

5. Avoid duplicate rendering paths

Different query params should not create different HTML responses unless required.

What to check

  • SSR frameworks rendering unique pages per query string
  • Static generation fallback behavior
  • Cache fragmentation in edge functions

6. Browser cache

Allow pages to come from browser cache, even when query strings are suddenly involved

What to check

  • Prefetched and prerendered pages without query strings, while actually clicked links do include query string keys
  • Visitors landing on homepage from ads, and clicking on the logo which does not contain query string keys
  • Both pagehits could be served from cache with No-Vary-Search response header (Chromium-only)

Further debugging

How to approach this in RUMvision

  1. Open the todo
  2. Identify the query parameter
  3. Compare:
    • Requests with the parameter
    • Requests without the parameter
  4. Check caching behavior:
    • CDN cache hit rate
    • Server response time
  5. Apply fixes (usually caching or normalization)
  6. Monitor improvement over the next 7 days

Pro tip

Focus on:

  • High-traffic parameters (e.g. utm_campaign, gclid)
  • Landing pages from paid campaigns
  • Mobile traffic (often more sensitive to TTFB)

Fixing one parameter at CDN level can improve performance across all campaign traffic instantly.

Table of Contents