Зафиксировать обновление
Какие версии плагинов, темы, WordPress или PHP поменялись.
Практическая диагностика · WordPress
WordPress стал медленно работать после обновления: что проверить
Если сайт замедлился сразу после обновления, не нужно начинать с абстрактной «оптимизации». Сначала связываем изменение с конкретным компонентом: плагином, темой, PHP, базой, кешем или внешним API.
Быстрый маршрут
Что проверить за первые 5 минут
Нам важна точка до/после: что изменилось и какие страницы стали медленнее.
Сравнить страницы
Медленно всё или только админка, каталог, поиск, checkout.
Проверить TTFB
Если HTML приходит медленно, проблема чаще на backend.
Посмотреть ресурсы
CPU, RAM, MySQL, PHP-FPM и фоновые процессы.
Проверить внешние вызовы
Новый плагин может ждать API, лицензирование или SMTP.
После обновления скорость нужно сравнивать по компонентам.Если замедление появилось в тот же момент, первым кандидатом является изменившийся код или окружение.
Шаг 1
Составьте список изменений, а не «оптимизируйте всё»
Обновление может затронуть десятки пакетов. Фиксируем версии до и после, время deploy и наличие изменений PHP/MySQL. Если есть snapshot, он помогает сравнить без догадок.
Особенно полезно знать, началась ли проблема после обновления одного плагина или после общего автообновления ночью.
Шаг 2
Отделите долгий ответ сервера от тяжёлого браузера
Если TTFB вырос с условных сотен миллисекунд до нескольких секунд, ищем PHP, базу, кеш и внешние вызовы. Если HTML приходит быстро, а страница зависает в браузере — смотрим JavaScript, изображения и новые frontend-ресурсы.
Не смешиваем эти два сценария: уменьшение изображений не исправит SQL-запрос на 4 секунды.
Шаг 3
Проверьте новые запросы, cron и хуки после обновления
Плагин может добавить тяжёлый запрос в каждый page load, запустить миграцию базы, пересчитать индекс или начать обращаться к внешнему сервису. Иногда замедление временное, пока выполняется фоновая перестройка.
Смотрим логи, Query Monitor на тестовой копии, slow query и расписание cron. На production не стоит бесконтрольно включать тяжёлую отладку.
Шаг 4
Обновление могло сбросить или обойти кеширование
После смены темы/плагина page cache может перестать применяться к части URL, object cache — потерять соединение, а CDN — начать считать каждый запрос уникальным из-за новых cookie.
Сравниваем заголовки cache HIT/MISS, поведение для авторизованного и обычного пользователя, а также наличие постоянных query-параметров.
Шаг 5
Проверьте базу данных и очереди после обновления
WooCommerce и крупные плагины могут создавать фоновые задачи и обновлять схему данных. Пока очередь не завершена, CPU и база работают заметно тяжелее.
Смотрим рост таблиц options, autoload, action scheduler, медленные SQL и блокировки. Если нагрузка стабильно остаётся высокой после завершения фоновых задач, ищем регрессию в коде.
Практический пример
После обновления WooCommerce карточки стали открываться по 4–5 секунд
Главная остаётся быстрой, а товары и корзина замедлились. PageSpeed на главной почти не изменился, поэтому общая проверка сайта не показывает проблему.
Замер TTFB по шаблонам показывает регрессию только у WooCommerce. В slow query видим новый тяжёлый запрос от обновлённого расширения, а object cache для этой ветки перестал попадать в HIT. Исправляем конфликт и повторяем замеры.
| Измерение | Что видно |
|---|---|
| Главная TTFB | без изменений |
| Карточка товара | рост в несколько раз |
| Slow query | новый запрос после update |
| Cache | MISS на проблемной ветке |
Типовые сценарии
Как локализовать замедление
Разные симптомы после обновления почти всегда ведут в разные слои.
| Симптом | Вероятная зона | Первое действие |
|---|---|---|
| Медленно только в админке | plugin hooks/API/cron | проверить admin requests и внешние вызовы |
| Медленно только товары | WooCommerce/SQL | профилировать запросы карточек |
| TTFB высокий везде | PHP/DB/cache | проверить FPM, MySQL, page cache |
| HTML быстрый, интерфейс тормозит | JS/CSS | проверить Network и main thread |
| Нагрузка высокая после update | миграция/очередь | посмотреть cron и background jobs |
Чего не делать
Типичные действия, которые мешают диагностике
Ставить ещё один «ускоряющий» плагин
Новый слой может скрыть причину и добавить конфликт.
Откатывать весь сайт без фиксации изменений
После восстановления не будет понятно, какой компонент виноват.
Чистить базу случайным оптимизатором
Можно удалить нужные transient/данные и не исправить медленный запрос.
Смотреть только PageSpeed
Лабораторный балл не показывает PHP/SQL-причину сам по себе.
Чек-лист
Проверка WordPress после обновления
- Зафиксировать версии: Что изменилось непосредственно перед замедлением.
- Сравнить типы страниц: Frontend, admin, товары, поиск.
- Измерить TTFB: Backend или браузер.
- Проверить PHP-FPM: Воркеры и очереди.
- Проверить базу: Slow query, autoload, locks.
- Проверить cron: Фоновые миграции и задачи.
- Проверить кеш: HIT/MISS и object cache.
- Проверить внешние API: Нет ли долгих ожиданий.
- Точечно откатить кандидат: На snapshot/тестовой копии.
- Измерить снова: Подтвердить улучшение тем же методом.
Когда нужен доступ к проекту
Какие данные ускоряют диагностику
Если причина находится в SQL, PHP-FPM или object cache, потребуется доступ к серверу и тестовая копия. Отключать коммерческие плагины на живом магазине без snapshot рискованно.
Передавать пароли в текст статьи или публичную переписку не нужно. Для рабочей диагностики доступы выдаются отдельно и только к тем системам, которые действительно нужны для проверки.
Вопросы
Короткие ответы
Почему сайт тормозит только после входа в админку?
Для авторизованных пользователей page cache обычно не работает, поэтому проявляется реальная нагрузка PHP/DB.
Можно ли просто увеличить сервер?
Это может временно скрыть проблему, но регрессия кода останется.
Поможет ли очистка кеша?
Иногда после обновления, но если кеш перестал применяться, простая очистка не исправит конфигурацию.
Нужно ли откатывать обновление?
Если найден конкретный виновник и откат безопасен — да как временную меру, затем планировать совместимое обновление.