Improving browser caching with No-Vary-Search 🚀
No-Vary-Search avoids cache fragmentation from URL parameters: examples, browser support and debugging caveats.
Every frontend developer knows the pain: you have configured Cache-Control perfectly, then a marketer comes along, adds a pile of UTM tags or fbclid to a link, and the browser treats that URL as a completely new resource. The cache goes to waste, the page loads more slowly, and identical entries multiply on the server.
You can solve this on the CDN side or through a Service Worker, but it is time-consuming and full of workarounds. Web standards finally have a native solution to the problem: the No-Vary-Search response header.
💡 What is it?
It is an HTTP response header that explicitly tells the browser and other caches: “Hey, these URL parameters do not affect the page content at all. Ignore them when looking in the cache.”
If a user visits site.com/page?utm_source=tg, the browser saves it. The next time the user follows a link to site.com/page?utm_source=email, the browser does not go to the network, but serves the page instantly from its local cache because the content is identical.
🛠 How do you write it? Examples
The header uses Structured Fields syntax and gives you flexible control:
1️⃣ Ignore only specific parameters, the most common use case:
No-Vary-Search: params=("utm_source" "utm_medium" "utm_campaign" "fbclid")The content at links with these tags shares a single cache slot, but if something like ?product_id=123 changes, the cache entries remain separate.
2️⃣ Ignore absolutely all parameters:
No-Vary-Search: params3️⃣ Ignore everything EXCEPT the important parameters:
No-Vary-Search: params, except=("id" "page")Handy when there are many parameters, but only the product ID and pagination affect rendering.
4️⃣ Ignore parameter order:
No-Vary-Search: key-orderIf the backend does not care what order the query parameters appear in, ?a=1&b=2 or ?b=2&a=1, this flag saves you unnecessary cache misses.
🚦 Standards status and support
At the moment, in mid-2026, the IETF specification is a draft, and the header itself is considered experimental.
Chromium browsers: Chrome, Edge and Opera: already have excellent support. They use No-Vary-Search not only for the standard disk cache, but also for the Speculation Rules API: they parse the header to reuse pages that have already been prefetched or prerendered, even when the parameters do not match.
Safari and Firefox: are still behind, but the feature is being actively discussed in the context of Interop.
⚠️ A small debugging catch: if you deploy this header to production, the good old cache-busting trick of site.com/script.js?v=random_string stops working if that parameter falls under the ignore rule. Be careful.
You can adopt it right now as progressive enhancement: Chromium users get an immediate speed boost, while everyone else simply follows the old path.
How do you currently deal with cache fragmentation caused by trackers? Strip tags through a Service Worker, configure rules in Cloudflare/Nginx, or just live with it for now? 👇