За замовчуванням Cloudflare кешує лише статику (JS, CSS, зображення). Для кешування HTML-сторінок потрібно створити Cache Rules — це кардинально знижує навантаження на сервер.
Що кешує Cloudflare за замовчуванням
Caching → Configuration → Caching Level: Standard кешує файли з розширеннями: .jpg, .png, .gif, .css, .js, .woff2, .ico та інші статичні формати.
Cache Rule для HTML-сторінок
Caching → Cache Rules → Create rule:
# Кешувати всі HTML сторінки (виключаючи /admin, /wp-admin)
Conditions:
- hostname equals example.com
- AND NOT path starts with /wp-admin
- AND NOT path starts with /admin
- AND NOT Cookie contains wordpress_logged_in
Cache Settings:
- Eligible for cache: Yes
- Edge TTL: 4 hours
- Browser TTL: 1 hour
Обхід кешу для WordPress
# Cache Rule — BYPASS для WordPress admin
Conditions:
- Cookie contains: wordpress_logged_in
OR Path starts with: /wp-admin
OR Path starts with: /wp-login.php
Cache Settings:
- Cache Status: Bypass
Примусове очищення кешу
Caching → Configuration → Purge Cache:
- Purge Everything — очистити весь кеш (з обережністю)
- Custom Purge — очистити кеш конкретного URL
- Purge by Tag/Host/Prefix — Business і вище
Cache Analytics
Caching → Cache Analytics — показує співвідношення HIT/MISS/BYPASS запитів. Мета: HIT rate > 80% для статики.
Часті проблеми з кешуванням
| Симптом | Причина |
|---|---|
| CF-Cache-Status: DYNAMIC замість очікуваного HIT | Запит не підпадає під умови Cache Rule, або у відповіді є Set-Cookie — такі відповіді Cloudflare за замовчуванням не кешує |
| CF-Cache-Status: EXPIRED одразу після очищення | Edge TTL закінчився раніше очікуваного — звірте значення із заголовками Cache-Control на джерелі |
| Користувач бачить чужий кошик або чужі дані | Закешовано персоналізовану сторінку без виключення за Cookie — критична помилка конфігурації |
| Зміни на сайті не з'являються навіть після Purge Everything | Винен не Cloudflare, а кеш браузера або проміжний кеш на хостингу (наприклад, сторінка в OPcache/Redis) |
Рекомендовані TTL за типом контенту
| Тип контенту | Edge TTL | Browser TTL |
|---|---|---|
| Статичні ассети (JS/CSS/зображення) | 1 місяць | 1 день |
| HTML публічних сторінок | 4 години | 10 хвилин |
| API-відповіді без персоналізації | 5 хвилин | Без кешу (no-store) |
| Персоналізовані сторінки | Bypass | Без кешу (no-store) |
Коли Cache Rules не допоможуть
- Контент персоналізований для кожного користувача (особистий кабінет, кошик) — кешувати такі сторінки в принципі не можна без ризику витоку чужих даних
- Сайт уже віддає коректні заголовки Cache-Control і не потребує перевизначення на рівні Cloudflare
- Застосунок залежить від актуальності даних у реальному часі (котирування, чати) — будь-який кеш тут шкідливий
- На тарифі Free обмежена кількість правил і типів умов — для складної логіки потрібен вищий план
Перевірка результату
Після налаштування правила переконайтеся, що кеш дійсно працює, за заголовком відповіді:
curl -sI https://example.com/ | grep -i cf-cache-status
# Перший запит зазвичай MISS, повторний протягом Edge TTL — HIT
curl -sI https://example.com/ | grep -i cf-cache-status
Якщо статус стабільно DYNAMIC — перевірте умови правила в Page Rules: старе правило з вищим пріоритетом може перебивати новий Cache Rule. Загальні рекомендації щодо прискорення віддачі — у статті про оптимізацію швидкості в Cloudflare.
Порядок застосування правил
Cache Rules у Cloudflare виконуються згори вниз, і перше правило, що підходить за умовами, перемагає — подальші правила для цього запиту вже не перевіряються. Звідси практичне правило: більш специфічні умови (конкретний шлях, конкретний піддомен) потрібно ставити вище загальних, інакше загальне правило перехопить запит раніше, ніж система дійде до точного збігу.
Ця ж поведінка пояснює часту плутанину, коли адміністратор додає нове вузьке правило, а воно ніби не працює — насправді спрацьовує більш раннє широке правило. Перевірити фактично застосоване правило можна в розділі Caching → Cache Rules за лічильником «Requests», який оновлюється в міру звернень до сайту.
Взаємодія з кешем самого хостингу
Cloudflare кешує відповіді на рівні edge-серверів по всьому світу, але це не скасовує власний кеш на стороні хостингу — наприклад, сторінковий кеш плагіна WordPress або OPcache для PHP-коду. Ці два рівні працюють незалежно: очищення кешу Cloudflare не зачіпає кеш на сервері, і навпаки. Під час відлагодження проблем із застарілим контентом завжди перевіряйте обидва рівні окремо, інакше легко витратити час на «очищення не того кешу».