Ваша стратегия кэширования — это прямой сигнал для AI-краулеров

Ваша стратегия кэширования — это прямой сигнал для AI-краулеров

Гайз, эффективное HTTP-кэширование — это уже не просто фича для перфоманса, а критический элемент инфраструктуры, который напрямую влияет на эффективность краулинга и то, как ваш сайт воспринимают и поисковики, и современные AI-системы.

Боты ведут себя не так агрессивно, когда видят правильно настроенные хидеры кэширования, что экономит ваш краулинговый бюджет и позволяет им обходить более свежий и глубокий контент.

Кривые настройки, однако, могут привести к жесткой просадке производительности и сливу ресурсов краулера.

Одна из самых губительных ошибок — неправильное использование хидера Vary.

Если включать в него заголовки, которые по факту не меняют ответ, типа Vary: User-Agent или Vary: Cookie, это приводит к катастрофической фрагментации кэша.

В результате создаются тысячи почти одинаковых записей в кэше, что просто убивает hit rate.

Для адаптивных изображений нужно юзать Vary с Client Hints вроде DPR и Width, но это надо делать в связке с правилами CDN, чтобы нормализовать варианты и избежать фрагментации.

Чтобы побороть фрагментацию от трекинговых параметров, есть экспериментальный хидер No-Vary-Search, который говорит кэшу игнорировать параметры типа utm_source или fbclid при создании ключей кэша.

Вы обязаны разделять время жизни кэша для браузера и для CDN.

Используйте директиву s-maxage, чтобы задать долгий срок кэширования для общих кэшей, как ваш CDN, и при этом ставьте куда более короткий max-age для браузеров.

Например, Cache-Control: public, max-age=60, s-maxage=600 говорит браузеру перепроверить через минуту, но позволяет CDN отдавать свою кэшированную копию десять минут, защищая ваш основной сервер.

Применяйте стратегию кэширования в зависимости от типа контента:

— `HTML` с редкими изменениями (посты в блоге): Юзайте длинный TTL для CDN (s-maxage=86400) в паре со стратегией очистки кэша по событию. Когда контент обновляется, используйте фичи CDN типа Cache Tags или surrogate keys, чтобы мгновенно сбросить кэш для нужных страниц.

— `HTML` с частыми изменениями (главная): Ставьте TTL для CDN покороче (s-maxage=300) с stale-while-revalidate=60, чтобы обеспечить быстрый отклик для юзера, пока апдейты подтягиваются в фоне.

— Страницы, требующие аутентификации: Используйте Cache-Control: private, no-cache с ETag, чтобы запретить общее кэширование, но разрешить эффективную повторную валидацию с ответом 304 Not Modified. Для особо чувствительных данных юзайте private, no-store, чтобы браузер вообще не хранил копию на диске.

— Ресурсы с версионированием (Fingerprinted Assets): Директиву immutable следует использовать только для ресурсов с версиями в именах файлов (например, app.9f2d1.js). Применять ее к HTML-документам опасно, так как это может запереть и юзеров, и краулеров на устаревшем контенте.

Наконец, помните, что кэш сохраняет редиректы и ошибки.

Редирект 301 часто кэшируется навсегда по умолчанию, и даже ошибки 404 или 500 могут ненадолго кэшироваться, из-за чего временные проблемы кажутся краулерам более долгосрочными.

Также учтите, что использование Cache-Control: no-store на HTML-документе — это частый блокер для Back`/forward` cache (BFCache), который мешает мгновенному восстановлению страниц и ухудшает юзабилити.

https://www.jonoalderson.com/performance/http-caching/

@MikeBlazerX

Инсайты для узкого круга — в @MikeBlazerPRO

Источник новости https://t.me/mikeblazerx/5893...