Как отключить emoji и oEmbed в WordPress без лишних скриптов

На небольших и средних сайтах WordPress часто остаются включёнными два источника лишней нагрузки: скрипты emoji и механизм oEmbed. В админке это незаметно, но на фронтенде они добавляют запросы, лишний HTML и иногда мешают чистке кода. Если задача — убрать технический шум без риска сломать публикации, лучше отключать это точечно и проверяемо.

Ниже разберём, как понять, что именно у вас грузится, какие варианты отключения безопасны, и как проверить результат после внедрения. Для сайтов с AI-контентом и автоматизацией это особенно полезно: чем меньше лишних подключений, тем проще контролировать производительность и поведение шаблона. Если вы используете WPGPT для генерации контента, такая чистка хорошо ложится в общий техдолг по оптимизации фронтенда.

Когда emoji и oEmbed действительно мешают

Проблема не в самих функциях, а в том, что они часто остаются включёнными по умолчанию даже там, где не нужны. Emoji в WordPress добавляет отдельный скрипт и инлайн-инициализацию. oEmbed отвечает за автоподстановку внешних ссылок в iframe и за discovery-метаданные в <head>. На контентных сайтах это может быть оправдано, но на проектах с жёсткой оптимизацией обычно лишнее.

Типичные сценарии:

  • сайт не использует эмодзи в контенте и комментариях;
  • вставки YouTube, VK, RuTube и других сервисов делаются вручную или через отдельный блок/плагин;
  • нужно сократить количество запросов и убрать лишние теги из <head>;
  • в шаблоне уже есть собственная логика для embeds, и стандартный oEmbed только дублирует её.

Диагностика: что именно подключает WordPress

Перед отключением не стоит действовать вслепую. Сначала проверьте, есть ли на странице стандартные следы emoji и oEmbed. Это можно сделать в исходном коде и в DevTools.

Что искать в HTML

Откройте любую публичную страницу и посмотрите исходник. Для emoji обычно встречаются:

  • wp-emoji-release.min.js;
  • инлайн-скрипт с проверкой поддержки canvas/emoji;
  • стили, связанные с emoji, если тема или плагины их не переопределяют.

Для oEmbed ищите:

  • wp-embed.min.js;
  • <link rel="alternate" type="application/json+oembed" ...>;
  • <link rel="alternate" type="text/xml+oembed" ...>.

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

Проверка через браузер

Вкладка Network покажет, загружается ли wp-emoji-release.min.js и wp-embed.min.js. Если скрипт есть в HTML, но не выполняется из-за кеша или минификации, это всё равно лишний код в разметке. Для чистки фронтенда важны и запросы, и сам объём HTML.

Как отключить emoji и oEmbed через код

Самый предсказуемый способ — добавить небольшой код в functions.php дочерней темы или в собственный мини-плагин. Так вы не зависите от интерфейса плагина и точно понимаете, что отключено.

Базовый вариант для фронтенда

add_action( 'init', function () {
	remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
	remove_action( 'wp_print_styles', 'print_emoji_styles' );
	remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
	remove_action( 'admin_print_styles', 'print_emoji_styles' );
	remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
	remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
	remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
} );

add_action( 'init', function () {
	wp_deregister_script( 'wp-embed' );
	remove_action( 'wp_head', 'wp_oembed_add_discovery_links' );
	remove_action( 'wp_head', 'wp_oembed_add_host_js' );
	remove_filter( 'oembed_dataparse', 'wp_filter_oembed_result', 10 );
	remove_filter( 'pre_oembed_result', 'wp_filter_pre_oembed_result', 10 );
} );

Этот вариант подходит, если вы уверены, что:

  • не используете автоподстановку ссылок в постах;
  • не рассчитываете на стандартный embed-скрипт WordPress;
  • не хотите, чтобы emoji-логика работала в письмах и RSS.

Если сайт активно использует комментарии и рассылки, отключайте только фронтенд-часть и тестируйте отдельно.

Если нужен более мягкий вариант

Иногда лучше не вырезать всё сразу, а убрать только фронтенд-скрипты, оставив часть логики для админки. Это полезно, если редакторы иногда вставляют ссылки, которые WordPress должен преобразовать в embed на бэкенде или в предпросмотре.

add_action( 'wp_enqueue_scripts', function () {
	wp_deregister_script( 'wp-emoji-release' );
	wp_deregister_script( 'wp-embed' );
}, 100 );

Но у такого подхода есть нюанс: часть следов в <head> может остаться. Если цель — именно чистка HTML, лучше убирать действия и фильтры, а не только deregister.

Когда удобнее использовать плагин

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

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

Если у вас уже стоит плагин для техничной чистки, проверьте, не дублируете ли вы отключение кодом. Двойная настройка иногда приводит к путанице: в одном месте функция выключена, в другом — пытаются её повторно снять.

Пошаговая настройка без поломки сайта

  1. Сделайте резервную копию файлов и базы.
  2. Проверьте, используются ли emoji и стандартные embeds в контенте.
  3. Добавьте код в дочернюю тему или мини-плагин, а не в основной шаблон.
  4. Очистите кеш страницы, объектный кеш и CDN, если он есть.
  5. Откройте несколько страниц: главную, запись, страницу, архив и страницу с внешней ссылкой.
  6. Проверьте исходный код и Network в DevTools.

Если на сайте есть редакторы, предупредите их, что автоподстановка ссылок может измениться. Особенно это заметно на старых записях, где WordPress сам превращал URL в embed.

Как проверить, что решение сработало

После внедрения нужно убедиться не только в отсутствии ошибок, но и в том, что лишние подключения действительно исчезли.

Проверка в исходном коде

Откройте страницу и найдите:

  • нет wp-emoji-release.min.js;
  • нет wp-embed.min.js;
  • нет oEmbed discovery links в <head>;
  • не появились ошибки в консоли.

Проверка в браузере и на сервере

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

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

Отключили только enqueue, но не убрали head-элементы

Так бывает, когда снимают только скрипт wp-embed, но оставляют discovery links. В результате HTML всё ещё содержит следы oEmbed. Решение — убрать и действия в wp_head, и сам скрипт.

Сломали автоподстановку ссылок в старом контенте

Если редакторы привыкли вставлять обычные URL и рассчитывают на embed, после отключения WordPress перестанет подставлять iframe. Исправление простое: либо оставить oEmbed, либо перейти на явные блоки/вставки через плагин или редакторский блок.

Добавили код в родительскую тему

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

Не очистили кеш

Если сайт использует page cache, object cache или CDN, старый HTML может показываться ещё долго. После правки всегда очищайте все уровни кеша, иначе проверка будет ложноположительной.

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

Не отключайте всё подряд только ради «чистого кода». Если на сайте есть интеграции, автоподстановка ссылок или письма с динамическим контентом, сначала проверьте, где именно используется emoji/oEmbed. Лишняя агрессивность в оптимизации часто дороже, чем один небольшой скрипт.

Для сайтов, где контент создаётся регулярно и часть материалов готовится через AI, удобно держать техническую оптимизацию в одном месте: генерация, публикация, чистка шаблона и SEO-настройки не должны жить разрозненно. Если у вас уже используется WPGPT, имеет смысл рядом держать и понятный набор правил для фронтенда: что отключаем, что оставляем, что проверяем после публикации.

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

В итоге рабочая схема такая: сначала диагностируете, что подключается, потом отключаете только ненужное, затем проверяете HTML, Network и кеш. Это надёжнее, чем просто «ускорять WordPress» общими советами без понимания, какой скрипт за что отвечает.

Как исключить AI-страницы из индексации в WordPress через noindex и robots
15.09.2026
Как настроить отложенную публикацию AI-контента в WordPress через Cron и WPGPT
22.09.2026
Как отловить и убрать 404 на изображениях в WordPress
18.09.2026
Как отключить XML-RPC в WordPress и не сломать мобильные приложения и внешние сервисы
27.08.2026
Как убрать дубли страниц авторов и архивов в WordPress через canonical и noindex
03.09.2026