WordPress стал медленным после изменения: как локализовать регрессию
Модельный разбор без заявлений о клиентском результате: после обновления плагина главная иногда отвечает быстро, а иногда задерживает HTML на несколько секунд.
Для кого
Владелец WordPress, разработчик или администратор Linux-хоста
Исходная ситуация
Что произошло
PageSpeed меняется от запуска к запуску, изображения оптимизированы, но пользователи всё равно ждут начало загрузки. Нужно отделить TTFB от frontend и найти временную связь.
Какие сигналы нужны
TTFB по времени
Серия замеров показывает частоту и длительность медленных ответов.
PageSpeed/CrUX
Лабораторный тест и реальные пользователи отвечают на разные вопросы и не смешиваются в один score.
CPU, RAM и диск
Серверные метрики помогают проверить очередь PHP-FPM, память и конкуренцию с backup/cron.
Последовательность разбора
Собрать базовую линию
Сравнить один набор URL, холодный и прогретый кеш, медиану и высокий перцентиль.
Найти окно деградации
Сопоставить медленный TTFB с cron, релизом, PHP-FPM и запросами базы.
Проверить на staging
Менять один фактор за раз и не отключать плагины вслепую на production.
Закрепить результат
Повторить тот же набор замеров и оставить регулярный контроль.
Что меняется в процессе
Результат без выдуманных процентов
- разделение backend TTFB и полной загрузки страницы
- воспроизводимый набор URL и условий проверки
- гипотеза подтверждается профилировщиком и логами, а не одним графиком
- регрессия после следующего изменения становится заметнее
Проверьте сценарий на своём объекте
Добавьте URL или Linux-сервер, соберите базовую линию и убедитесь, что уведомления доходят до ответственного до настоящего инцидента.