Багаторівневе кешування: Browser→CDN→Varnish→Redis→DB

Ми стикалися з проектами, де кожен запит до сторінки перетворювався на десятки SQL-запитів. Гальмував навіть простий блог. Після впровадження багаторівневого кешування час відповіді впав з 2000 мс до 80 мс, а навантаження на базу знизилося на 95%. Клієнти суттєво знижують витрати на інфраструктуру після такої оптимізації. Розповідаємо, як побудувати таку систему.

Багаторівневе кешування — це послідовність шарів зберігання відповідей. Кожен шар обслуговує запит, не передаючи його далі. Чим ближче до користувача потрапляння в кеш, тим швидша відповідь. Правильна стратегія знижує навантаження на базу даних і сервер додатку, а також покращує Core Web Vitals.

Чому недостатньо одного рівня кешування?

Браузерний кеш економить трафік, але не допомагає при першому візиті. CDN прискорює доставку статики, але для динамічних сторінок потрібен швидший шар. Varnish — потужний reverse proxy, але не вміє зберігати складні структури даних. На відміну від Apache mod_cache, Varnish працює в 10 разів швидше завдяки оптимізованій VCL. Redis вирішує це завдання, але потребує оперативної пам'яті. Комбінація цих інструментів дає максимальний ефект: типовий сайт після налаштування отримує hit rate >80% на CDN та >70% на Varnish.

Кешування бази даних (query cache) може додатково підвищити продуктивність, досягаючи hit rate >90% для повторюваних запитів.

Рекомендовані TTL для різних типів контенту

Ці TTL потрібно коригувати під частоту змін контенту. Для новинного порталу HTML краще кешувати на 2 хвилини, для корпоративного сайту — на годину. Ми завжди проводимо навантажувальне тестування, щоб переконатися, що hit rate відповідає цільовим значенням.

Як налаштувати браузерне кешування?

# nginx: заголовки для браузерного кешу
location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

location ~* \.html$ {
    add_header Cache-Control "public, max-age=0, s-maxage=300";
    add_header Vary "Accept-Encoding, Accept-Language";
}

Директива immutable говорить браузеру не перевіряти актуальність файлу — він гарантовано не зміниться. Це дає миттєве завантаження при повторних візитах. Браузерний кеш у 100 разів швидший за запит до сервера.

Підключення CDN

# cloudflare page rules
- pattern: "*.company.com/assets/*"
  settings:
    cache_level: cache_everything
    edge_cache_ttl: 2592000  # 30 днів
    browser_cache_ttl: 31536000  # 1 рік

CDN знімає навантаження з origin і скорочує TTFB для географічно віддалених користувачів.

Varnish: тонке налаштування

vcl 4.1;
backend default {
    .host = "app-server";
    .port = "8080";
}
sub vcl_recv {
    if (req.http.Authorization || req.http.Cookie ~ "session") { return (pass); }
    if (req.method != "GET" && req.method != "HEAD") { return (pass); }
    unset req.http.Cookie;
    return (hash);
}
sub vcl_backend_response {
    if (beresp.status == 200 || beresp.status == 301) {
        if (beresp.http.Content-Type ~ "text/html") { set beresp.ttl = 5m; }
        else if (beresp.http.Content-Type ~ "application/json") { set beresp.ttl = 1m; }
        unset beresp.http.Set-Cookie;
    }
    set beresp.grace = 1h;
}
sub vcl_deliver {
    if (obj.hits > 0) { set resp.http.X-Cache = "HIT"; }
    else { set resp.http.X-Cache = "MISS"; }
}

Згідно з документацією Varnish Cache, grace period дозволяє обслуговувати застарілий кеш, коли backend недоступний, що підвищує доступність. Hash key можна кастомізувати для розділення кешу за мовами або пристроями.

Вирішення проблеми інвалідації кешу

Без правильної інвалідації користувачі побачать застарілі дані. Ми проєктуємо єдину систему: при зміні даних надсилаються HTTP PURGE на Varnish, видаляються ключі Redis та очищаються теги CDN. Приклад на Python:

def on_product_updated(product_id):
    redis.delete(f"product:{product_id}")
    requests.request('PURGE', f"http://varnish:6081/products/{product_id}")
    # Cloudflare purge by tag
    requests.post(f"https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache",
        headers={"Authorization": f"Bearer {token}"},
        json={"tags": [f"product-{product_id}"]})

Типова помилка — налаштування надто довгих TTL без механізму інвалідації. Ми рекомендуємо використовувати теги на CDN та PURGE на Varnish, щоб гарантувати свіжість даних. У деяких сценаріях ми застосовуємо Edge Functions для миттєвої інвалідації на межі мережі.

Моніторинг hit rate за рівнями

Використовуємо Prometheus метрики: varnish_main_cache_hit / (varnish_main_cache_hit + varnish_main_cache_miss), redis_keyspace_hits_total / (redis_keyspace_hits_total + redis_keyspace_misses_total). Цільові значення вказані в таблиці вище. Регулярний моніторинг дозволяє своєчасно коригувати TTL та виявляти проблеми з інвалідацією.

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

1. Аудит поточної архітектури кешування — аналізуємо логи nginx, конфіги Varnish, параметри Redis та структуру CDN.
2. Налаштування Browser Cache через nginx або .htaccess.
3. Підключення CDN (Cloudflare, CloudFront) з правилами кешування.
4. Встановлення та конфігурація Varnish (4.1+) з правилами grace та hash.
5. Налаштування Redis (кластер, персистентність, eviction policy).
6. Створення єдиної системи інвалідації з PURGE та API.
7. Навантажувальне тестування та оптимізація TTL.
8. Документація та навчання команди.

Терміни та вартість

Налаштування повного стеку — від 4 до 7 робочих днів. Вартість розраховується індивідуально і залежить від складності проекту. Наприклад, налаштування для інтернет-магазину з 10 000 товарів коштує близько $1000, а середня економія на серверних ресурсах після впровадження становить $500 на місяць. Клієнти зазвичай окуповують вкладення за 2–3 місяці за рахунок зниження витрат на сервери та підвищення конверсії.

Поширена помилка — неправильне налаштування TTL

Багато хто встановлює однакові TTL для всіх типів контенту. Це призводить або до надмірного кешування динамічних даних, або до надто частої інвалідації статики. Ми підбираємо TTL на основі частоти оновлення контенту: статика — на рік, HTML — 5 хвилин, JSON API — 1 хвилина. Після налаштування перевіряємо hit rate і коригуємо при необхідності.

Спеціалізуємося на оптимізації продуктивності сайтів понад 5 років, виконали більше 50 проектів. Замовте аудит поточного кешування — ми виявимо вузькі місця і запропонуємо оптимальну стратегію. Отримайте консультацію з налаштування багаторівневого кешування для вашого проекту.

Чому 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 пунктів.