Optimising Cache Implementation: How to Ignore Marketing Parameters and Save Your Cache

Magento cache optimization becomes critical the moment marketing traffic scales faster than cache rules evolve. Many Magento stores slow down during campaigns, not because of poor infrastructure, but because Magento Full Page Cache (FPC) is unintentionally fragmented by marketing parameters.

UTM tags, GTM identifiers, and platform specific tracking IDs are essential for attribution. But if they’re not handled correctly at the cache layer, they quietly introduce Magento cache pollution, leading to poor cache efficiency and unnecessary server load.

This blog walks through a real production issue where marketing traffic degraded Magento performance and how a small cache rule change fixed it permanently.

Understanding Magento Full Page Cache Issues

Magento Full Page Cache is designed to serve identical pages from cache as efficiently as possible. However, cache keys are generated using the full request URL, including query parameters.

That means URLs like these:

/product/shoes?id=123&utm_source=tiktok&utm_id=abc123

/product/shoes?id=123&utm_source=tiktok&utm_id=xyz456

From a storefront perspective, both pages are identical but from a Magento cache key generation perspective, they are completely different objects. This behaviour is correct by default, but dangerous at scale. When thousands of users arrive via ads, Magento Full Page Cache issues surface quickly if marketing parameters are not explicitly ignored.

What Magento Cache Pollution Looks Like in Production

cache polution

During a high-volume marketing campaign, we observed a single product page generating tens of thousands of unique URLs, all differing only by tracking parameters.

From a cache standpoint, this resulted in:

• Explosive growth in cache entries
• A rapidly declining cache hit ratio in Magento
• Increased requests reaching the origin servers

In one case, over 80,000 cache entries were created for content that should have required fewer than 50.

This is Magento cache pollution in its purest form:

Identical content, fragmented cache, wasted resources.

Why Scaling Servers Doesn’t Solve Cache Problems

The immediate response was predictable, adding more EC2 instances to handle the load. This reduced pressure temporarily, but it didn’t address the real issue.

Magento performance optimization isn’t about brute-force scaling. When cache rules are inefficient:

• More servers just process more cache misses
• Costs increase without improving cache efficiency
• Performance issues resurface during every campaign

Infrastructure scaling can hide cache problems, but it never fixes them.

Detecting Magento Cache Issues Using Observability

The issue didn’t surface through errors or alerts. Everything looked “fine” until we analysed the data closely.

Custom New Relic dashboards revealed:

• Abnormally high cache object counts
• URL patterns dominated by GTM and TikTok parameters
• A steady decline in cache hit ratio during traffic spikes

This made it clear that Magento performance issues during traffic spikes weren’t traffic related at all. Instead, they were cache related. Without observability, this would’ve remained an expensive mystery.

Fixing Cache Key Generation by Ignoring URL Parameters

The solution was conceptually simple:

Exclude non-functional marketing parameters from Magento cache key generation.

This ensures that:

• Tracking continues uninterrupted
• Magento Full Page Cache stores one version of each page
• Marketing parameters no longer fragment the cache

Example:

Without cache rules, Magento sees these as different:

/category/shoes?utm_source=google

/category/shoes?utm_source=facebook

/category/shoes?utm_source=tiktok

With proper rules applied:

/category/shoes

This approach, ignoring URL parameters in Magento cache, is one of the most effective ways to prevent cache pollution.

Implementing Cache Rules in Magento 2 with Fastly

For Magento 2 stores using Fastly, there are two reliable implementation paths.

1: Fastly VCL Configuration

Teams managing custom VCL can filter parameters at the CDN layer:

sub vcl_recv {

if (req.url.qs) {

set req.url = querystring.filter(

req.url,

"utm_source,utm_medium,utm_campaign,utm_term,utm_content,fbclid,gtm_id"

);

}

}

This ensures Magento cache rules ignore parameters that don’t affect page content.

Option 2: Magento Fastly Module Configuration

Most teams don’t need custom VCL.

Magento’s Fastly module allows ignored parameters to be configured directly from the admin panel:

Path:

Stores > Configuration > Advanced > System > Full Page Cache > Fastly Configuration

Here, parameters like utm_source, fbclid, and gtm_id can be excluded safely.

Results: Cache Hit Ratio Recovery and Performance Gains

The impact was immediate and measurable:

• Cache entries dropped from ~80,000 to under 50
• Cache hit ratio in Magento improved dramatically
• Origin server load reduced significantly
• Page speed stabilised across campaigns
• Infrastructure costs stopped escalating

This wasn’t a rewrite or replatform, it was targeted Magento cache optimization done right.

Intelligent Cache Warm-Up with cWarmer

When we think about Magento cache optimization, improving cache hit ratio and preventing pollution are key. But even after fine-tuning cache rules, there’s another performance layer that can make a dramatic impact: cache warming.

Magento’s Full Page Cache works great once pages are populated in cache. But after cache flushes, which happen due to product updates, inventory changes, price changes, or deploys, pages can return to origin until they are warmed again. This can cause slow load times for early users after a flush.

cWarmer is a SaaS-based cache warmer built specifically for Magento 2 that ensures critical pages stay pre-cached and ready to serve. By intelligently monitoring cache state and warming pages automatically, it ensures that visitors see cached content instantly, even after cache invalidations. cWarmer runs outside the Magento instance, so it doesn’t add load to the application server, and it supports warming across contexts like store views, customer groups, and currencies.

With cWarmer, stores benefit from:

• Pages staying in cache even after frequent invalidations
• Faster time-to-first-byte (TTFB) without code changes
• Better user experience and higher conversions
• Improved SEO performance through consistently fast page loads

cWarmer complements the cache rule optimization we’ve discussed earlier, while ignoring irrelevant URL parameters improves how cache keys are generated, cWarmer improves how cache entries are maintained and preloaded. Together, they deliver a more resilient, high-performing Magento experience.