Core/Dash Dimension: Query String

What the Query String dimension captures

The Query String dimension groups your Core Web Vitals data by the full query string present in the URL at the time of the page visit. That includes everything after the ?: tracking parameters like utm_source=google, pagination like page=2, sort orders like sort=price, search queries like q=running+shoes, A/B test variants, and filter combinations.

Most performance monitoring tools strip query strings or collapse them into a single URL group. CoreDash keeps them intact, which means you can compare the LCP, INP, and CLS of /products?sort=price against /products?sort=popularity on the same page template, with the same users, across the same time period.

Why query strings cause performance regressions

Query parameters are one of the most common sources of unexplained performance variance. Here is why they matter:

CDN caching behavior

By default, most CDNs treat URLs with different query strings as separate cache entries. /search?q=boots and /search?q=sandals are two distinct cache keys. If your search results page generates hundreds of unique queries per hour, almost none of those requests will be served from cache. Every visitor hits your origin server cold.

Some CDNs let you ignore specific parameters (like UTM tags) in the cache key, but that configuration is easy to miss. If utm_source=email is included in your cache key, your email campaign landing page will have a near-zero cache hit rate, and every recipient gets a full server render instead of a cached response. That is a common and measurable LCP spike.

Server-side rendering cost

Filter and sort parameters often trigger the most expensive database queries on a page. A plain product listing at /products might be fully cached. The same page at /products?color=red&size=M&brand=Nike&sort=price-asc may require a complex query, a different response shape, or even a complete re-render. On pages that cannot cache filtered results efficiently, the time to first byte increases, and LCP follows it.

Pagination is another consistent offender. Page 1 of a listing is usually fast because it is the default view and gets cached aggressively. Page 10 or page 50 is rarely cached, often slower to generate, and frequently never tested. CoreDash surfaces these differences directly, without requiring you to guess.

Client-side behavior triggered by parameters

Some query parameters do not change the server response but do change what JavaScript runs on load. A/B test variant parameters, affiliate tracking codes, and referral tokens are frequently read by scripts that initialize different UI flows, fire additional network requests, or delay rendering while waiting for experiment configuration. These parameters can add measurable INP cost and occasionally cause layout shifts if the variant changes visible content after initial paint.

Common patterns worth investigating

• UTM parameters on paid traffic: Visitors from ads often land with ?utm_source=google&utm_medium=cpc&utm_campaign=.... If your CDN includes these in its cache key, paid traffic consistently gets slower responses than organic traffic.
• Search result pages: Short, popular queries may be cached. Long-tail or first-time queries almost never are. Comparing ?q=nike against ?q=blue+trail+running+shoes+mens+size+11 often shows a measurable LCP difference.
• Heavy filter combinations: E-commerce category pages with multiple active filters are expensive to render and rarely cached. If your 75th percentile LCP is high, filter combinations are a likely contributor.
• Pagination beyond page 1: Page 2 and beyond are usually slower and more resource-intensive. They also often contain the same hero image or layout but without the benefit of cached assets from a previous visit.

How to use this dimension in CoreDash

Select Query String from the dimension picker in any CoreDash report. The table will show each unique query string alongside its LCP, INP, CLS, and visit count. Sort by LCP to find the slowest parameter combinations, or sort by visit count to find the highest-traffic variants.

Pair this dimension with the URL dimension to narrow your analysis to a single page template before comparing its query string variants. That combination makes it easy to confirm whether a performance problem is in the page itself or in a specific parameter pattern.

The Query String dimension falls under the Page & Navigation category in CoreDash, alongside dimensions like URL, Pathname, and Navigation Type.