When tracking parameters break your Magento cache

Tracking parameters get plenty of attention in technical SEO, but usually around crawling, duplication, canonicals and attribution. What gets discussed far less is what happens when those same parameters interact badly with the caching layer.

I recently worked through a performance issue where clean URL testing looked healthy, but the real-user data was telling a completely different story. TTFB had climbed above 5 s and LCP had deteriorated at almost exactly the same time, yet testing the normal URLs showed nothing remotely close to that level of slowdown.

The site in question is running Magento with Varnish providing full-page caching and Cloudflare sitting in front. The problem turned out to be a group of advertising, shopping and analytics parameters causing cache misses and forcing Magento to build pages from scratch.

What the field data showed

The first useful signal came from CrUX. Mobile TTFB at p75 had increased from 967 ms to 5.3 s, while LCP had moved from 1.7 s to 5.6 s over the same period.

The increase in LCP was tracking closely with the increase in TTFB, so server response was the obvious place to focus. The strange part was that I could not reproduce anything close to a 5 s TTFB when testing the clean URLs.

Across several templates, clean requests were generally returning in the low hundreds of ms. The site was clearly capable of responding quickly, which meant the difference had to be somewhere between the clean tests and the requests real users were making. Even the crawl stats in Search Console showed a healthy response timings.

The Magento and Varnish setup mattered

This was not just a case of looking at response times and guessing that caching might be involved. Magento was exposing the x-magento-cache-debug response header, so it was possible to see whether individual requests were hitting or missing the full-page cache.

Cloudflare was also in front of the site, but the HTML responses were coming back as DYNAMIC rather than being cached at the edge. That made the Magento/Varnish layer the more interesting part of the stack for this particular investigation.

The next step was therefore to stop testing only the clean URL and start looking at the versions users actually land on.

Testing the parameterised URLs

A lot of ecommerce traffic does not arrive on a perfectly clean canonical URL. Google Ads, Shopping, Microsoft Ads, social platforms, analytics systems and email tools can all append their own tracking parameters.

I tested a selection of those parameters against the same pages and compared TTFB with the Magento cache response. Each first-hit test used a fresh random value, so I was not accidentally requesting a URL that had already been cached.

For the more interesting results, I ran a second first-hit test with another fresh value. I then repeated one of those exact URLs to see how the response changed once that specific parameterised URL had already been requested.

A simplified curl test looked like this:

The important parts were the TTFB and the response headers. On this setup, x-magento-cache-debug provided the HIT or MISS signal I needed alongside the timings.

Worth noting, if the site is challenging your command-line requests through the WAF, I wouldn’t waste time trying to force curl through it. Run the same comparison in a browser or through whatever testing setup gives you a representative request.

The results were pretty clear

Some parameters were already being handled properly by the Varnish configuration. Fresh gclid, UTM, fbclid and mc_cid values continued to return cached responses at around 0.13 to 0.16 s.

Others behaved completely differently. For example:

The wider testing showed the same pattern with params such as gad_source, gad_campaignid, wbraid, msclkid, ttclid, and dclid. Fresh values were producing cache misses with TTFB around 5.3 to 5.8 s.

That was the key finding – a new tracking value could force Magento to build the page, while repeating that exact URL was much faster because a cached version now existed.

Why some parameters were fast and others were not?

The parameters that remained fast lined up closely with those already catered for in the existing Magento/Varnish configuration. Several newer advertising and Shopping parameters did not.

That matters because these parameters were not changing the page content. A category page with an srsltid attached was still the same category page, but the caching layer was effectively treating the request differently. The result was unnecessary page generation for users arriving through those tracked URLs.

This also explains why clean URL testing looked healthy. The clean page was cached and fast, while parts of the real-world traffic were hitting URLs that caused Magento to do considerably more work.

Why this is easy to miss

Most SEO performance testing starts with the canonical URL. Crawlers follow clean internal links, Lighthouse is normally pointed at a clean page and monitoring platforms tend to request the same known URLs repeatedly. That can give you a perfectly valid result without necessarily showing you what some users are experiencing.

Field data is useful here precisely because it reflects those real visits. If CrUX is showing 5 s+ TTFB but your own tests keep coming back at 200 or 300 ms, I would not immediately assume there is something wrong with the field data. I would start looking for what is different about those real requests.

Tracked URLs are one of those differences. It’s not one I come across that often, but it does happen with platforms like Magento / Adobe Commerce.

There is a commercial angle too

This behaviour can disproportionately affect traffic you are actively paying for. Google Ads, Shopping, Microsoft Ads and other campaign traffic are exactly the kinds of visits that arrive with these parameters attached.

You can therefore end up with a user arriving directly on the clean URL and getting a response in a fraction of a second, while somebody clicking a paid campaign waits 5 s+ for the same page to begin responding.

For an ecommerce site, that is not just a Core Web Vitals issue. It is a slower experience being delivered to potentially high-value traffic before the page has even started properly loading. That will hit the conversion rate hard.

The cache miss was only part of the problem

There was another issue underneath all of this. An uncached Magento page taking more than 5 s to generate is slow regardless of how the cache miss happened. One clean URL also took 3.88 s when it hit an expired or purged cache entry, before dropping to 0.14 s on the repeat request.

So I would treat these as two separate things to investigate. The first is why tracking parameters that do not change the page content are creating unnecessary cache misses. The second is why the uncached application response is taking several seconds in the first place.

Improving the Varnish handling reduces how often users hit the slow path. Improving the underlying Magento response makes that slow path less painful when a genuine cache miss does happen.

What I would check after finding this

Once the behaviour is proven, I would review how Magento and Varnish are handling tracking parameters across the site rather than simply fixing the handful found during testing.

The examples are useful because they prove the issue exists, but they should not become an exhaustive list that somebody has to maintain manually forever. The wider question is whether parameters that do not change page content need to form part of the cache behaviour at all.

After any changes, I would run the same tests again using fresh parameter values and confirm that the cache behaviour now matches the clean URL. CrUX and Google Search Console can then be monitored over the following weeks to see whether the field data starts moving back in the right direction.

The takeaway!

The useful part of this investigation was not simply finding a caching issue. It was explaining why the field data and the clean URL tests appeared to contradict each other.

Both were effectively correct. The clean URL was fast, but that was not the URL every user was requesting.

Tracking parameters are already part of the technical SEO conversation, but their impact on caching and real-world performance gets far less attention. If field TTFB looks poor while your clean tests look healthy, testing the URLs users actually land on is a useful place to go next.

Especially if there is Magento and Varnish sitting behind them…