Чому мій сайт на WordPress повільно працює на спільному хостингу? Насамперед перевірте ці п’ять моментів.

«Хостинг гальмує» — звичний діагноз, і найчастіше він помилковий. У дев’яти випадках із десяти із сервером усе гаразд, а щось, що працює поверх нього, виконує значно більше роботи, ніж потрібно.

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

1. Кеш. Чи кешується взагалі хоч щось? Перевірте заголовки відповіді в приватному вікні.
2. База даних. Скільки часу займають запити та скільки їх виконується?
3. Версія PHP. Та версія, на якій сайт справді працює, а не та, яку показує панель.
4. Плагіни. Який із них запускає повільні запити та обробники.
5. Сусіди на сервері. Лише тепер варто підозрювати спільні ресурси CPU та диска.

Перевіряйте саме в такому порядку. Він приблизно відповідає тому, наскільки часто кожна з цих причин виявляється винуватцем проблеми. Сусіди на сервері стоять останніми не просто так.

1. Чи кешується взагалі хоч щось?

Відкрийте сайт у приватному вікні та перегляньте заголовки відповіді:

curl -sI https://example.com/ | grep -iE 'x-litespeed-cache|cf-cache-status|age|cache-control'

x-litespeed-cache: hit означає, що сторінка була віддана з кешу й запит узагалі не дійшов до PHP. Якщо під час кожного запиту ви отримуєте miss, кожен відвідувач змушує WordPress заново формувати сторінку, звертаючись до бази даних. Зазвичай це 200–800 мс роботи замість приблизно 5 мс.

Найпоширеніші причини постійного miss: відсутність плагіна кешування, встановлений, але не активований плагін кешування, cookie, що встановлюється під час кожного запиту — так роблять багато плагінів чатів і керування згодою на cookies, через що сторінку неможливо кешувати, — або відсутність WP_CACHE у wp-config.php.

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

2. Скільки часу займає робота бази даних?

Встановіть Query Monitor, відкрийте повільну сторінку від імені адміністратора та подивіться на два показники: загальний час виконання запитів і їхню кількість.

Для звичайної сторінки розумним показником можна вважати менш ніж 100 запитів і менш ніж 50 мс сумарного часу роботи з базою даних. Сотні запитів зазвичай означають, що якийсь плагін запитує дані всередині циклу. А 500 мс роботи бази даних на невеликому сайті часто вказують на запит, для якого відсутній необхідний індекс.

wp db query "SHOW FULL PROCESSLIST;" --allow-root   # що виконується просто зараз
wp option get cron --format=json | head -c 400      # список cron, який ніколи не очищується, — ознака проблеми

WordPress зберігає тимчасові дані (transients), сесії та автоматично завантажувані параметри, що залишилися від видалених плагінів, у wp_options. Під час кожного завантаження сторінки WordPress зчитує всі записи з увімкненим автозавантаженням.

На сайті, де за час його існування встановили та видалили десяток плагінів, розмір таких даних нерідко сягає десятків мегабайт:

wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS mb
             FROM wp_options WHERE autoload='yes';" --allow-root

Якщо розмір перевищує приблизно 1 МБ — уже варто зайнятися очищенням. Якщо більше ніж 5 МБ — найімовірніше, ви знайшли свою проблему.

3. Яка версія PHP використовується насправді?

Не та, що вказана в панелі керування, а та, на якій справді працює сайт.

PHP 8.3 приблизно вдвічі швидший за PHP 7.4 на типових навантаженнях WordPress, а підтримка безпеки PHP 7.4 завершилася ще у 2022 році.

wp eval 'echo PHP_VERSION;' --allow-root

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

4. Знайдіть плагін, який створює навантаження

Query Monitor дозволяє визначити, який саме плагін запускає запити до бази даних і повільні обробники.

Типові підозрювані — віджети схожих публікацій, лічильники «популярне за тиждень», засоби перевірки битих посилань, плагіни статистики, що записують окремий рядок під час кожного перегляду сторінки, та плагіни безпеки, які виконують перевірки під час кожного запиту.

Будь-який із них за вимкненого кешу може додати 300 мс до завантаження кожної сторінки. А плагіни статистики можуть продовжувати створювати навантаження навіть за ввімкненого кешу, оскільки для їхньої роботи запит має дійти до PHP.

Вимикайте підозрілі плагіни по одному на staging-копії сайту та проводьте вимірювання після кожної зміни. Не варто експериментувати з цим безпосередньо на робочому сайті о шостій вечора.

5. І лише тепер підозрюйте сусідів на сервері

Віртуальний хостинг передбачає спільне використання ресурсів CPU та дискової підсистеми.

Якщо сайт працює швидко о третій ночі й повільно опівдні, а перші чотири причини ви вже виключили, тоді справді можливо, що ви конкуруєте з іншими користувачами за ресурси.

У цьому випадку важливі ліміти CPU та I/O вашого контейнера й те, чи досягаєте ви цих обмежень. Нормальна панель керування має показувати обидва показники.

Якщо сайт постійно досягає власного ліміту CPU, йому потрібен потужніший тариф або необхідно зменшити обсяг роботи, що виконується під час кожного запиту. Якщо ж сам сервер постійно перевантажений незалежно від навантаження вашого сайту, імовірно, хостинг-провайдер розмістив на ньому забагато клієнтів.

На тарифах inSave кожен сайт працює у власному контейнері зі своїми лімітами CPU, RAM та I/O, тому навантаження сусіднього сайту не може забрати ресурси вашого проєкту настільки, щоб вивести його з ладу. Панель при цьому показує, наскільки близько сайт перебуває до встановлених обмежень.

LiteSpeed і LSCache доступні на всіх тарифах, що для більшості сайтів одразу вирішує перший пункт із цього списку. А починаючи з Shared Pro також доступний об’єктний кеш Redis.

Коротко

Спочатку кеш, потім база даних, версія PHP, плагіни — і лише після цього сусіди на сервері.

Чотири з п’яти цих проблем можна виправити самостійно практично на будь-якому хостингу. Саме тому порада «переїхати на швидший хостинг» так часто розчаровує: новий сервер запускає той самий неоптимізований і ресурсоємний код — тільки тепер за більші гроші.