Edge Caching для быстрых сайтов: Cloudflare, Varnish, кейсы
Недавно наш клиент, интернет-магазин на 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 — хранение контента на серверах CDN рядом с пользователем. Вместо запроса к origin-серверу посетитель получает данные с ближайшего edge-узла за 10–30 мс. Это критично для сайтов с глобальной аудиторией: Core Web Vitals напрямую влияют на ранжирование. Мы, инженеры с опытом более 10 лет, настраиваем Edge Caching под ключ — от простых Cache Rules до сложных Varnish-конфигураций. За это время реализовали более 50 проектов в e-commerce и SaaS, и в каждом экономия на трафике составляла до 80%.
Почему 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 Cache-Control | Сервер origin | Низкая (заголовки) | Как задано | Низкая | Простые сайты, API |
Cloudflare Cache Rules в сочетании с правильными заголовками дают результат в 2–3 раза лучше по скорости отдачи, чем кэширование на уровне приложения.
Как настроить Edge Caching?
| Этап | Действия | Срок |
|---|---|---|
| Аудит | Проверка заголовков через curl и Chrome DevTools; поиск узких мест | 2-4 часа |
| Проектирование | Определение URL для кэширования, TTL, стратегии инвалидации | 1-2 дня |
| Конфигурация CDN | Настройка Cloudflare Cache Rules или Varnish VCL; настройка Nginx заголовков | 1-2 дня |
| Тестирование | Проверка Cache Hit Rate, TTFB, LPC через PageSpeed Insights; мониторинг заголовка X-Cache-Status | 1 день |
| Документирование | Фиксация конфигураций, обучение команды, передача доступов | 0.5 дня |
Суммарно базовая настройка занимает 1–2 дня, сложные интеграции (Next.js ISR + Varnish) — до 3 дней.
Примеры конфигураций
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 под ключ — получите документированную конфигурацию и месяц поддержки.







