Chromium adds No‑Vary‑Search to the HTTP disk cache, enabling query‑param cache deduplication

What happened

• Chromium has extended No‑Vary‑Search support into the HTTP disk cache (now in stable Chrome builds). When a response carries a No‑Vary‑Search header, the browser may reuse a cached disk entry for URLs that only differ in specified query parameters instead of re‑fetching the full resource.

Why this matters for full‑stack teams

• Real page loads are deduplicated. Pages that only differ by analytics/tracking params (utm_*, gclid, fbclid, etc.) can be served from disk cache, significantly speeding navigations and reducing network/CPU cost for users.
• Better prefetch/prerender reuse. Previously prefetch/prerender reuse was limited; disk‑cache awareness lets speculative fetches pay off more often.
• Lower origin/CDN load and latency. Fewer cache misses mean fewer origin hits and fewer revalidations — good for high‑traffic endpoints.
• Behavioral risk for client‑heavy pages. If your single‑page app or client rendering relies on search params being present on first paint, prerendered or cached responses served under No‑Vary‑Search may initially expose a different URL/params in location.href until activation — you must ensure client code updates on activation.

Immediate, practical checklist (high‑impact steps)

1. Audit query parameters
   • Inventory all query parameters your app receives. Classify as: (a) server‑affecting (must vary cache), (b) client‑only (safe to ignore), (c) unpredictable/unsafe.
2. Start with a conservative header
   • Use explicit params: No‑Vary‑Search: params=("utm_source" "utm_medium" "utm_campaign" "fbclid" "gclid")
   • Or use key‑order or other variants only if you fully understand server behavior.
3. Add header at the origin (or CDN edge)
   • Examples (conceptual):
     • Express: res.setHeader('No‑Vary‑Search', 'params=("utm_source" "utm_medium")')
     • Nginx (add_header) / CDN custom header rules
   • Prefer edge/CDN configuration to avoid origin changes wherever possible.
4. Test thoroughly before wide rollout
   • Verify served resource is identical for URLs that differ only in ignored params.
   • Test prerender/prefetch and navigation flows: ensure client‑side logic that depends on URL params runs after activation (or re‑reads params).
   • Confirm analytics instrumentation still captures the right final URL/params (activation may change location).
5. Monitor cache and origin metrics
   • Track cache hit ratio, origin request rate, and any cache‑related 304/validation traffic after deployment.
6. Consider CDN and intermediary behavior
   • Not all CDNs or intermediaries understand No‑Vary‑Search yet. If you rely on downstream caches, coordinate with CDN support or use origin/edge headers cautiously.
7. Rollout strategy
   • Canary the header for a subset of users or paths, and ramp once metrics validate expected behavior.

Testing tips

• DevTools network panel: perform loads with different query params and inspect “Disk cache” as the resource source.
• Reproduce prerender/use speculation rules if you rely on prefetching: ensure activation produces correct application state.
• Use server logs to confirm identical responses and to detect accidental reuse of truly variant content.

Risks and gotchas

• Incorrectly marking a parameter as ignorable can serve wrong content (especially for pages where query parameters alter server response).
• Client hydration timing: client code that reads search parameters at initial paint may run before activation when a prerendered/cached page is reused — update code to handle activation events and re‑read params where necessary.
• Browser coverage: currently this behavior is implemented in Chromium browsers; other browsers may behave differently. Do not assume universal behavior without checking browser support for your audience.

Bottom line No‑Vary‑Search moving into the HTTP disk cache is a practical, high‑leverage change: when used conservatively it reduces redundant downloads and improves performance for real users. Treat it as an origin/CDN/engineering rollout item — inventory params, test client behavior around prerender/activation, and ramp progressively.

Source: Chrome release notes — Chrome 141: No‑Vary‑Search support for the HTTP disk cache.