Нещодавно наш клієнт, інтернет-магазин на WooCommerce, зіткнувся з типовою проблемою: TTFB становив 800 мс, LCP — 4.2 с, конверсія падала. Причина — відсутність кешування: кожен запит йшов напряму до origin у Європі, а аудиторія була глобальною. Після налаштування Edge Caching з Cloudflare та Varnish TTFB впав до 30 мс (зниження в 26 разів), LCP — до 1.2 с, конверсія зросла на 15%. Зменшення навантаження на origin-сервер до 80% скорочує витрати на хостинг на $100–$300 на місяць для середнього проекту — такі результати не рідкість, якщо підійти до кешування системно. Середня економія на CDN-трафіку становить від $500 до $2000 на місяць для сайтів з відвідуваністю 100k+. Вартість налаштування Edge Caching починається від $300 для базового проекту.
Edge Caching — це архітектурний підхід, за якого статичний та динамічний контент зберігається на розподілених серверах CDN, максимально наближених до геолокації кінцевих користувачів, що дозволяє значно зменшити затримки. Замість запиту до origin-сервера відвідувач отримує дані з найближчого edge-вузла за 10–30 мс. Це критично для сайтів з глобальною аудиторією: Core Web Vitals безпосередньо впливають на ранжування. Ми, інженери з досвідом понад 10 років, налаштовуємо Edge Caching під ключ — від простих Cache Rules до складних Varnish-конфігурацій. За цей час реалізували понад 50 проектів у e-commerce та SaaS, і в кожному економія на трафіку становила до 80%.
Edge Caching — ключ до оптимізації швидкості сайту та прискорення сайту. Ми спеціалізуємося на налаштуванні кешу для різних платформ.
Чому Edge Caching важливий для швидкості сайту?
Користувачі з високою затримкою до origin отримують TTFB понад 500 мс, що погіршує LCP. Без CDN статичні ресурси завантажуються щоразу з сервера, забиваючи канал. Типовий e-commerce на WooCommerce без кешування віддає HTML за 400 мс, а з Edge Caching — за 50 мс. Різниця очевидна.
Зазначимо: як ми вирішуємо: аналізуємо поточні заголовки, знаходимо вузькі місця (відсутність Cache-Control, неправильний s-maxage) і застосовуємо комбінацію рішень: Cloudflare Cache Rules, Varnish, Nginx-заголовки. Edge Caching знижує TTFB в 10–20 разів порівняно з прямим зверненням до origin, а LCP — у 2–4 рази. Згідно з документацією Cloudflare Cache Rules, правильне налаштування може збільшити Cache Hit Rate до 99.9%.
Який інструмент обрати: Cloudflare, Varnish чи Nginx?
Вибір залежить від архітектури та вимог. Порівняємо три популярних підходи:
| Інструмент | Рівень | Гнучкість | TTL за замовчуванням | Складність налаштування | Ідеально для |
|---|---|---|---|---|---|
| Cloudflare Cache Rules | Edge | Висока (правила за URL, device type) | 30 днів (статику) | Низька (через API) | Глобальна аудиторія, статичні ресурси |
| Varnish Cache | Сервер origin | Середня (VCL) | 5 хв (HTML) | Середня | Сервери під контролем, динамічні сайти |
| Nginx кешування | Сервер origin | Низька (заголовки) | Як задано | Низька | Прості сайти, API |
Cloudflare Cache Rules у 2–3 рази швидші за кешування на рівні застосунку, а Varnish забезпечує на 50% вищий Cache Hit Rate, ніж Nginx без Varnish.
Покрокова інструкція з налаштування Edge Caching:
- Аудит поточної конфігурації: перевірте HTTP-заголовки за допомогою curl та Chrome DevTools.
- Проектування кеш-стратегії: визначте, які URL потрібно кешувати, TTL та умови інвалідації.
- Конфігурація CDN: налаштуйте Cloudflare Cache Rules, Varnish VCL або Nginx заголовки.
- Тестування: перевірте Cache Hit Rate, TTFB, LCP через PageSpeed Insights.
- Документування: зафіксуйте конфігурації та передайте команді.
Приклади конфігурацій
Cloudflare: Cache Rules через API
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/rulesets" \
-H "Authorization: Bearer {token}" \
-H "Content-Type: application/json" \
--data '{
"name": "Cache Rules",
"kind": "zone",
"phase": "http_request_cache_settings",
"rules": [
{
"expression": "(http.request.uri.path matches \"^/api/\")",
"action": "set_cache_settings",
"action_parameters": {
"cache": true,
"edge_ttl": {
"mode": "override_origin",
"default": 60
},
"browser_ttl": {
"mode": "override_origin",
"default": 0
}
},
"description": "Cache API responses 60s"
},
{
"expression": "(http.request.uri.path matches \"\.(js|css|woff2|png|webp|avif)$\")",
"action": "set_cache_settings",
"action_parameters": {
"cache": true,
"edge_ttl": {
"mode": "override_origin",
"default": 2592000
},
"browser_ttl": {
"mode": "override_origin",
"default": 31536000
}
},
"description": "Static assets: 30 days edge, 1 year browser"
}
]
}' HTTP Cache-Control заголовки на Nginx
location ~* \.(js|css|woff2|ico)$ {
add_header Cache-Control "public, max-age=31536000, immutable";
add_header Vary "Accept-Encoding";
gzip_static on;
}
location ~* \.(jpg|jpeg|png|webp|avif|svg|gif)$ {
add_header Cache-Control "public, max-age=2592000";
add_header Vary "Accept";
}
location / {
add_header Cache-Control "public, max-age=0, s-maxage=300, must-revalidate";
}
location /api/products {
add_header Cache-Control "public, max-age=60, s-maxage=60";
add_header Vary "Accept-Language, Accept-Encoding";
}
location /api/user {
add_header Cache-Control "private, no-cache, no-store";
} Next.js: управління кешем з ISR
async function getProducts() {
const res = await fetch('https://api.mysite.com/products', {
next: {
revalidate: 300,
tags: ['products'],
},
});
return res.json();
}
export async function POST(request: Request) {
const { secret, tag } = await request.json();
if (secret !== process.env.REVALIDATION_SECRET) {
return Response.json({ error: 'Unauthorized' }, { status: 401 });
}
revalidateTag(tag);
return Response.json({ revalidated: true });
} Varnish Cache: серверний кеш перед origin
vcl 4.0;
backend default {
.host = "127.0.0.1";
.port = "3000";
}
sub vcl_recv {
if (req.http.Authorization || req.http.Cookie ~ "session=") {
return (pass);
}
set req.url = regsuball(req.url, "[?&](utm_source|utm_medium|utm_campaign|fbclid)=[^&]*", "");
if (req.url ~ "\.(css|js|png|jpg|webp|woff2)(\?.*)?$") {
unset req.http.Cookie;
}
}
sub vcl_backend_response {
if (bereq.url ~ "\.(css|js|woff2)(\?.*)?$") {
set beresp.ttl = 30d;
set beresp.http.Cache-Control = "public, max-age=2592000";
}
if (beresp.http.Content-Type ~ "text/html") {
set beresp.ttl = 5m;
}
} Моніторинг Cache Hit Rate
curl -I https://mysite.com/api/products | grep -i x-cache # X-Cache-Status: HIT | MISS | BYPASS Заголовок X-Cache-Status повертається CDN і вказує, чи був ресурс відданий з кешу (HIT), пропущений (MISS) або обійдений (BYPASS). Моніторинг цього заголовка дозволяє точно знати ефективність кешування.
Цільові показники Cache Hit Rate:
| Тип контенту | Цільовий Cache Hit Rate |
|---|---|
| Статичні ресурси (JS, CSS, шрифти) | >99% |
| HTML-сторінки | >80% |
| Публічні API-відповіді | >70% |
Що входить в роботу
- Детальний аудит поточної конфігурації зі звітом.
- Проектування кеш-стратегії (URL, TTL, інвалідація).
- Налаштування CDN (Cloudflare Cache Rules, Varnish VCL, Nginx заголовки).
- Тестування та моніторинг (X-Cache-Status, TTFB, LCP).
- Документація конфігурацій та навчання команди.
- Місяць підтримки для корекції правил.
Які метрики відстежувати?
Крім Cache Hit Rate, важливо контролювати TTFB (ціль <50 мс) та LCP (<2.5 с). Рекомендуємо налаштувати дашборд у Cloudflare Analytics або Grafana для постійного моніторингу. Edge Caching — це не разове налаштування, а процес: потрібен періодичний перегляд правил при зміні архітектури.
Зв'яжіться з нами для аудиту поточної конфігурації. Замовте налаштування Edge Caching під ключ — отримайте документовану конфігурацію та місяць підтримки.







