TTL — это не настройка «на глаз»: сначала смотрим на трафик и поведение кэша

TTL — это не настройка «на глаз»: сначала смотрим на трафик и поведение кэша

Если менять TTL без анализа, можно получить либо лишние запросы к origin, либо слишком долгую жизнь устаревшего контента. Начинать нужно с трёх метрик: cache hit ratio, доля динамических запросов и время обновления контента на стороне источника.

Для статических ресурсов TTL обычно можно делать длиннее: CSS, JS, изображения редко меняются, а кэш снижает нагрузку и задержку. Для HTML и API-контента TTL должен зависеть от частоты публикаций и допустимой «устарелости» данных. Если контент обновляется часто, лучше использовать короткий TTL и точечную инвалидацию, чем держать универсальное значение для всего домена.

Полезно разнести трафик по типам: отдельные правила для статических файлов, страниц каталога, персонализированных ответов и служебных запросов. Смотрим не только на общий объём, но и на распределение по URL, статусам ответа и возрасту объектов в кэше. Если miss'ов много на одном типе объектов, проблема обычно не в CDN, а в неверной стратегии cache key или слишком агрессивном bypass.

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