Оптимізація продуктивності Drupal: кешування, Varnish, Redis

Чому оптимізація продуктивності Drupal починається з багаторівневого кешування?

Типова ситуація: Drupal-сайт з 10 000 відвідувачів на день починає гальмувати при пікових навантаженнях. Без кешу кожна сторінка генерує до 30 SQL-запитів, що при 1000 паралельних сесій призводить до перевищення лімітів CPU та падіння. TTFB злітає до 2 секунд, Core Web Vitals провалюються. На одному з проектів з 50 000 відвідувань на день ми знизили TTFB з 2.5 с до 8 мс, впровадивши багаторівневе кешування.

Ми стикалися з цією проблемою десятки разів. Рішення — комбінація Internal Page Cache, Dynamic Page Cache, Redis, Varnish та BigPipe. Цей стек знижує навантаження на 90% і скорочує TTFB до десятків мілісекунд. Оптимізація продуктивності Drupal вимагає розуміння того, як працюють cache tags та інвалідація.

Проблеми, які вирішуємо

• Високий TTFB — сторінки рендеряться заново для кожного запиту, хоча контент статичний. Типовий випадок: Drupal без кешу генерує сторінку за 500–1500 мс, з них 300–800 мс — SQL-запити.
• Навантаження на БД — кожний рендер викликає десятки запитів (N+1 query, неоптимізовані view). При 100 rps БД може впасти.
• Повільні динамічні блоки — персоналізовані елементи (корзина, юзер-бар) блокують рендеринг решти сторінки. BigPipe вирішує це потоковим рендерингом.

Архітектура кешування

Drupal — одна з небагатьох CMS із вбудованою підтримкою кешу на рівні ядра. Ми використовуємо чотири рівні:

Render cache

Кешуються окремі render arrays (блоки, в'юхи, поля). Інвалідується за cache tags. Приклад: блок останніх новин кешується на 1 годину, інвалідується при публікації нової новини.

Dynamic Page Cache

Кешує сторінки з урахуванням контексту (авторизований/ні, мова, роль). Не запускає повний bootstrap, але все одно звертається до PHP. Типовий TTFB: 50–200 мс.

Internal Page Cache

Кеш повних сторінок для анонімних користувачів. Зберігає HTML на диску/в БД. Вмикається через адмінку або drush:

drush en page_cache -y
drush cr

У конфігу: system.performance > cache.page.max_age = 3600.

vcl 4.1;
import std;
backend default {
    .host = "127.0.0.1";
    .port = "8080";
}
sub vcl_recv {
    if (req.http.Cookie ~ "SESS|SSESS") { return(pass); }
    if (req.method != "GET" && req.method != "HEAD") { return(pass); }
    unset req.http.Cookie;
    return(hash);
}
sub vcl_backend_response {
    set beresp.ttl = 1h;
    set beresp.grace = 1h;
    return(deliver);
}
sub vcl_deliver {
    set resp.http.X-Cache = obj.hits > 0 ? "HIT" : "MISS";
}

composer require drupal/varnish_purger drupal/purge
drush en purge purge_drush purge_ui purge_queuer_coretags purge_processor_cron varnish_purger -y

Які метрики продуктивності відстежувати?

Відстежуємо TTFB, кількість SQL-запитів, відсоток cache hits (HIT/MISS), LCP, CLS. Інструменти: модулі Devel, XHProf, заголовки X-Cache від Varnish. Мета — TTFB <200 мс та cache hit ratio >90%. На одному з проектів після оптимізації TTFB впав з 1.2 с до 12 мс, а SQL-запити — з 250 до 3 на сторінку. Замовте аудит, щоб дізнатися точні метрики вашого сайту.

Як налаштування кешування Drupal впливає на Core Web Vitals?

Правильно налаштоване кешування безпосередньо покращує LCP та INP. Коли сторінка віддається з кешу Varnish, LCP знижується до 500-800 мс, а INP — за рахунок відсутності довгих задач на сервері. Для авторизованих користувачів BigPipe розбиває рендеринг на потоки, що зменшує час до першого контенту.

Налаштування Redis для Drupal

Встановіть модуль Redis, пропишіть параметри в settings.php:

$settings['redis.connection']['interface'] = 'PhpRedis';
$settings['redis.connection']['host'] = 'localhost';
$settings['cache']['default'] = 'cache.backend.redis';
$settings['cache']['bins']['render'] = 'cache.backend.redis';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.redis';

Після цього кеш-біни вивантажуються в Redis, знижуючи навантаження на БД на 70-90%. OPcache прискорює виконання PHP-скриптів на 30-50%.

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

• Аудит поточної архітектури (логи, конфіги, навантаження).
• Впровадження всіх рівнів кешування (Internal Page Cache, Dynamic Page Cache, Redis, Varnish, BigPipe).
• Налаштування PHP OPcache та CSS/JS агрегації.
• Документація з обслуговування та рекомендації з деплою.
• Гарантія результату: TTFB <200 мс при типовому навантаженні.
• Навчання команди роботі з кешем та моніторингом.

Економія на інфраструктурі може сягати 80% за рахунок зниження навантаження на сервери. Інвестиції в оптимізацію окупаються в середньому за 2–3 місяці.

Процес роботи та строки

1. Аналітика — вивчаємо поточну архітектуру, логи, конфіги (1 день).
2. Проектування — обираємо стек: Varnish vs Nginx cache, Redis vs Memcache (1 день).
3. Реалізація — налаштування кешування, BigPipe, Purge (2–3 дні).
4. Тестування — навантажувальне тестування, заміри Core Web Vitals (1 день).
5. Деплой — розгортання на production, документування (1 день).

Орієнтовні строки: базова оптимізація — 2–3 дні, з Varnish — 5–7 днів. Вартість розраховується індивідуально. Зв'яжіться з нами для детального аудиту.

Результати типової оптимізації

Varnish приблизно в 10 разів швидше Dynamic Page Cache для анонімних запитів.

Порівняння методів кешування

Згідно з Wikipedia, BigPipe — технологія потокового рендерингу, яка мінімізує час до першого контенту для авторизованих користувачів.

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

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