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