Headless WordPress под нагрузкой: что ломается первым

Headless WordPress не становится быстрее автоматически: при всплеске трафика первыми могут просесть REST API, сервер базы данных или отдельный фронтенд, а кеширование иногда лишь делает сбой менее заметным. Ниже — разбор архитектуры на примере WordPress 6.x: что проверять под нагрузкой и как понять, за какой частью системы следить в первую очередь.

Что именно нагружается в headless-схеме

В классическом WordPress PHP формирует HTML, а браузер получает страницу с того же сайта. В headless-схеме WordPress обычно остаётся системой управления контентом, а внешний фронтенд получает записи через REST API и сам отдаёт страницы. Фронтенд может работать на отдельном сервере или платформе, а контент — в отдельном WordPress-хостинге.

В итоге у вас не один путь запроса, а несколько:

• посетитель открывает страницу на фронтенде;
• фронтенд отдаёт готовый HTML из кеша или формирует его;
• при необходимости приложение запрашивает данные у WordPress REST API;
• WordPress обрабатывает запрос через PHP и, если результат не закеширован, обращается к базе данных.

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

Headless убирает WordPress из роли рендерера публичных страниц, но не из роли зависимости. Если фронтенд ждёт API перед показом контента, задержка API становится задержкой сайта.

Что ломается первым

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

1. WordPress API начинает отвечать медленно

Если фронтенд при каждом просмотре страницы запрашивает REST API, рост аудитории напрямую увеличивает число запросов к WordPress. Особенно дорого обходятся страницы, для которых приложение делает несколько последовательных запросов: сначала за записью, затем за автором, категориями и связанным контентом. Если часть данных можно получить одним запросом, лишние обращения превращаются в лишнюю работу PHP и базы.

Смотрите не только на среднее время ответа. Важны p95 и p99: они показывают задержки, которые испытывает небольшая, но заметная доля пользователей. Отдельно измеряйте ответы популярных маршрутов API и долю ответов с ошибками.

2. База данных упирается в дорогие выборки

REST API — это не автоматическая гарантия дешёвого чтения. Плагины могут добавлять поля и обработчики, а запросы приложения — забирать слишком много записей или метаданных. При росте числа одновременных запросов это увеличивает время работы PHP и нагрузку на базу.

Проверяйте маршруты, которые возвращают списки, крупные объекты и связанные записи. Сравните время ответа с включёнными и отключёнными дополнительными полями, если это допустимо в тестовой среде. Не переносите такой эксперимент на рабочий сайт без оценки влияния на пользователей.

3. Кеш не попадает в нужный запрос

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

Считайте долю попаданий в кеш отдельно для HTML фронтенда и для API. Если фронтенд отдаёт страницу из кеша, но при каждом открытии браузер всё равно запрашивает WordPress за блоком контента, нагрузка на CMS никуда не исчезла.

4. Фронтенд теряет стабильность при генерации страниц

При серверной генерации страниц приложение может обращаться к WordPress перед ответом пользователю. Тогда недоступность API или медленный ответ увеличивают время загрузки и могут привести к ошибке страницы. При предварительной генерации готовый HTML переживает кратковременную недоступность CMS лучше, но новые публикации и изменения контента требуют обновления страниц.

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

Сравните модели до выбора

Критический путь¹ — последовательность операций, которые должны завершиться до того, как пользователь увидит страницу. Чем больше в ней синхронных обращений к WordPress, тем сильнее фронтенд зависит от состояния CMS.

Как проверить систему до реального инцидента

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

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

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

Где headless ломается на границах

• Предпросмотр и черновики. Редакторский запрос не равен публичному кешируемому запросу. Проверьте авторизацию, доступ к черновикам и то, что ответы редактора не попадают в общий кеш.
• Публикация и обновление страниц. Если фронтенд заранее собирает HTML, выясните, как публикация запускает обновление и что увидит пользователь, пока оно не завершилось.
• Медиа и сторонние сервисы. Изображения могут загружаться не с того же узла, что страница. Задержка внешнего хранилища или обработки изображений будет выглядеть как проблема фронтенда, хотя API WordPress отвечает нормально.
• Плагины и обновления. Изменение плагина может повлиять на поля API или время ответа. После обновлений повторяйте тесты ключевых маршрутов, а не только проверку главной страницы.
• Сбой при обновлении кеша. Если удалять старую копию до готовности новой, короткая операция публикации может оставить страницу без доступной версии. Продумайте, какая копия остаётся доступной при ошибке обновления.

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

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

Перед запуском составьте карту критического пути для трёх самых посещаемых страниц: от браузера до фронтенда, API и базы. Затем нагрузите эти маршруты с рабочим объёмом данных и отдельно проверьте сценарий недоступности WordPress. В проде следите за p95 API, долей попаданий в кеш, ошибками фронтенда и числом обращений к API на просмотр страницы. Эти показатели подскажут, что именно ограничивает систему, прежде чем общая жалоба «сайт стал медленным» превратится в инцидент.

¹ Критический путь — операции, без завершения которых нельзя отдать результат пользователю.