Рефакторинг ради скорости: как найти реальную причину высокого CPU и медленных страниц

Access/error logs, cron, резервные копии, боты и тяжёлые запросы как основные направления диагностики.

Запрос «переделать сайт» почти никогда не является техническим заданием. За ним могут скрываться устаревший дизайн, плохая конверсия, медленная работа, неудобная админка, SEO-проблемы или код, который страшно менять.

Симптом и причина — не одно и то же

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

Что проверить в первую очередь

• После исправления повторить тот же сценарий и сравнить профиль нагрузки.
• После релиза мониторить ошибки, формы, нагрузку и SEO.
• Не считать среднее за месяц объяснением короткого пика.
• Снять карту темы, плагинов, БД, PHP, cron и интеграций.
• Сохранить работающие URL и данные до изменений.

Как сузить круг причин

Рефакторинг я бы начинал с инвентаризации: что уже работает, откуда приходит трафик, какие интеграции завязаны на старый код и какие изменения стали дорогими.

Старый сайт не обязательно выбрасывать. Иногда выгоднее сохранить URL, данные и работающие интеграции, меняя проблемные слои постепенно. В других случаях чистая миграция дешевле спасения legacy.

Чего я бы не делал на старте

• проверять после релиза только главную
• менять URL без SEO-карты
• править production без staging
• обновлять всё одновременно

Самая дорогая ошибка — начать с полного переписывания, не сохранив URL, аналитику, формы, данные и рабочие сценарии.

Что сравнить после исправления

• нагрузка
• частота регрессий
• PHP/JS ошибки
• время типовой правки

Хороший рефакторинг заметен не эффектом, а тем, что сайт перестаёт ломаться от каждой следующей задачи.