Логи, cron, резервные копии, боты, PHP и SQL как последовательные уровни диагностики нагрузки.
Высокий CPU на хостинге — симптом, а не диагноз. Причиной могут быть реальные посетители, боты, cron, резервные копии, тяжёлый SQL или PHP-код.
До начала работ
Скорость нельзя диагностировать одним баллом Lighthouse. Я бы разделял серверное время, загрузку ресурсов, отрисовку, JavaScript и реальные пользовательские метрики.
- Проверить версии PHP, WordPress и критических плагинов на совместимость.
- Сопоставить пик CPU с конкретным временем в access/error logs.
- Настроить мониторинг.
- После исправления повторить тот же сценарий и сравнить профиль нагрузки.
Как я бы прошёл эту задачу
- Измерить ресурсы и long tasks.
- Настроить мониторинг.
- Разделить backend latency и frontend rendering.
- Зафиксировать URL, устройство и время проблемы.
- Посмотреть access/error logs.
- Проверить SQL, cron, backup и bots.
Точки риска по дороге
PageSpeed полезен для диагностики, но зелёный балл не заменяет реальную производительность. Нужно разделять backend, frontend и бизнес-сценарии.
- удаление скриптов без проверки функций
- несколько кеш-плагинов
- игнорирование cron и backups
Кеш и CDN не исправят тяжёлый PHP-запрос, бесконечный cron или несколько мегабайт JavaScript на первом экране.
Проверка на реальном сценарии
Перед публикацией я бы повторил не только изменённый шаг, но и соседние сценарии: мобильную версию, формы, аналитику, интеграции и страницы того же шаблона.
- slow SQL
- TTFB
- CPU/RAM
- LCP/INP/CLS
Когда работу можно считать законченной
После работы должны остаться понятные доступы, зафиксированные изменения и способ повторно проверить результат.
Если эту задачу нужно внедрить, а не только разобрать
Можно собрать план внедрения, проверить зависимости и довести изменение до работающего production-сценария.