Улучшаем кэширование в браузере с помощью No-Vary-Search 🚀
Заголовок No-Vary-Search помогает избежать фрагментации кэша из-за URL-параметров: примеры, поддержка и нюансы отладки.
Каждый фронтендер знает боль: вы идеально настроили Cache-Control, но прилетает маркетолог, добавляет к ссылке кучу UTM-меток или fbclid, и браузер считает этот URL совершенно новым ресурсом. Кэш сгорает, страница грузится дольше, а на сервере множатся одинаковые записи.
Решать это на стороне CDN или через Service Worker можно, но долго и костыльно. Наконец-то в веб-стандартах появилось нативное решение проблемы — заголовок ответа No-Vary-Search.
💡 Что это такое?
Это HTTP-заголовок ответа, который явно говорит браузеру (и другим кэшам): «Эй, вот эти параметры в URL никак не влияют на контент страницы. Игнорируй их при поиске в кэше».
Если пользователь зашёл на site.com/page?utm_source=tg, браузер сохранит её. Когда в следующий раз пользователь перейдёт по ссылке site.com/page?utm_source=email, браузер не пойдёт в сеть, а моментально отдаст страницу из локального кэша, потому что контент идентичен.
🛠 Как это пишется? (Примеры)
Заголовок использует синтаксис Structured Fields и даёт гибкий контроль:
1️⃣ Игнорировать только конкретные параметры (самый частый кейс):
No-Vary-Search: params=("utm_source" "utm_medium" "utm_campaign" "fbclid")Контент по ссылкам с этими метками склеится в один кэш-слот, но если изменится условный ?product_id=123, кэш разделится.
2️⃣ Игнорировать вообще все параметры:
No-Vary-Search: params3️⃣ Игнорировать всё, КРОМЕ важных параметров:
No-Vary-Search: params, except=("id" "page")Удобно, если параметров много, но на рендеринг влияют только ID товара и пагинация.
4️⃣ Игнорировать порядок параметров:
No-Vary-Search: key-orderЕсли бэкенду всё равно, в каком порядке идут query-параметры (?a=1&b=2 или ?b=2&a=1), этот флаг спасёт от лишних cache miss.
🚦 Статус в стандартах и поддержка
На текущий момент (середина 2026 года) спецификация IETF находится в статусе черновика (Draft), а сам заголовок считается экспериментальным.
Chromium-браузеры (Chrome, Edge, Opera): Уже имеют отличную поддержку. Они используют No-Vary-Search не только для стандартного дискового кэша, но и для Speculation Rules API (парсят заголовок, чтобы переиспользовать уже предзагруженные (prefetiched/prerendered) страницы, даже если параметры не совпали).
Safari и Firefox: Пока отстают, но фича активно обсуждается в контексте Interop.
⚠️ Небольшой подвох при дебаге: Если вы внедрите этот заголовок на проде, старый добрый трюк для сброса кэша вида site.com/script.js?v=random_string перестанет работать, если этот параметр попадет под правило игнорирования. Будьте аккуратны.
Внедрять можно уже сейчас как progressive enhancement — Chromium-пользователи получат мгновенный буст к скорости, а остальные просто пойдут по старому пути.
А как вы сейчас боретесь с фрагментацией кэша из-за трекеров? Вырезаете метки через Service Worker, настраиваете правила на Cloudflare/Nginx или пока просто смирились? 👇