Headless-режим WordPress: архитектурные последствия

Сборка статического фронтенда на 10 000 записей начинается минимум со ста запросов к REST API: больше 100 объектов за раз он не отдаёт. Это самая безобидная цена headless-режима. Дороже обходятся предпросмотр черновиков, SEO-метаданные, формы и поиск: всё, что раньше делали тема и плагины, придётся строить заново. Речь о WordPress 6.x; контентные эндпоинты REST API входят в ядро с версии 4.7.

Что вы отделяете на самом деле

В классической схеме WordPress делает всё сам: хранит контент, разбирает URL, подбирает шаблон, собирает HTML, подключает скрипты плагинов. В headless остаются хранение и админка. Всё остальное уходит во фронтенд на Next.js, Nuxt, Astro или свой код.

Вместе с рендерингом уезжает неочевидное:

• маршрутизация и пермалинки: структура URL теперь в коде фронтенда;
• SEO-метаданные и sitemap: отдаёт ли плагин свои поля через API, зависит от плагина;
• поиск, формы, комментарии: обработка остаётся в WordPress, интерфейс и защита от спама на вас;
• предпросмотр черновиков;
• скрипты и стили плагинов: они подключаются через тему и в ответ API не попадают.

Выбор между REST и WPGraphQL здесь не разбираем: исходим из REST, он есть в ядре без плагинов.

Как меняется нагрузка

Кеш HTML больше не работает

Раньше полностраничный кеш закрывал основной трафик: посетитель получал готовый HTML, PHP не запускался. Теперь к WordPress ходит фронтенд, и каждый запрос к API мимо кеша поднимает ядро со всеми активными плагинами. Тяжёлые плагины замедляют ответ так же, как раньше замедляли генерацию страницы. Кешировать теперь нужно сами ответы API: в Nginx, на CDN или во фронтенде. Инвалидация кеша при публикации тема отдельная; без неё вы выбираете между устаревшим контентом и шквалом запросов.

Сборка и лишние запросы

Лимит в 100 объектов на выдачу задаёт ядро; общее число записей и страниц приходит в заголовках X-WP-Total и X-WP-TotalPages. Дальше начинается N+1: автор, рубрики и миниатюра приходят идентификаторами. Параметр _embed встраивает связанные объекты в тот же ответ, но раздувает его, а _fields оставляет только нужные поля. Работайте с обоими и проверяйте итоговый размер ответа.

Три схемы отдачи страниц нагружают WordPress по-разному:

Пояснение. ISR (инкрементальная регенерация): страница отдаётся из кеша как статика, а по истечении срока или по сигналу о публикации пересобирается в фоне. Так механизм называется в Next.js.

Что мерить до и после

Универсальных цифр здесь нет: время ответа зависит от плагинов, хостинга и размера выдачи, а выдуманное число хуже честного «замерьте». Мерьте на одном железе и с одинаковой параллельностью, до миграции и после:

1. TTFB списка записей на холодном и прогретом кеше, с _embed и без;
2. время полной сборки при текущем числе записей и при удвоенном: так виден характер роста;
3. p95 ответа API во время сборки, когда фронтенд ходит в несколько потоков;
4. долю попаданий в кеш API и число запросов, дошедших до PHP;
5. время от кнопки «Опубликовать» до появления страницы на сайте: редакторы заметят его первыми.

Редакторский контур

Предпросмотр

Черновики REST API публично не отдаёт, нужна аутентификация. Значит, фронтенду нужен маршрут предпросмотра, который запрашивает черновик на сервере. В ядре с версии 5.6 для этого есть пароли приложений (Application Passwords). Учётные данные должны жить только на сервере фронтенда: попадут в браузерный код, и любой посетитель получит доступ с правами этого пользователя.

Контент и блоки

Поле content.rendered отдаёт HTML после всех фильтров WordPress, а ссылки в нём ведут на домен WordPress, не фронтенда: их придётся переписывать. Шорткоды плагинов уже раскрыты, но их скрипты и стили вы не получите. Сырое содержимое (content.raw) доступно только в контексте редактирования, то есть после аутентификации.

Безопасность и SEO

Поверхность атаки меняется, а не исчезает. Проверьте перед запуском:

• эндпоинт /wp-json/wp/v2/users публично отдаёт авторов опубликованных записей, а slug часто совпадает с логином; ограничьте эндпоинт, если авторы не должны быть публичными;
• старый публичный домен WordPress: если он открыт, поисковик найдёт дубли страниц, закройте его или настройте редиректы на фронтенд;
• sitemap и robots.txt теперь за фронтендом, а встроенная карта сайта WordPress по умолчанию указывает на домен WordPress.

Headless не убирает WordPress из системы. Он убирает из системы всё, что WordPress делал молча.

Где подход ломается

Три сценария, в которых отделённый фронтенд стоит дороже, чем даёт:

• магазин на WooCommerce: корзина и оформление заказа завязаны на сессии и куки, а многие платёжные плагины рассчитаны на шаблоны темы. У WooCommerce есть Store API, но покрывает ли он ваши платёжные плагины, проверяйте до старта;
• редакторы собирают страницы визуальным конструктором: он хранит вёрстку в своём формате и зависит от собственных стилей и скриптов, а API отдаст разметку без них;
• небольшой сайт без фронтенд-разработчика: вы получаете два деплоя и два набора обновлений ради выигрыша, который часто даёт кеш и ревизия плагинов.

Что делать дальше

Потратьте день на инвентаризацию раньше, чем начнёте писать фронтенд.

1. Пройдите по активным плагинам и для каждого ответьте, выводит ли он что-то на фронте; отметьте те, у которых нет замены через API.
2. Соберите прототип на одном типе контента, например на записях блога, вместе с предпросмотром.
3. Снимите на нём метрики из раздела выше.
4. Решите, как фронтенд узнаёт о публикации: по расписанию или по сигналу от WordPress.

Если узкое место окажется в плагинах или в отсутствии кеша, headless вам не нужен: эту проблему дешевле решить внутри монолита.