Non marketing query parameter impact

This health check detects 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 cause noticeably worse performance.

Unlike marketing parameters, these parameters are often functional (e.g. filters, pagination, search queries) and may directly affect the response.

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 query parameters for page
Pages with the query parameter "page" are experiencing slower load times compared to requests without parameters.

Why this matters

Non-marketing query parameters are often tied to real functionality, but they can still:

  • Increase Time to First Byte (TTFB)
  • Trigger expensive backend operations
  • Bypass or fragment caching
  • Slow down key user journeys (search, filtering, listing pages)

Because these parameters are user-facing, they often impact high-intent traffic.

How to fix it

Most issues come from:

  • Database-heavy queries (filters, search, sorting)
  • Missing or ineffective caching per parameter value
  • Rendering differences per query string (SSR)
  • Large result sets (e.g. deep pagination)
  • Backend logic branching on query params
  • Cache fragmentation due to too many parameter combinations

Possible causes and fixes:

1. Identify whether the parameter affects content

Before optimizing, determine if the parameter:

  • Changes the response (e.g. ?page=2, ?sort=price)
  • Or is redundant / unused

What to do

  • Remove unused parameters
  • Normalize or redirect if possible

2. Optimize backend performance

If the parameter is required, optimize how it is handled.

What to check

  • Database queries (indexes, query complexity)
  • API response times
  • Server-side rendering cost

What to do

  • Add indexes for filtered fields
  • Reduce payload size
  • Avoid unnecessary joins or computations

3. Improve caching strategy

Unlike marketing params, these often require selective caching.

What to do

  • Cache per parameter value where possible
  • Use cache keys that include only relevant parameters
  • Set appropriate TTLs for dynamic content

Example

Cache:

/products?page=1    
/products?page=2

But avoid:

  • caching irrelevant combinations
  • or disabling caching entirely

4. Limit parameter combinations

Too many combinations can kill cache efficiency.

What to check

  • Free-form filters (e.g. ?q=anything)
  • Multiple stacked parameters (?color=red&size=l&sort=price)

What to do

  • Restrict allowed values
  • Normalize parameter order
  • Consider server-side aggregation or precomputation

5. Avoid duplicate rendering paths

Ensure similar requests reuse work.

What to check

  • SSR frameworks generating unique HTML per query string
  • Edge rendering without caching
  • Lack of shared cache layers

6. Optimize pagination and search

These are common offenders.

What to check

  • Deep pagination (e.g. ?page=100)
  • Inefficient search queries
  • Large result sets

What to do

7. Browser cache considerations

Query parameters often prevent reuse of browser cache.

What to check

  • Same content served under different query strings
  • Navigation paths introducing parameters inconsistently

What to do

  • Normalize URLs where possible
  • Use No-Vary-Search (Chromium-only) where applicable

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. Determine:
    • Does it affect content or not?
  5. Check backend and caching behavior:
    • Query performance
    • Cache hit rate
  6. Apply fixes (optimization, caching, or normalization)
  7. Monitor improvement over the next 7 days

Pro tip

Focus on:

  • Parameters tied to core flows (search, category, filtering)
  • High-traffic pages
  • Mobile traffic (more sensitive to backend latency)

Optimizing a single parameter like search or filter can improve performance across entire user journeys. For better diagnostics, use the Server-Timing header to track server-side processing time.

Table of Contents