Как отключить emoji и oEmbed в WordPress для ускорения сайта

Автор: Ольга Громова | Опубликовано: 31.08.2026

На небольших и средних сайтах WordPress часто тянет за собой лишние запросы, которые не нужны вообще: emoji-скрипты, oEmbed-обвязка, discovery-ссылки в <head>. Это не «магическая оптимизация», но на проектах с аккуратной технической базой такие мелочи обычно и создают лишний шум в Lighthouse, PageSpeed и в реальной загрузке страницы.

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

Когда это действительно имеет смысл

Отключать emoji и oEmbed стоит не «на всякий случай», а если вы видите конкретные симптомы:

в исходном коде страницы есть wp-emoji-release.min.js и связанные inline-скрипты;
в <head> присутствуют wp-json, oembed, rest_route и discovery-ссылки, хотя сайт не использует встраивание внешних материалов через WordPress;
в отчётах по производительности есть лишние запросы к wp-emoji-release.min.js или к endpoint’ам oEmbed;
сайт работает как контентный проект, а встраивание роликов и постов делается вручную через iframe или через отдельный плагин.

Если редакторы активно вставляют ссылки на посты WordPress в визуальном редакторе и рассчитывают на автоматический предпросмотр, oEmbed лучше не отключать полностью. В таком случае можно убрать только фронтенд-часть, а в админке оставить всё как есть.

Диагностика: что именно грузится лишним

Перед правкой откройте исходный код страницы и проверьте, есть ли такие элементы:

wp-emoji-release.min.js;
<link rel="https://api.w.org/" ...>;
<link rel="alternate" type="application/json+oembed" ...>;
<link rel="alternate" type="text/xml+oembed" ...>.

Если хотите проверить быстро, используйте поиск по исходнику страницы или DevTools. В Network обычно видно, что emoji-скрипт подгружается с /wp-includes/js/wp-emoji-release.min.js, а oEmbed даёт дополнительные discovery-ссылки и REST-запросы при некоторых сценариях.

Что не стоит отключать без проверки

Не трогайте всё подряд, если у вас:

блоки редактора, завязанные на встроенные медиа;
внешние embed-сценарии через oEmbed;
кастомная тема, где часть логики использует REST API и discovery-ссылки;
старый контент, который может зависеть от автоподстановки встраиваний.

Пошаговое решение без плагина

Самый предсказуемый вариант — добавить код в дочернюю тему или в собственный мини-плагин. Если у вас уже есть mu-plugin для технических правок, это даже лучше: такие настройки не потеряются после обновления темы.

1. Отключаем emoji-скрипты и стили

Добавьте в functions.php дочерней темы или в отдельный плагин:

<?php
add_action( 'init', function () {
    remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
    remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
    remove_action( 'wp_print_styles', 'print_emoji_styles' );
    remove_action( 'admin_print_styles', 'print_emoji_styles' );
} );

Этот код убирает emoji-обвязку и на фронтенде, и в админке. Если вам важно оставить удобство в редакторе, можно ограничиться только фронтендом, но чаще всего это не требуется.

2. Отключаем oEmbed на фронтенде

Если сайт не использует автоматическое встраивание контента WordPress, можно убрать oEmbed-скрипт и discovery-ссылки:

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

remove_action( 'wp_head', 'wp_oembed_add_discovery_links' );
remove_action( 'wp_head', 'wp_oembed_add_host_js' );

Здесь важно понимать разницу: wp-embed — это фронтенд-скрипт, а discovery-ссылки в <head> — это метаданные для встраивания. Если убрать только скрипт, часть лишнего останется.

3. Если нужен более мягкий режим

Иногда удобнее отключить только автоподстановку oEmbed для чужих ссылок, но оставить сам механизм для админки. В таком случае лучше тестировать на staging-сайте, потому что поведение зависит от темы и редакторского процесса.

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

Сравнение подходов

Подход	Что делает	Плюс	Минус
Код в теме/плагине	Точечно отключает emoji и oEmbed	Контроль и прозрачность	Нужно один раз аккуратно внедрить
Плагин оптимизации	Убирает часть лишних функций через настройки	Быстро для типовых сайтов	Может отключить лишнее или конфликтовать с другими оптимизациями
Ничего не делать	Оставляет стандартное поведение WordPress	Минимум риска	Лишние запросы и метаданные остаются

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

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

После правки не ограничивайтесь визуальной проверкой. Нужны три шага:

Откройте исходный код страницы и убедитесь, что wp-emoji-release.min.js больше не подключается.
Проверьте <head>: ссылки oembed и api.w.org должны исчезнуть, если вы убрали соответствующие действия.
Прогоните страницу через DevTools Network или PageSpeed и сравните список запросов до и после.

Если у вас есть кэш на уровне плагина, сервера или CDN, очистите его перед повторной проверкой. Иначе вы можете смотреть на старую версию HTML и сделать ложный вывод, что код не сработал.

Что считать нормальным результатом

Нормально, если:

в исходнике нет emoji-скрипта;
в <head> стало меньше служебных ссылок;
редактор в админке продолжает работать;
встраивание нужных внешних материалов не сломалось.

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

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

Код добавили не туда

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

Отключили oEmbed, а редакторы жалуются на встраивания

Значит, на сайте есть рабочий сценарий, который использует автоподстановку embed. В этом случае не отключайте механизм целиком. Оставьте его в админке или пересмотрите редакторский процесс.

Проверяли без очистки кэша

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

Сломали совместимость с плагином оптимизации

Некоторые плагины уже умеют отключать emoji или oEmbed. Если вы добавили свой код поверх них, можно получить дублирующие действия или странное поведение. В таком случае оставьте один источник правды: либо код, либо настройку плагина.

Практические советы по безопасности и производительности

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

Если вы ведёте несколько проектов, имеет смысл собрать похожие технические отключения в один внутренний must-use плагин: emoji, лишние архивы, ненужные embed-скрипты, часть метаданных в <head>. Но не превращайте его в свалку — каждая правка должна быть документирована и проверяема.

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