Cache Rules у Cloudflare: пришвидшіть фронтенд, не змінивши жодного рядка коду
У сучасному вебі важить кожна мілісекунда. Ми днями оптимізуємо React-компоненти, тонко налаштовуємо конфігурацію Next.js і зменшуємо розміри бандлів, щоб покращити Core Web Vitals. Але один із найпотужніших важелів продуктивності взагалі не потребує змін у коді застосунку. Він повністю живе на краю мережі (network edge): Cloudflare Cache Rules.
Перенісши стратегію кешування в глобальну мережу Cloudflare, ви можете віддавати користувачам ресурси, статичні сторінки і навіть динамічні відповіді API з майже нульовою затримкою, водночас повністю захищаючи origin-сервер від стрибків трафіку.
1. Що таке Cache Rules?
Роками Cloudflare покладався на «Page Rules» для кастомних налаштувань. Вони працювали, але були обмеженими: для одного URL-патерну можна було поєднати лише невелику кількість параметрів. На заміну їм Cloudflare запровадив Cache Rules — окремий, дуже гнучкий рушій, побудований на швидкій платформі Ruleset Platform.
Cache Rules дають змогу писати складні умовні вирази на основі власних критеріїв (заголовків запиту, cookies, query-рядків чи HTTP-методів), щоб точно визначити, як edge-сервери Cloudflare мають кешувати й віддавати ваш контент.
2. Чому edge-кешування переважає традиційне
Коли ви покладаєтеся лише на кешування в браузері (через заголовки Cache-Control, що надсилаються користувачу), оптимізація приносить користь тільки відвідувачу, який повертається. Коли користувач уперше заходить на ваш сайт, його браузер однаково мусить сходити до origin-сервера по ресурси.
Edge-кеш працює як спільний глобальний кеш. Коли перший користувач у Києві запитує некешовану статичну сторінку чи ресурс, Cloudflare отримує її з вашого сервера й зберігає копію в локальному київському дата-центрі. Коли наступні тисячі користувачів у цьому регіоні запитують той самий ресурс, до вашого origin-сервера ніхто навіть не звертається. Файл віддається безпосередньо з edge за мілісекунди.
| Метрика | Стандартний запит до origin | Влучання в edge-кеш Cloudflare |
|---|---|---|
| Time to First Byte (TTFB) | 200 мс – 1,5 с (залежно від навантаження на сервер) | <10 мс – 30 мс (віддається з RAM/SSD на edge) |
| Навантаження на origin-сервер | Високе (обробка роутингу, рендеринг, запити до БД) | Нульове (сервер повністю оминається) |
| Витрати на трафік | Високі (оплата хостингу за вихідний трафік) | Нульові (Cloudflare не бере плату за CDN-трафік) |
3. Три базові Cache Rules для фронтенд-інженерів
Розгляньмо практичні правила з реальних проєктів, які ви можете налаштувати в дашборді Cloudflare просто зараз, щоб оптимізувати сучасний вебзастосунок.
Правило 1: агресивне кешування статичних ресурсів (результати збірки Vite/Next.js)
Сучасні збирачі додають до production-ресурсів унікальні хеші вмісту (наприклад, main-a8f9d3.js, styles-b2c4e1.css). Оскільки після деплою ці файли ніколи не змінюються, їх можна кешувати безстроково.
- Вираз:
(http.request.uri.path matches "^/(assets|_next/static)/.*") - Cache Status: Eligible for cache
- Edge TTL: Override origin -> 1 місяць
- Browser TTL: Override origin -> 1 рік
Чим це допомагає: гарантує, що важкі JS-бандли та CSS повністю оминають ваш сервер і миттєво завантажуються для кожного користувача в будь-якій точці світу.
Правило 2: кешування динамічних сторінок для неавторизованих користувачів
Якщо у вашому застосунку є публічні маркетингові маршрути, лендинги чи каталоги товарів, які не залежать від того, хто їх переглядає, їх можна безпечно кешувати на edge — за умови, що користувач не залогінений.
- Вираз:
(http.request.uri.path in {"/" "/about" "/pricing"} and not http.request.headers["cookie"] contains "auth_session") - Cache Status: Eligible for cache
- Edge TTL: Override origin -> 30 хвилин
Чим це допомагає: анонімний трафік (а він становить більшість переглядів лендингів) отримує миттєве завантаження, тоді як залогінені користувачі й далі звертаються напряму до сервера по свіжі персональні дані.
Правило 3: оптимізація статичних JSON-відповідей API
Якщо ваш фронтенд отримує з API повільні дані, що рідко змінюються (навігаційні меню, конфігурації чи рядки локалізаційних словників), JSON-відповідь можна кешувати безпосередньо на edge.
- Вираз:
(http.request.uri.path matches "^/api/v1/(config|navigation)" and http.request.method eq "GET") - Cache Status: Eligible for cache
- Edge TTL: Override origin -> 2 години
4. Як уникнути пасток: інвалідація кешу та ревалідація
Найбільший страх розробників щодо агресивного кешування — віддавати застарілий контент. Якщо ви закешували HTML-сторінку чи API-ендпоінт на edge на 2 години, що станеться, коли через 5 хвилин доведеться терміново викотити багфікс?
Cloudflare розв’язує цю проблему кількома механізмами:
- Purge Everything / Purge by URL: кеш можна очистити вручну в дашборді Cloudflare або програмно через Cloudflare API під час CI/CD-пайплайну деплою (наприклад, у workflow GitHub Actions).
- Stale-While-Revalidate: можна налаштувати Cloudflare так, щоб він миттєво віддавав користувачу закешований ресурс, а у фоні асинхронно звертався до origin по оновлену версію для наступного відвідувача.
Висновок
Щоб фронтенд відчувався миттєвим, не завжди потрібна швидша база даних чи повний рефакторинг коду. Розуміючи межу мережі та налаштувавши точні Cloudflare Cache Rules, ви наближаєте застосунок до своїх користувачів по всьому світу, стабілізуєте хостинг-інфраструктуру й без зайвих зусиль вичавлюєте максимум із метрик продуктивності.