Кеш WordPress: чому ваш сайт перевантажує сервер кожним кліком, хоча міг би не робити нічого

Уявіть собі бариста, який щоразу, коли хтось замовляє американо, біжить на плантацію вирощувати каву. Збирає зерна. Сушить. Обсмажує. Меле. Заварює. І так - для кожної чашки. Абсурд? Безумовно. Але саме так працює ваш WordPress-сайт без правильно налаштованого кешування. Кожен відвідувач змушує сервер заново збирати сторінку з десятків PHP-файлів, робити запити до бази даних, генерувати HTML. Знову і знову. Тисячі разів на день. І потім ви дивуєтесь, чому хостинг за $15 на місяць не справляється з трьома сотнями відвідувачів.

Що насправді відбувається, коли хтось відкриває ваш сайт

Більшість власників WordPress-сайтів сприймають свій сайт як щось статичне - набір сторінок, які просто "лежать" на сервері. Насправді WordPress - це динамічний двигун. Щоразу, коли хтось натискає посилання, запускається ланцюжок із 30-80 запитів до бази даних MySQL, виконуються десятки PHP-скриптів, підключаються шаблони теми, обробляються хуки плагінів. І тільки після цього відвідувач бачить сторінку.

Для блогу з 50 відвідувачами на день? Не проблема. Для інтернет-магазину з 2000 відвідувачів? Катастрофа.

Кешування - це спосіб зробити цю роботу один раз і зберегти результат. Наступний відвідувач отримує вже готову сторінку - без запуску PHP, без звернення до бази, без навантаження на процесор. Сервер фактично роздає статичний HTML-файл. Різниця в швидкості - від 3 до 50 разів.

Чотири рівні кешування, про які не розповідає ваш хостер

Кешування - не монолітна штука. Це система з кількох шарів, і кожен працює на своєму рівні. Пропустити один - як поставити броньовані двері, але забути про вікно.

1. Кеш браузера (Browser Cache) - файли зберігаються на комп'ютері відвідувача. CSS, JavaScript, зображення не завантажуються повторно. Налаштовується через заголовки Expires і Cache-Control.
2. Сторінковий кеш (Page Cache) - готовий HTML зберігається на сервері. Це основний рівень, який дає найбільший ефект. Плагіни WP Super Cache, W3 Total Cache, WP Rocket працюють саме тут.
3. Об'єктний кеш (Object Cache) - результати запитів до бази зберігаються в оперативній пам'яті через Redis або Memcached. Критично важливий для WooCommerce та сайтів з динамічним контентом, де сторінковий кеш не завжди працює.
4. Opcode-кеш (OPcache) - PHP-код компілюється один раз і зберігається в пам'яті. Без нього кожен запит змушує інтерпретатор PHP перечитувати файли з диска. OPcache вбудований у PHP з версії 5.5, але не завжди увімкнений.

"Якщо ви використовуєте WordPress без об'єктного кешу на сайті з більш ніж 50 плагінами, ви буквально спалюєте гроші на хостингу. Redis скорочує кількість запитів до MySQL на 80-90%." - Том Макфарлін, WordPress Core Contributor

Серверний кеш проти плагінів: хто кого

Ось де починається справжня плутанина. Частина хостингів пропонує "вбудоване кешування на рівні сервера" - через Nginx FastCGI Cache, Varnish або LiteSpeed Cache. Інші кажуть: "Просто поставте WP Rocket". Що обрати?

Коротка відповідь: і те, і те. Але пріоритети різні.

Серверний кеш виграє у чистій швидкості, тому що запит навіть не доходить до PHP. Nginx бачить, що є збережений файл, і миттєво віддає його. Плагін же вимушений хоча б частково запустити WordPress, щоб визначити - чи потрібно віддати кеш, чи згенерувати нову сторінку.

Ідеальна конфігурація виглядає так: серверний кеш обробляє 90% запитів від анонімних відвідувачів, а плагін керує правилами інвалідації (коли кеш потрібно скинути) та оптимізацією CSS/JS.

WooCommerce та кеш: мінне поле, яке підриває більшість

Якщо у вас інтернет-магазин на WooCommerce - вітаю, ви потрапили в найскладніший сценарій кешування. Чому? Тому що кошик, сторінка оформлення замовлення, особистий кабінет - все це динамічний контент. Кешувати його не можна. Якщо закешуєте сторінку кошика - один покупець побачить товари іншого. Було. Бачив. Не смішно.

Що потрібно зробити:

• Виключити з кешу сторінки /cart/, /checkout/, /my-account/ та всі URL з cookie woocommerce_items_in_cart
• Використовувати фрагментне кешування (fragment caching) для динамічних елементів на статичних сторінках
• Обов'язково підключити Redis для об'єктного кешу - WooCommerce генерує від 200 до 800 запитів до бази на одне завантаження каталогу
• Перевірити, що Ajax-запити (додавання в кошик) не проходять через кеш

Один мій знайомий запустив магазин одягу на WooCommerce із 3000 товарів. Shared-хостинг. Без об'єктного кешу. Під час рекламної кампанії в Instagram сайт ліг за 12 хвилин. Переїхав на VPS з Redis та Nginx FastCGI Cache - той самий сайт тримав 800 одночасних відвідувачів без жодної затримки. Ціна хостингу зросла з $7 до $25, але конверсія піднялась на 40%.

Як перевірити, чи працює ваш кеш насправді

Знаєте, що найгірше? Поставити плагін кешування, побачити зелену галочку в налаштуваннях - і думати, що все працює. А потім через три місяці виявити, що кеш вимкнений через конфлікт з іншим плагіном. Або що він кешує тільки головну сторінку.

Перевірка номер один: відкрийте DevTools у браузері (F12), вкладка Network. Перезавантажте сторінку. Подивіться на заголовок відповіді. Шукайте:

• X-Cache: HIT - сторінка віддана з кешу. Працює!
• X-Cache: MISS - кеш промахнувся, сторінка згенерована заново
• X-Cache-Status або cf-cache-status (для Cloudflare) - аналогічно

Перевірка номер два: подивіться у вихідний код сторінки (Ctrl+U). Більшість плагінів кешування додають коментар внизу HTML, наприклад: <!-- Page cached by WP Rocket -->. Немає такого коментаря? Кеш не працює.

Перевірка номер три: виміряйте TTFB (Time To First Byte) через GTmetrix або WebPageTest. Закешована сторінка WordPress видає TTFB 50-200 мс. Якщо бачите 800 мс і вище - кеш або не працює, або неправильно налаштований.

Яку стратегію кешування обрати під ваш тип хостингу

Не всі хостинги однакові. І стратегія кешування прямо залежить від того, що у вас під капотом.

Shared-хостинг - ваші можливості обмежені. OPcache зазвичай увімкнений, але Redis чи Memcached недоступні. Ставте WP Super Cache (безкоштовний) або WP Rocket (платний, але вартий кожного долара). На серверах з LiteSpeed - обов'язково LiteSpeed Cache, він працює на рівні сервера і безкоштовний.

VPS або Cloud - тут починається свобода. Встановіть Redis для об'єктного кешу, налаштуйте Nginx FastCGI Cache для сторінкового кешу, переконайтесь, що OPcache має достатньо пам'яті (мінімум 128 МБ для великих сайтів). Плагін використовуйте для управління інвалідацією та оптимізації фронтенду.

Managed WordPress-хостинг (Kinsta, WP Engine, Cloudways) - кешування зазвичай вже налаштоване. Не ставте додаткові плагіни кешу - вони конфліктуватимуть із серверним рішенням. Kinsta, наприклад, прямо забороняє WP Super Cache та W3 Total Cache. Використовуйте тільки те, що пропонує хостер.

Золоте правило: ніколи не використовуйте два плагіни сторінкового кешу одночасно. Це не подвоює швидкість. Це подвоює проблеми. Два плагіни будуть перезаписувати кеш один одного, створювати конфлікти і в підсумку ваш сайт працюватиме повільніше, ніж без кешу взагалі.

Кеш - це не "поставив і забув"

Якщо ви дочитали до цього місця, у вас може скластися враження, що достатньо один раз все налаштувати - і далі можна не повертатися. Це небезпечна ілюзія. Кожне оновлення WordPress, кожен новий плагін, кожна зміна теми може зламати кешування. Тихо. Непомітно. Місяцями.

Поставте собі нагадування раз на місяць: перевірити заголовки X-Cache, виміряти TTFB, переглянути логи помилок на предмет кеш-конфліктів. П'ять хвилин роботи, які можуть зекономити вам сотні доларів на хостингу і тисячі - на втрачених клієнтах.

А ви перевіряли, чи дійсно працює кеш на вашому сайті? Чи просто вірите зеленій галочці в плагіні?