Кеш на рівні сервера: невидимий прискорювач, який перетворює повільний хостинг на ракету

Уявіть: ви заходите в улюблену кав'ярню, замовляєте латте, і бариста каже - "Зачекайте, мені потрібно спершу виростити каву, потім обсмажити зерна, потім..." Абсурд, правда? Але саме так працює ваш сервер без кешування. Кожен запит від відвідувача змушує його заново генерувати сторінку з нуля - звертатися до бази даних, збирати шаблон, обробляти PHP-код. І так тисячі разів на день. Одну й ту саму сторінку. Для різних людей. З однаковим результатом. Серверний кеш - це той самий готовий латте на стійці, який бариста зробив заздалегідь, бо знає: його замовлять знову.

Більшість власників сайтів чули про кешування, але вважають його магією для DevOps-інженерів. Насправді розуміння серверного кешу - це різниця між сайтом, що вантажиться 4 секунди, і сайтом, що відповідає за 200 мілісекунд. І ні, плагін для WordPress тут не допоможе так, як вам обіцяють.

Що саме кешує сервер і чому це не те саме, що кеш браузера

Давайте розставимо крапки. Коли хтось говорить "кеш", зазвичай має на увазі одне з трьох: кеш браузера, кеш CDN або кеш на рівні сервера. Перші два - це зовнішні шари. Вони корисні, але не вирішують головної проблеми: ваш сервер все одно задихається під навантаженням.

Серверний кеш працює інакше. Він зберігає результати обчислень прямо на машині - в оперативній пам'яті або на швидкому диску - щоб не повторювати ту саму роботу двічі.

• OPcache - кешує скомпільований PHP-код, щоб інтерпретатор не розбирав скрипти кожного разу
• Object cache (Redis/Memcached) - зберігає результати запитів до бази даних в оперативній пам'яті
• Page cache (FastCGI cache, Varnish) - зберігає повністю згенеровану HTML-сторінку
• Query cache - кешує повторювані SQL-запити на рівні СУБД

Кожен рівень знімає навантаження з конкретного вузла. І найбільший ефект ви отримаєте, коли ввімкнете всі рівні разом - не один якийсь плагін, а повний стек кешування від PHP до HTTP.

П'ять рівнів серверного кешу: від фундаменту до даху

Думайте про серверний кеш як про п'ятиповерховий будинок. Кожен поверх виконує свою функцію, і пропуск будь-якого - це дірка в конструкції.

1. OPcache (рівень PHP). Без нього PHP перечитує та компілює кожен файл при кожному запиті. Увімкнення OPcache дає приріст швидкості PHP-коду на 30-70%. Налаштовується за 2 хвилини в php.ini.
2. Object cache - Redis або Memcached (рівень даних). WordPress, Drupal, Laravel - усі вони бомбардують базу даних сотнями запитів на сторінку. Redis зберігає відповіді в RAM. Результат - час генерації сторінки падає з 800 мс до 150 мс.
3. Query cache / ProxySQL (рівень СУБД). MySQL вміє кешувати результати запитів. Але з версії 8.0 вбудований query cache прибрали - він погано масштабувався. Тепер для цього використовують ProxySQL або аналоги.
4. FastCGI cache / Varnish (рівень веб-сервера). Nginx зберігає повну HTML-сторінку і віддає її без звернення до PHP взагалі. Varnish робить те саме, але ще агресивніше. TTFB падає до 10-30 мс.
5. Microcaching (рівень реального часу). Навіть динамічні сторінки можна кешувати на 1-5 секунд. При 1000 запитів на секунду сервер обробить лише один, а решту 999 віддасть з кешу.

"Кешування - це не оптимізація. Це архітектурне рішення. Якщо ви додаєте кеш як пластир на рану - ви лише відкладаєте проблему. Якщо ви проєктуєте систему з кешем від початку - ви будуєте систему, яка масштабується." - Martin Kleppmann, автор книги "Designing Data-Intensive Applications"

Цифри, які змусять вас зупинитися і подумати

Порівняймо продуктивність одного й того самого WordPress-сайту на VPS з 2 ядрами та 4 ГБ RAM. Тест - 100 одночасних користувачів, ab (Apache Benchmark), сторінка блогу з 20 записами.

Подивіться на останній рядок. Той самий сервер. Те саме залізо. Але замість 12 запитів на секунду - 950+. CPU завантажений на 8% замість 98%. Це не магія. Це три рівні кешу, налаштовані за вечір.

FastCGI cache в Nginx - найнедооцінений інструмент у світі хостингу. Він безкоштовний, вбудований, і при цьому перетворює копійчаний VPS на машину, що тримає тисячі відвідувачів.

Пастки кешування: коли "швидше" означає "зламано"

Ось чому багато адмінів бояться серверного кешу: він може показувати застарілий контент. І це не параноя - це реальна проблема, якщо не подумати заздалегідь.

Класична ситуація. Інтернет-магазин увімкнув Varnish. Клієнт додає товар у кошик - а кошик порожній, бо сервер віддає закешовану версію сторінки без cookies. Або: адмін оновив ціну, але відвідувачі ще годину бачать стару, бо TTL сторінки - 3600 секунд.

Як цього уникнути?

• Розділяйте статичне й динамічне. Кешуйте тіло сторінки, але виключайте з кешу запити з cookies авторизації чи кошика
• Використовуйте cache purge. Nginx має модуль ngx_cache_purge, Varnish - команду ban. При оновленні контенту кеш має очищатися автоматично
• Ставте адекватний TTL. Для блогу - 1 година. Для каталогу з цінами - 5 хвилин. Для API - microcache на 1-2 секунди
• Тестуйте з різними ролями. Перевіряйте як бачить сайт анонім, авторизований, адмін. Три різні світи

Правило просте: кешуйте все, що можна, і точно знайте, що не можна. Це як готувати їжу на тиждень - вареники заморозити можна, а салат - ні.

Redis vs Memcached: вічна битва, у якій переможець очевидний

Якщо ви обираєте object cache для свого проєкту, у вас два кандидати. Обидва тримають дані в оперативній пам'яті. Обидва неймовірно швидкі. Але різниця суттєва.

У 2025 році Redis - де-факто стандарт. Memcached все ще живий, але Redis виграє за функціональністю, підтримкою і гнучкістю. Якщо ви починаєте з нуля - навіть не роздумуйте.

Як налаштувати базовий стек кешу за один вечір

Не треба бути сисадміном з 20-річним досвідом. Ось конкретний план для типового VPS з Ubuntu 22.04 + Nginx + PHP-FPM + MySQL + WordPress:

1. Увімкніть OPcache. Відкрийте php.ini, встановіть opcache.enable=1, opcache.memory_consumption=256, opcache.max_accelerated_files=20000. Перезапустіть PHP-FPM.
2. Встановіть Redis. apt install redis-server - одна команда. Потім встановіть плагін Redis Object Cache у WordPress. Натисніть "Enable". Все.
3. Налаштуйте FastCGI cache в Nginx. Додайте в конфіг блок fastcgi_cache_path, визначте зону, вкажіть fastcgi_cache_valid 200 60m. Виключіть запити з cookies авторизації через map-директиву.
4. Увімкніть gzip/brotli. Технічно це не кеш, але стискання - невід'ємна частина швидкості. Brotli дає на 15-20% менший розмір порівняно з gzip.
5. Перевірте результат. curl -I yourdomain.com - шукайте заголовок X-FastCGI-Cache: HIT. Якщо бачите HIT - вітаю, сторінка летить з кешу.

Весь процес займає 2-3 години, якщо ви робите це вперше. Вдруге - 30 хвилин. Утретє - зможете налаштувати наосліп, поки варите каву.

Кеш і SEO: зв'язок, який ігнорують

Google з 2021 року використовує Core Web Vitals як фактор ранжування. Три метрики - LCP, FID (тепер INP) та CLS. Перші дві напряму залежать від швидкості сервера.

LCP (Largest Contentful Paint) - час завантаження найбільшого елемента. Якщо ваш TTFB - 1200 мс без кешу, LCP фізично не може бути нижче 1.5 секунди. Google хоче бачити менше 2.5 секунд. З FastCGI cache і TTFB 20 мс - ви легко вкладаєтеся.

Кожні 100 мс затримки - це мінус 1% конверсії. Так, ці дані від Amazon вже стали кліше. Але вони не перестали бути правдою. Якщо ваш інтернет-магазин генерує $10 000 на місяць, 400 мс зайвої затримки коштують вам $400. Щомісяця. Рік за роком.

Серверний кеш - це не витрата часу. Це інвестиція з найшвидшою окупністю у всьому стеку технологій вашого сайту.

Тепер чесно: ви знаєте, скільки мілісекунд ваш сервер витрачає на генерацію однієї сторінки? Якщо ні - відкрийте термінал і виміряйте. Можливо, ваш сайт вже давно задихається, а ви просто не чуєте, як він хрипить.