Page Rules и Cache Rules: где ломают кэш и получают лишний TTL

Page Rules и Cache Rules: где ломают кэш и получают лишний TTL

Page Rules и Cache Rules решают похожие задачи, но работают по-разному. Первая — старый, но всё ещё полезный механизм для точечных исключений. Вторая — более гибкий инструмент для правил кэширования, заголовков и обхода происхождения. Ошибка начинается там, где их смешивают без иерархии.

Базовая схема простая: сначала определите, что должно кэшироваться всегда, что — только при условиях, а что — никогда. Для этого:
— статике задайте агрессивный cache key и длительный TTL;
— API, панели и личные кабинеты исключите из кэша;
— для отдельных URL применяйте bypass, если ответ зависит от cookies, авторизации или географии.

Page Rules используйте только там, где нужна жёсткая точечная обработка: редирект, disable performance, bypass cache для конкретного пути. Cache Rules лучше подходят для масштабируемой логики: условие по host, path, query string, статусу ответа. Если одно и то же можно выразить через Cache Rules, не дублируйте это в Page Rules — потом сложнее отлаживать приоритеты.

Проверяйте конфликт правил на уровне запроса: какой URL матчится первым, какой заголовок приходит с origin, не перетирает ли одно правило другое. Отдельно контролируйте cookies и query string: часто именно они незаметно создают cache fragmentation и убивают hit ratio.

Стабильность инфраструктуры — залог масштабируемости: сначала упрощайте логику кэширования, потом расширяйте её точечно.