WordPress повільний лише після входу: admin-ajax, Heartbeat і кеш

Різниця між швидкістю для гостя й авторизованого користувача — важлива діагностична підказка. Публічний відвідувач часто отримує вже готовий HTML зі сторінкового або edge-кешу. Після входу WordPress повинен зібрати сторінку динамічно, перевірити сесію, ролі, персоналізовані елементи й виконати код активних плагінів. Тому хороший результат звичайного тесту швидкості не завжди описує реальну роботу редактора, менеджера магазину або адміністратора.

Спочатку відтворіть точний сценарій

Не змішуйте в одному вимірюванні фронтенд, wp-admin і редактор. Зафіксуйте роль користувача, сторінку, дію, час і браузер. Перевірте ту саму адресу в приватному вікні та після входу. Якщо різниця стабільна, порівняйте TTFB, загальний час, кількість запитів і найдовші мережеві операції.

Інструменти браузера допомагають побачити, чи очікування виникає до отримання HTML, під час завантаження JavaScript або після фонових запитів. Серверні журнали та профілювання потрібні, щоб зв’язати повільний HTTP-запит із PHP, базою або зовнішнім сервісом.

Чому сторінковий кеш змінює картину

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

Офіційний посібник WordPress про кешування розділяє browser, object і server cache. Вони вирішують різні задачі. Додавання сторінкового кешу не виправить повільний запит у wp-admin, а persistent object cache не компенсує невдалу бізнес-логіку.

Перевірте admin-ajax.php

WordPress-плагіни використовують AJAX для автозбереження, пошуку, фільтрів, перевірки форм, імпорту й багатьох фонових дій. Офіційна документація пояснює, що стандартні WordPress AJAX-запити проходять через wp-admin/admin-ajax.php. Сам файл не є проблемою: важливо, яка action викликається, як часто й що робить серверний callback.

У Network знайдіть повторювані запити до admin-ajax.php, перегляньте параметр action, тривалість і відповідь. Далі визначте плагін або тему, що реєструє обробник. Типові причини — важкий запит без індексу, завантаження великого обсягу даних, синхронний виклик зовнішнього API або дія, яка запускається частіше, ніж потрібно.

Heartbeat не потрібно вимикати навмання

Heartbeat API — вбудований механізм періодичного обміну даними, який підтримує автозбереження, блокування редагування й інші майже реальні оновлення. На сервері він також обробляється через admin-ajax. Якщо сторонній код додає важку операцію до кожного heartbeat, навантаження множиться на кількість активних користувачів.

Повне відключення може зламати потрібні функції. Безпечніше спочатку визначити, які дані додаються, де саме працює Heartbeat і чи виправдана частота. Після зміни перевірте автозбереження, спільне редагування та сценарії плагінів.

База даних і autoload-опції

Динамічний запит завантажує опції, виконує перевірки прав і звертається до контенту. Надмірні autoload-дані, повторні meta-запити, складні вибірки без індексів і великі transient можуть збільшувати TTFB. Потрібно аналізувати конкретні запити та їхній виклик, а не видаляти записи за розміром.

Persistent object cache може зменшити повторні звернення до бази між запитами. Але кеш повинен бути відновлюваним і не бути єдиним місцем зберігання даних. Спочатку знайдіть джерело навантаження, потім оцініть, чи кеш відповідає профілю сайту й можливостям хостингу.

Cron і loopback-запити

WP-Cron перевіряє заплановані події під час звичайних звернень до сайту. У поточному WordPress запуск cron переноситься на shutdown, щоб менше затримувати HTML, але завислі черги, часті події або повільні callbacks усе одно створюють навантаження. Документація функції wp_cron() описує loopback-механізм запуску.

Перевірте прострочені події, інтервали й тривалість задач. На стабільному сервері системний cron може бути передбачуванішим, але його налаштовують лише після інвентаризації чинних подій.

Зовнішні API та поштові виклики

CRM, ліцензійний сервер, аналітика, курси валют і доставка можуть відповідати повільно. Якщо код чекає їх синхронно під час відкриття сторінки, користувач чекає разом із ним. Запити повинні мати розумний timeout, контроль помилки й кеш там, де дані можна безпечно повторно використати. Некритичну синхронізацію доцільно переносити у фон.

Плагінова діагностика без випадкового вимкнення

Кількість плагінів сама по собі не визначає швидкість. Один обробник може бути важчим за двадцять простих розширень. На live-сайті не вимикайте компоненти без розуміння залежностей. Спочатку зіставте action, hook, PHP-помилку або SQL-запит із конкретним модулем, підготуйте перевірку й внесіть одну малу зміну.

Практичний порядок перевірки

1. Порівняйте гостьовий і авторизований запит до тієї самої сторінки.
2. Відокремте серверний TTFB від проблем JavaScript у браузері.
3. Знайдіть повільні admin-ajax і REST-запити та їхні action/route.
4. Перевірте Heartbeat, cron і зовнішні HTTP-виклики.
5. Профілюйте SQL, autoload-опції та повторювані обчислення.
6. Прив’яжіть проблему до власника коду й підготуйте мінімальне виправлення.
7. Повторіть той самий сценарій після зміни й перевірте журнали.

Для загальної картини прочитайте матеріал про Core Web Vitals. Якщо потрібна серверна діагностика, на сторінці оптимізації швидкості сайту описано наш підхід без універсальних обіцянок.

FAQ

Поширені запитання

Чому тест PageSpeed показує добрий результат, а wp-admin повільний?

PageSpeed переважно оцінює публічну сторінку для неавторизованого відвідувача. wp-admin і сторінки після входу обходять частину кешу та виконують інший код.

Чи потрібно повністю вимкнути WordPress Heartbeat?

Ні. Спочатку визначте, що саме створює навантаження. Повне вимкнення може порушити автозбереження, блокування редагування й функції плагінів.

Чи допоможе persistent object cache?

Може зменшити повторні звернення до бази, якщо сервер його підтримує. Він не виправляє повільний зовнішній API, невдалий SQL або надмірно частий callback.

Чи винен admin-ajax.php?

Це лише стандартна точка входу. Причину потрібно шукати в action, частоті виклику та серверному обробнику конкретного плагіна або теми.

Як перевіряти live-сайт без ризикованого вимкнення плагінів?

Почніть із журналів, Network, профілювання запитів і зіставлення hooks. Вносьте одну малу зміну з визначеним сценарієм перевірки.