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