Як пришвидшити WordPress: від хостингу до бази даних
Спершу виміряйте, потім виправляйте стек знизу вгору: PHP і серверний кеш, зображення, плагіни, база даних і сторінки WooCommerce, які не можна кешувати.

Більшість повільних сайтів на WordPress гальмують зовсім не з тієї причини, про яку думають їхні власники. Перш ніж ставити черговий плагін, проведіть вимірювання. Час до першого байта (TTFB) показує, скільки серверу потрібно, щоб сформувати HTML; якщо на закешованій сторінці він перевищує приблизно 600 мс, проблема на боці сервера. Largest Contentful Paint (LCP) показує, коли на екрані справді з’являється основний контент, і добрим результатом Google вважає до 2,5 секунди. Запустіть PageSpeed Insights, щоб побачити дані реальних відвідувачів, а потім WebPageTest або вкладку «Мережа» в браузері, щоб зрозуміти, що і в якому порядку завантажується. Запишіть цифри: кожна зміна нижче має покращувати одну з них, а якщо не покращує — відкотіть її.
Починайте з нижнього рівня стека, бо жоден плагін не виправить повільний сервер. Спершу перевірте версію PHP: WordPress на PHP 8.x працює помітно швидше, ніж на 7.x, а версії, нижчі за 8.2, уже не отримують виправлень безпеки. Переконайтеся, що ввімкнено OPcache: тоді PHP тримає скомпільований код у пам’яті й не розбирає ті самі файли під час кожного запиту. Має значення і диск: WordPress читає сотні дрібних файлів на кожну сторінку, і NVMe справляється з цим значно краще, ніж SATA SSD. Але найбільший виграш дає кеш на рівні сервера, коли вебсервер віддає збережену сторінку, взагалі не запускаючи PHP.
Тут вибір тарифу зустрічається з вибором плагіна кешування. На нашому хостингу для WordPress анонімні відвідувачі отримують закешовану сторінку безпосередньо від вебсервера, а PHP працює лише для авторизованих користувачів і надсилання форм, тож завдання плагіна зводиться до того, щоб скидати кеш потрібних сторінок після публікації. На хостингу без серверного кешу статичні HTML-файли натомість записує плагін — WP Super Cache, W3 Total Cache або WP Rocket. Оберіть один, а не два: кілька плагінів кешування конфліктують через ті самі правила й віддають застарілі або зламані сторінки. Якщо сервер працює на LiteSpeed, зазвичай найкраще підходить його власний плагін.
Зображення зазвичай найважча частина сторінки — і найпростіша для виправлення. Конвертуйте завантаження у WebP або AVIF: за тієї ж візуальної якості вони, як правило, на 25–50% менші за JPEG, а WordPress підтримує WebP з версії 5.8 і AVIF з версії 6.5. Не завантажуйте фотографію завширшки 4000 пікселів, щоб показати її у 800: WordPress створює кілька розмірів і через srcset дає браузеру вибрати потрібний, але лише якщо тема коректно виводить розміри зображень. Вбудоване ліниве завантаження відкладає зображення нижче першого екрана, проте головне зображення має завантажуватися одразу — ліниве завантаження елемента LCP є одним із найпоширеніших способів погіршити цю метрику.
Кожен активний плагін додає PHP-код, а чимало з них — ще й запити до бази, скрипти та стилі на кожну сторінку, потрібні вони там чи ні. За допомогою Query Monitor з’ясуйте, які плагіни забирають найбільше часу, вимкніть непотрібні, а під час наступного редизайну замініть тему на конструкторі сторінок легкою блоковою темою. Потім почистьте базу даних. Опції з автозавантаженням читаються під час кожного запиту, тому тримайте їхній загальний обсяг помітно меншим за мегабайт і видаляйте залишки від видалених плагінів. Обмежте кількість ревізій у wp-config.php, видаляйте прострочені транзієнти й доручіть це WP-CLI або плагіну очищення за розкладом, а не один раз.
WooCommerce змінює правила, бо найважливіші його сторінки кешувати не можна. Кошик, оформлення замовлення та особистий кабінет у кожного відвідувача свої, тому їх треба виключити зі сторінкового кешу, інакше один покупець може побачити кошик іншого. Отже, на кожному кроці покупки PHP і база даних виконують реальну роботу. Постійний об’єктний кеш, наприклад Redis, зберігає результати повторюваних запитів у пам’яті, а High-Performance Order Storage переносить замовлення із загальної таблиці записів в окремі таблиці. Тариф WP Pro сам налаштовує об’єктне кешування та винятки для кошика й оформлення замовлення — це мінімум, потрібний магазину, щоб залишатися швидким.
Якщо все це зроблено, а адмінка досі гальмує, оформлення замовлення сповільнюється під час акцій або TTFB стрибає залежно від часу доби, вузьке місце вже не в налаштуваннях, а в спільних ресурсах процесора. Це момент перейти з хостингу для WordPress на преміум-хостинг, де ядра CPU і пам’ять зарезервовані лише за вашим сайтом, резервні копії створюються щогодини, а звернення одразу потрапляють до старшого інженера. Тариф Premium S коштує від €24.99 на місяць. У WebHostFlow перехід відбувається на місці — той самий акаунт, ті самі шляхи, та сама IP-адреса, — тож наступного дня можна знову все виміряти й перевірити, чи змінилися цифри.
