Как ускорить сайт на WordPress

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

Что происходит на каждом запросе

Пока нет готового кэша, запрос идёт так. Веб-сервер отдаёт его в PHP. Стартует index.php, подключается wp-load.php, затем wp-settings.php. Это не «отрисовать шаблон». Это полная загрузка приложения.

1. Читается wp-config.php, поднимается соединение с базой.
2. Подключаются must-use плагины, потом каждый активный плагин по списку. У каждого выполняется главный файл: он регистрирует хуки, читает свои настройки из базы, иногда ходит во внешние API.
3. Подключается тема и functions.php. Тема тоже плагин, только обязательный.
4. Проходят хуки plugins_loaded, init, wp_loaded. На init плагины регистрируют типы записей, таксономии, кроны и правила адресов — даже если текущая страница этого не использует.
5. WordPress разбирает URL, делает запросы в базу за записью, меню, виджетами и опциями. Опции часто читаются десятками отдельных запросов, по одной на плагин.
6. Собирается шаблон: шапка, контент, подвал. Конструктор страниц на этом шаге ещё раз рендерит каждый виджет в PHP.
7. В подвале печатаются скрипты и стили, которые плагины поставили в очередь. На страницу попадают файлы плагинов, которые в тексте даже не видны.

Итог одного открытия страницы: PHP разобрал сотни файлов, база ответила на пачку запросов, в HTML уехали чужие CSS и JS. Следующий посетитель запускает тот же цикл с нуля. WordPress не держит приложение запущенным между запросами, как это делает нормальный сервер на фреймворке. Каждый хит — новый процесс и новая полная сборка.

Почему виноваты все плагины сразу

Плагин в WordPress не «спит», пока его блок не понадобился. Если он активен, его код исполняется на каждом запросе: на статье, в корзине, в поиске, в админке, в admin-ajax.php и в wp-cron.php. Отдельного режима «загрузи только то, что нужно этой странице» у ядра нет.

• 01Плагин безопасности проверяет запрос и пишет журнал.
• 02SEO-плагин считает title, каноникал и схему, даже если шаблон их уже задал.
• 03Магазин поднимает сессию корзины на страницах, где корзины нет.
• 04Формы, чат, пиксели и конструктор регистрируют скрипты глобально, а не на одном URL.
• 05Два плагина часто делают одно и то же: два кэша, два слайдера, две оптимизации картинок. Оба всё равно загружаются.

Отключить лишнее полезно, но потолок низкий. Сайт на 15 плагинах уже тащит 15 независимых программ внутри одного ответа. Сайт на 40 плагинах не «чуть медленнее» — он на каждый хит открывает в разы больше PHP-файлов и запросов к базе. Редактор ставит новый плагин, и счётчик растёт без переписывания темы.

Почему кэш и минификация почти ничего не меняют

Плагины кэша, CDN и сжатие CSS уменьшают боль, но не убирают устройство WordPress.

• 01Кэш страницы отдаёт готовый HTML и пропускает PHP только для гостя и только при попадании в кэш. Первый заход, сброс кэша, личный кабинет, корзина, поиск, фильтры и страница с меткой в адресе снова поднимают ядро и все плагины. Кэш ещё и разъезжается: правка в админке не всегда сбрасывает нужные URL.
• 02Объектный кэш (Redis) убирает часть запросов к базе. PHP всё равно читает файлы всех плагинов и гоняет их хуки.
• 03Минификация и объединение JS делают легче уже готовый HTML. Список скриптов, которые плагины успели подключить, от этого не сокращается. Склейка скриптов часто ломает страницу, и её откатывают.
• 04Картинки и ленивая загрузка нужны, но они не трогают время, пока PHP собирает страницу. Если сервер думает 1,5 секунды до первого байта, WebP это не лечит.

Поэтому типичный отчёт PageSpeed у WordPress упирается в одно и то же: долгий ответ сервера, лишний JavaScript, скачки вёрстки из-за виджетов. Это не «плохой хостинг». Это плата за то, что на каждый запрос открывается вся система. Подробнее про сами метрики — в статье как ускорить загрузку сайта.

WordPress — пережиток прошлого

Модель «ядро плюс гора плагинов, и всё это стартует заново на каждый хит» была нормальной, когда страница была статьёй с десятком запросов. Сейчас тот же механизм обслуживает магазины, кабинеты и конструкторы. Ядро тащит код редактора, эмодзи, встраивания и совместимость с темами десятилетней давности. Плагины пишут разные люди и не знают друг о друге. Ускорение превращается в вечную уборку: выключить скрипт, откатить обновление, прогреть кэш, снова смотреть PageSpeed.

Современный фреймворк устроен наоборот. На запрос выполняется только код этого маршрута. Нет общего мешка, куда каждый плагин обязан залезть. Страница собирается из своих компонентов, скрипты подключаются там, где они нужны, а готовый HTML можно отдать с кэша, не поднимая CMS. Админка, каталог и формы пишутся под задачу, а не ставятся пакетом «на всякий случай». Об этом же сравнение — на странице CMS и фреймворки.

Переедем с WordPress на фреймворк

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

• 01Nuxt или Next — если нужен быстрый интерфейс и страницы, которые отдаются уже готовыми.
• 02Laravel — если нужна своя серверная логика, кабинет и интеграции без ядра WordPress.

Каталог, заявки и нужные блоки остаются. Пропадают десятки плагинов, которые раньше стартовали на каждой странице. Как проходит перенос без просадки — на странице перенос сайта на другую систему. Напишите через онлайн-заявку: посмотрим текущий WordPress и скажем, что забрать, а что не тащить за собой.