Админка и витрина WordPress тормозят: что ускорить в первую очередь

Редактор открывает запись — и ждёт. Менеджер правит товар — спиннер крутится минуту. Клиент на витрине видит белый экран, пока подтягиваются скрипты и тяжёлые изображения. PageSpeed красный, реклама дорожает, команда винит «хостинг», хостинг винит «плагины».

Медленный WordPress редко лечится одной галочкой. Обычно это сумма: слабый тариф, отсутствие кэша, тяжёлая тема, десяток плагинов «на всякий случай», неоптимизированные медиа и запросы к базе без индексов. Важно не ускорять всё сразу, а снять самые дорогие тормоза по порядку.

Два разных тормоза

Витрина и админка — разные миры. Кэш страниц спасает гостя и почти не помогает редактору в `/wp-admin`. Если команда страдает в админке, смотрят CPU, PHP, автозагрузки плагинов, размер базы и внешние HTTP вызовы из плагинов при каждом клике.

Если страдает только витрина — кэш, CDN, картинки, JS/CSS, TTFB хостинга. Путать эти контуры — тратить недели не на ту боль.

Типичные сценарии

После «невинной» установки плагина конструктора админка стала тяжёлой для всех. На витрине всё ещё терпимо благодаря кэшу.

Интернет-магазин: карточки с кучей скриптов отзывов, чатов и пикселей. Core Web Vitals падают, особенно на мобиле.

Общий хостинг: соседи по серверу периодически съедают CPU. Ночью быстро, в час пик — беда. Плагины ни при чём, виновата модель размещения.

Ошибки ускорения

Ставить три кэш-плагина сразу и удивляться белому экрану.

Сжимать картинки, не трогая TTFB и тяжёлые SQL.

«Оптимизировать» прод без бэкапа и без теста на копии.

Гнаться за 100 баллами PageSpeed в ущерб нужным скриптам аналитики без договорённости с маркетингом.

Порядок работ, который обычно окупается

1. Измерить. TTFB, время админки, вес главной, список плагинов, медленные запросы. Без цифр спорят вкусами.

2. Хостинг и PHP. Актуальная версия PHP, достаточно CPU/RAM, нормальный диск. На микротарифе чудес не будет.

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

4. Кэш витрины. Page cache, object cache где уместно, исключить корзину и личный кабинет. Проверить, что кэш реально HIT.

5. Медиа и фронт. Современные форматы изображений, ленивая загрузка, меньше блокирующего JS, критичный CSS без фанатизма.

6. База. Ревизии, авточерновики, раздутые таблицы, индексы для тяжёлых выборок магазина.

Для админки отдельно: ограничить автозагрузку тяжёлых плагинов, почистить `wp_options` autoload, убрать внешние API вызовы из критичного пути редактирования.

• сначала копия сайта и бэкап;
• один эксперимент за раз;
• после каждого шага — замер, не ощущения;
• фиксировать, что изменили, чтобы уметь откатить.

Как не ускорять вслепую

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

Отключайте плагины не на бою, а на копии. На проде максимум — точечные безопасные шаги после проверки. Сломанная витрина ради эксперимента с кэшем обнуляет выигрыш.

Поговорите с маркетингом заранее: какие скрипты аналитики обязательны. Иначе «оптимизация» сорвёт атрибуцию и вы получите внутренний конфликт вместо ускорения.

Если после базовых шагов админка всё ещё тяжёлая, смотрите хостинг и внешние API плагинов. Иногда единственное честное решение — сильнее тариф или отказ от плагина, который на каждый клик ходит в интернет.

План на 30 дней без большого взрыва

Неделя 1: замеры, бэкап, копия, инвентаризация плагинов и темы. Неделя 2: хостинг/PHP и удаление явного мусора плагинов. Неделя 3: кэш витрины и медиа. Неделя 4: база и тонкая настройка админки.

После каждого этапа фиксируйте цифры и оставляйте сайт стабильным. Так команда видит прогресс и не живёт в перманентном «сейчас ещё чуть-чуть починим».

Если магазин на тяжёлых конструкторах, честно оцените стоимость переноса критичных шаблонов на более лёгкую схему. Иногда это единственный путь к нормальным Core Web Vitals.

Не обещайте «как у стартапа на статике». Обещайте измеримое улучшение операций команды и загрузки витрины — и выполняйте по плану.

Отдельно разберите тяжёлые операции: импорт товаров, массовые правки, отчёты. Их лучше уводить в off-peak и на более сильный тариф или очередь, а не заставлять всю админку страдать весь день.

Проверьте объектный кэш и автозагрузку опций: раздутый autoload делает каждый запрос дороже и особенно заметен редакторам. Это частая «невидимая» причина медленной админки.

Если сайт мультиязычный или с большим каталогом, кеширование должно учитывать вариации страниц. Неправильные ключи кэша дают либо промахи, либо опасную перепутанную выдачу.

Не смешивайте эксперименты: не меняйте тему, кэш и хостинг в один день. Иначе невозможно понять, что дало эффект, а что сломало checkout.

Для редакции полезен отдельный «лёгкий» режим работы: меньше визуальных конструкторов на служебных страницах, меньше тяжёлых виджетов в админ-дашборде. Админка должна помогать работать, а не демонстрировать все плагины сразу.

Если после базовых оптимизаций витрина быстрая, а админка нет — не продолжайте крутить PageSpeed. Сфокусируйтесь на PHP, базе и плагинах админского пути. Разные боли требуют разных инструментов.

Зафиксируйте целевые цифры: открытие списка записей, сохранение товара, LCP главной. Работа без целей снова превратится в бесконечные «чуть быстрее».

Итог

Когда тормозят и админка, и витрина, нельзя лечить это «ещё одним плагином ускорения». Нужны замеры, порядок: среда → плагины → кэш → фронт → база, и понимание, какая боль чья.

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