Якщо WordPress різко сповільнився одразу після оновлення, не варто хаотично вимикати все підряд або встановлювати нові «оптимізатори». Спочатку потрібно зафіксувати момент появи проблеми, захистити дані й послідовно визначити компонент, який змінив поведінку сайту.
Аварійна оптимізація має дві мети: швидко повернути прийнятну роботу ресурсу та зберегти достатньо інформації, щоб причина не повторилася після наступного оновлення.
Як зафіксувати падіння швидкості
Запишіть час оновлення, перелік змінених компонентів і сторінки, де затримка найбільша. Перевірте сайт як незалогінений користувач, адміністративну панель, форми й основні операції магазину. Важливо відрізнити загальне перевантаження сервера від повільної роботи конкретної сторінки або функції.
Збережіть журнали помилок, показники навантаження CPU і пам’яті, час відповіді сервера. Якщо після редизайну погіршилися користувацькі метрики, прочитайте, як діяти, коли Core Web Vitals стали червоними.
Пошук конфлікту плагіна або теми
Найбезпечніше перевіряти конфлікт на копії сайту. Якщо проблема критична й копії немає, починайте з компонентів, які щойно оновилися або впливають на кеш, безпеку, редактор і базу даних. Вимикайте по одному, після кожної зміни повторюючи однаковий тест.
Не видаляйте модуль одразу: разом із ним можуть зникнути налаштування. Для теми перевірте дочірню тему, власні фрагменти коду та сумісність із версією PHP.
Очищення кешу й бази даних
Кеш очищують послідовно: плагін, серверний кеш, CDN і браузер. Одночасне очищення всіх рівнів ускладнює діагностику. Після цього перевірте, чи не запускається повторне прогрівання тисяч сторінок і чи не створює воно пікове навантаження.
У базі даних зверніть увагу на завислі завдання cron, надмірні транзієнти, журнали та таблиці плагіна, який оновився. Перед будь-яким очищенням створіть повну копію. Загальний перелік регулярних робіт наведений у матеріалі про те, що входить у технічну підтримку сайту.
Безпечний відкат і повторне оновлення
Якщо причина знайдена, поверніть попередню стабільну версію конкретного компонента або всю резервну копію. Переконайтеся, що після відкату працюють форми, оплата, авторизація та фонова обробка. Лише потім плануйте повторне оновлення на тестовій копії.
Паралельно перевірте, чи не змінилися вимоги до PHP, пам’яті або бази даних. Іноді нова версія просто виявляє обмеження старого хостингу. Якщо потрібна перебудова важких візуальних компонентів, можна залучити фахівців із веброзробки та дизайну.
Головне правило аварійної оптимізації — кожна дія має бути зворотною. Коли сайт знову працює стабільно, зафіксуйте причину, версії та порядок відновлення. Це скоротить наступний інцидент із годин до хвилин.