Чек-лист відлагодження продуктивності WordPress

Повільний сайт на WordPress рідко буває повільним із загадкової причини. Майже в кожному випадку, куди нас кличуть, причина одна з п'яти, і найшвидший шлях до відповіді — перевірити їх по черзі, а не купувати більший сервер.

Виміряйте, перш ніж щось чіпати. Відкрийте сторінку з інструментами розробника і запишіть два числа: час до першого байта і час появи найбільшого елемента. Повільний перший байт — це проблема сервера: PHP, база, зовнішнє API. Швидкий перший байт із повільною сторінкою — проблема фронтенду: картинки, шрифти, скрипти. Ці два шляхи майже не мають спільних рішень, тож помилка в здогадці коштує дня.

Якщо повільний сервер, поставте Query Monitor і подивіться на потрібну сторінку. Він покаже кількість запитів, найповільніший із них, HTTP-звернення під час рендерингу і плагін, який їх зробив. Звичні винуватці:
— плагін, що ходить у зовнішнє API на кожному завантаженні сторінки без кешу й без таймауту;
— запит по meta-полю без індексу на таблиці в сотні тисяч рядків;
— автозавантажувані опції, що розрослися до кількох мегабайтів;
— тема, що виконує `wp_query` у циклі замість одного запиту з `post__in`.

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

На фронтенді здобутки нудні й надійні: віддавайте картинки у WebP того розміру, у якому вони показані, ставте явні width і height, ліниво вантажте все нижче першого екрана, розміщуйте шрифти в себе й робіть preload лише для того, що вгорі сторінки. Головна картинка, експортована шириною 4000 пікселів, коштує дорожче за всі плагіни разом.

До хостингу переходьте востаннє, коли вже знаєте, що робить застосунок. Об'єктний кеш на Redis допомагає сайту з великою кількістю дрібних запитів; більше CPU допомагає сайту з важким PHP; ані те, ані інше не допоможе сайту, що чекає на чуже API.

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