Сайт периодически падает: как отличить проблему хостинга от проблемы кода

Лимиты CPU/RAM и процессов, медленные запросы, cron, резервные копии, боты и всплески реального трафика.

Фраза «сайт тормозит» может означать медленный серверный ответ, тяжёлую базу, большой JavaScript, изображения, сторонние виджеты или интерфейс, зависающий после клика. Ускорение начинается с измерения.

Сначала зафиксировать симптом

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

С чего я бы начал проверку

• Перед крупной правкой фиксировать точку возврата.
• Посмотреть access/error logs.
• Не считать среднее за месяц объяснением короткого пика.
• Настроить мониторинг.
• Разделить backend latency и frontend rendering.

Где обычно находится причина

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

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

Что легко сделать хуже

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

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

Как понять, что проблема решена

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

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