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