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 починається від $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?

Вибір залежить від архітектури та вимог. Порівняємо три популярних підходи:

Cloudflare Cache Rules у 2–3 рази швидші за кешування на рівні застосунку, а Varnish забезпечує на 50% вищий Cache Hit Rate, ніж Nginx без Varnish.

Покрокова інструкція з налаштування Edge Caching:

1. Аудит поточної конфігурації: перевірте HTTP-заголовки за допомогою curl та Chrome DevTools.
2. Проектування кеш-стратегії: визначте, які URL потрібно кешувати, TTL та умови інвалідації.
3. Конфігурація CDN: налаштуйте Cloudflare Cache Rules, Varnish VCL або Nginx заголовки.
4. Тестування: перевірте Cache Hit Rate, TTFB, LCP через PageSpeed Insights.
5. Документування: зафіксуйте конфігурації та передайте команді.

Приклади конфігурацій

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;
}
}

curl -I https://mysite.com/api/products | grep -i x-cache
# X-Cache-Status: HIT | MISS | BYPASS

Цільові показники Cache Hit Rate:

Що входить в роботу

• Детальний аудит поточної конфігурації зі звітом.
• Проектування кеш-стратегії (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 під ключ — отримайте документовану конфігурацію та місяць підтримки.

Чому Core Web Vitals критичні для технічного SEO

PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент із сайтом на 3 роки старше стоїть вище у видачі, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій. Ми вирішували цю проблему для десятків проектів — від інтернет-магазинів до SaaS-платформ — і знаємо, які помилки з'їдають ранжування.

Як досягти хороших показників Core Web Vitals?

Core Web Vitals: що реально впливає на позиції

Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з останнього великого оновлення алгоритму).

LCP: чому 8 секунд — це не проблема зображення

LCP вимірює час відмальовки найбільшого видимого елемента сторінки. Найчастіше — hero image або H1. Пороги: добре < 2.5s, погано > 4s.

Типовий діагноз на реальному проекті: інтернет-магазин одягу, LCP 7.8s на мобільних. Елемент — hero image категорії, 4.2MB JPEG без srcset, завантажується через CSS background-image (не <img>). Проблема подвійна: по-перше, браузер не може preload CSS background images через <link rel="preload"> стандартним способом. По-друге, 4.2MB на мобільному з'єднанні — це фізично повільно.

Рішення по кроках:

1. Переносимо hero з CSS background в <img> з fetchpriority="high" та loading="eager"
2. Конвертуємо в WebP, додаємо srcset: 800w для мобільних, 1400w для десктопа
3. <link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
4. Прибираємо всі render-blocking скрипти вище hero через defer

Підсумок: LCP 7.8s → 1.9s. Без зміни хостингу, без CDN.

Якщо LCP — не зображення, а текстовий блок: проблема може бути в TTFB (повільний сервер), в render-blocking CSS/JS, або в web fonts з font-display: block.

CLS: зсуви, які дратують користувача і Google

CLS вимірює сумарний зсув елементів в процесі завантаження. Пороги: добре < 0.1, погано > 0.25. CLS 0.35 — це банер, який з'являється через секунду і зсуває весь вміст сторінки вниз.

Джерела CLS:

• Зображення без заданих розмірів. <img src="photo.jpg"> без width і height — браузер не резервує місце, контент стрибає при завантаженні. Фікс: явні width/height або aspect-ratio в CSS.
• Рекламні блоки та віджети. Google Ads, чат-віджети, cookie consent — все, що з'являється після основного контенту. Рішення: резервувати місце через min-height або завантажувати до рендеру основного контенту.
• Web fonts. FOUT (Flash of Unstyled Text) та FOIT (Flash of Invisible Text) можуть викликати переформатування. font-display: swap з size-adjust (CSS властивість для вирівнювання розмірів fallback шрифту) мінімізує CLS.
• Динамічний контент. Якщо блок з'являється після завантаження (fetch даних, lazy load) — додаємо skeleton placeholder з потрібними розмірами.

INP: чому інтерфейс «зависає» на 500ms

INP вимірює затримку відповіді на будь-яку взаємодію користувача: клік, тап, введення. Пороги: добре < 200ms, погано > 500ms. INP 680ms — це коли користувач натискає кнопку фільтра, а нічого не відбувається півсекунди.

Головна причина високого INP — заблокований main thread. JavaScript-бандл 2.1MB парситься і виконується синхронно. Поки виконується, користувацькі події не обробляються.

Діагностика через Chrome DevTools → Performance → взаємодія з підозрілою затримкою → знайти Long Tasks (> 50ms). Типові винуватці:

• Безперервна обробка великого списку без requestIdleCallback або requestAnimationFrame
• Важкі event listeners без debounce/throttle
• Синхронний setState в React, який тригерить повний ре-рендер складного дерева компонентів
• Third-party scripts: livechat, аналітика, віджети — вони виконуються в тому ж main thread

Рішення: code splitting через динамічний import(), перенесення важких обчислень в Web Workers, React.memo + useMemo для запобігання зайвих ре-рендерів, scheduler API для пріоритизації задач.

Schema.org: розмітка, яку читають роботи

Структуровані дані через JSON-LD — не прямий ранжуючий фактор, але дають rich snippets у видачі (зірки рейтингів, ціни, дата публікації), що збільшує CTR на 20–30%.

Типи розмітки за сценаріями:

• E-commerce: Product з offers (ціна, наявність, валюта), aggregateRating (рейтинг з відгуків), brand. BreadcrumbList для навігації. ItemList для сторінок категорій.
• Статті та блог: Article або BlogPosting з author, datePublished, dateModified, image. Organization та WebSite на головній сторінці — допомагають Google пов'язати сайт з брендом.
• Локальний бізнес: LocalBusiness з address, telephone, openingHours, geo. Критично для локального SEO.
• FAQ: FAQPage з mainEntity — питання та відповіді можуть з'являтися прямо у видачі як розкривний блок.

Валідація: Google Rich Results Test та Schema Markup Validator. Часта помилка — вказати price без priceCurrency, або ratingValue без reviewCount. Google ігнорує неповну розмітку.

Як проводити технічний SEO-аудит

Сканованість. robots.txt блокує потрібні сторінки (або навпаки, не блокує службові). Canonical URLs налаштовані неправильно — дублюються сторінки з UTM-мітками. Sitemap містить сторінки з noindex. Все це Screaming Frog або Sitebulb покажуть за годину сканування.

Core Web Vitals в масштабі. Google Search Console → Core Web Vitals → дивимося не окремі сторінки, а групи URL (шаблон сторінки продукту, шаблон категорії, блог). Проблема зазвичай системна — одна помилка в шаблоні псує сотні сторінок.

JavaScript SEO. Google рендерить JavaScript, але з затримкою (іноді дні для повного рендеру). Для критичного контенту — SSR або SSG обов'язкові. Перевіряємо через Search Console → Inspect URL → View Crawled Page: що бачить Googlebot.

Internal linking. Орфанні сторінки (немає вхідних внутрішніх посилань) втрачають PageRank. Бите посилання (404) — сигнал якості.

Що входить в роботу

• Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
• Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
• Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
• Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.

Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.