Сайт тормозит: как найти причину, а не просто поставить кеш-плагин

Диагностика сервера, SQL, PHP, JavaScript, изображений и сторонних скриптов вместо универсального кеш-плагина.

Высокий CPU на хостинге — симптом, а не диагноз. Причиной могут быть реальные посетители, боты, cron, резервные копии, тяжёлый SQL или PHP-код.

Не чинить то, что ещё не диагностировано

Один и тот же внешний симптом может появляться по разным причинам. Сначала стоит записать конкретный сценарий: URL, устройство, шаг, момент появления и последние изменения.

Первые проверки без переделки сайта

• Разделить backend latency и frontend rendering.
• Измерить long tasks и блокировку главный поток.
• Посмотреть access/error logs.
• Не хранить глобальное состояние там, где достаточно локального компонента.
• Зафиксировать URL, устройство и время проблемы.

Что чаще оказывается источником

Скорость нельзя диагностировать одним баллом Lighthouse. Я бы разделял серверное время, загрузку ресурсов, отрисовку, JavaScript и реальные пользовательские метрики.

PageSpeed полезен для диагностики, но зелёный балл не заменяет реальную производительность. Нужно разделять backend, frontend и бизнес-сценарии.

Популярные ложные решения

• высокий CPU = много клиентов
• удаление скриптов без проверки функций
• оптимизация только главной
• игнорирование cron и backups

Кеш и CDN не исправят тяжёлый PHP-запрос, бесконечный cron или несколько мегабайт JavaScript на первом экране.

Проверка после исправления

• slow SQL
• LCP/INP/CLS
• TTFB
• CPU/RAM

Оптимизация считается удачной, когда быстрее становится реальный сценарий пользователя, а не только лабораторный отчёт.