Как найти и отключить лишние REST API-запросы в WordPress

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

Ниже разберём не абстрактную «оптимизацию REST API», а конкретный сценарий: как понять, какие запросы реально нужны, какие можно убрать, и как сделать это без риска сломать админку или фронтенд.

Когда REST API становится лишней нагрузкой

Сначала стоит убедиться, что проблема вообще в API, а не в общем состоянии сайта. Типичные признаки:

в DevTools на вкладке Network видно много запросов к /wp-json/ даже на простых страницах;
в логах сервера повторяются обращения к одному и тому же endpoint;
страница открывается нормально, но TTFB растёт из-за фоновых запросов плагинов;
админка работает медленно, хотя база и PHP в целом в порядке;
на сайте есть плагины, которые тянут данные через REST API, но эти данные не используются на конкретных типах страниц.

Что важно не перепутать

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

Диагностика: откуда идут запросы

Перед изменениями нужно понять источник. Самый практичный путь — посмотреть, какие именно URL вызываются и кто их инициирует.

Откройте страницу сайта в браузере и включите DevTools.
Перейдите на вкладку Network и отфильтруйте запросы по wp-json.
Обратите внимание на endpoint: /wp-json/wp/v2/posts, /wp-json/oembed/1.0/embed, /wp-json/contact-form-7/v1/... и т.д.
Проверьте, повторяются ли запросы на всех страницах или только в отдельных шаблонах.
Сравните фронтенд и админку: иногда лишний запрос нужен только в редакторе, а на публичной части его можно убрать.

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

Какие запросы можно отключать, а какие нет

Здесь полезно разделить задачи на три группы: системные, плагинные и декоративные. Системные лучше не трогать без проверки. Плагинные — отключать только если вы уверены, что функциональность не используется. Декоративные — это, например, oEmbed, если сайт не вставляет внешние материалы через автоподтягивание.

Подход	Когда подходит	Риск
Плагин для оптимизации	Если нужен быстрый контроль без правки кода	Можно отключить лишнее вместе с нужным, если настройки слишком общие
Код в теме или mu-plugin	Если нужно точечно убрать конкретный endpoint или скрипт	Требует проверки после обновлений темы и плагинов
Ничего не отключать, только мониторить	Если сайт активно использует редактор, интеграции и внешние сервисы	Лишняя нагрузка остаётся

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

Пошаговое решение: отключаем только лишнее

Ниже пример для случая, когда на сайте не используется oEmbed и не нужны некоторые публичные REST-маршруты от конкретного плагина. Код лучше добавлять в дочернюю тему или в отдельный mu-plugin, чтобы он не потерялся при обновлении.

1. Отключить oEmbed на фронтенде

Если сайт не встраивает внешние материалы через автоматическое преобразование ссылок, можно убрать связанные скрипты и REST-эндпоинт oEmbed:

<?php
add_action('init', function () {
    // Убираем фронтенд-скрипты oEmbed.
    wp_deregister_script('wp-embed');

    // Отключаем discovery links.
    remove_action('wp_head', 'wp_oembed_add_discovery_links');
    remove_action('wp_head', 'wp_oembed_add_host_js');
});

add_filter('embed_oembed_discover', '__return_false');
add_filter('oembed_response_data', function ($data) {
    return $data;
}, 10, 1);

Этот блок не отключает REST API целиком, а только убирает часть механики, которая часто не нужна на обычных контентных сайтах.

2. Ограничить REST API для неавторизованных пользователей

Если задача — скрыть часть маршрутов от публичного доступа, используйте фильтр rest_endpoints. Он позволяет убрать конкретные endpoints, не ломая весь API. Пример ниже удаляет только оembed-маршруты:

<?php
add_filter('rest_endpoints', function ($endpoints) {
    if (isset($endpoints['/oembed/1.0'])) {
        unset($endpoints['/oembed/1.0']);
    }

    if (isset($endpoints['/oembed/1.0/embed'])) {
        unset($endpoints['/oembed/1.0/embed']);
    }

    return $endpoints;
});

Такой способ безопаснее, чем блокировать /wp-json/ через серверные правила. Последний вариант часто ломает редактор и плагины, которые ожидают доступ к API.

3. Убрать REST-запросы конкретного плагина

Если источник нагрузки — плагин, сначала проверьте его настройки. Многие решения имеют отдельный переключатель для REST, AJAX или внешних запросов. Если переключателя нет, ищите документацию по хукам плагина или отключайте его функциональность на тех страницах, где она не нужна.

Пример условного отключения скрипта плагина на фронтенде:

<?php
add_action('wp_enqueue_scripts', function () {
    if (!is_page('contact')) {
        wp_dequeue_script('plugin-rest-client');
        wp_dequeue_style('plugin-rest-client');
    }
}, 100);

Здесь важно использовать реальные handle-имена из исходного кода плагина. Их можно посмотреть в HTML-исходнике страницы или через Query Monitor.

Проверка результата после внедрения

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

Откройте страницу в режиме инкогнито и проверьте Network: лишние /wp-json/ запросы должны исчезнуть или сократиться.
Проверьте редактор записей: автосохранение, вставку блоков и предпросмотр.
Если отключали endpoint плагина, протестируйте форму, поиск, фильтр или другой связанный сценарий.
Посмотрите консоль браузера на наличие ошибок JavaScript.
Сравните количество запросов до и после на одной и той же странице.

Если у вас есть доступ к серверным метрикам, полезно посмотреть не только число запросов, но и время ответа на страницы, где раньше API создавал лишнюю нагрузку. Иногда эффект виден не в скорости загрузки «по ощущениям», а в уменьшении фоновой активности.

Частые ошибки и как их исправить

Отключили REST API целиком через .htaccess или nginx

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

Удалили endpoint, не проверив зависимые функции

Например, убрали oEmbed, а потом обнаружили, что редакторы контента вставляют ссылки на YouTube или соцсети и ожидают автоподтягивание превью. В этом случае либо возвращайте endpoint, либо меняйте рабочий процесс редакторов.

Использовали код в родительской теме

После обновления темы изменения исчезнут. Для таких правок лучше использовать дочернюю тему или mu-plugin. Это особенно важно, если вы отключаете REST-запросы на боевом сайте и не хотите потерять настройку после апдейта.

Не проверили мобильную версию

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

Безопасность и производительность: что учитывать на практике

Если REST API используется только частично, лучше не прятать его «в ноль», а уменьшать поверхность атаки и количество лишних вызовов. Для этого:

не отключайте системные маршруты без теста на staging;
не блокируйте /wp-json/ на уровне сервера, если не понимаете зависимые плагины;
храните изменения в отдельном mu-plugin, чтобы их было проще контролировать;
проверяйте, не создаёт ли плагин лишние запросы на каждой странице, хотя нужен только в админке;
после обновлений темы и плагинов повторяйте проверку Network хотя бы на ключевых шаблонах.

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

В итоге рабочая схема простая: сначала находите конкретный источник REST-запросов, затем отключаете только лишний маршрут, скрипт или интеграцию, и только после этого проверяете редактор, формы и шаблоны. Такой подход безопаснее, чем попытка «ускорить WordPress» одним общим выключателем.