На небольших и средних WordPress-сайтах лишние скрипты часто прячутся не в теме и не в плагинах, а в базовой обвязке ядра. Два типичных кандидата — emoji-поддержка и oEmbed. Они добавляют запросы, мета-теги и служебные скрипты, которые не всегда нужны, особенно если сайт работает как корпоративный, контентный или технический ресурс без активного обмена встраиваниями.
Проблема обычно всплывает после замеров в Lighthouse, WebPageTest или просто при ручной проверке исходного кода: в <head> есть лишние подключения, а в консоли — запросы к wp-emoji-release.min.js и wp-embed.min.js. Ниже — как отключить это аккуратно, где смотреть побочные эффекты и как проверить, что всё действительно сработало.
Когда это вообще имеет смысл отключать
Не стоит рубить всё подряд только ради «чистоты». Сначала посмотрите на сценарий сайта. Если у вас блог, документация, B2B-сайт или лендинг, где эмодзи не являются частью контента, а встраивание чужих постов через oEmbed не используется, отключение обычно оправдано. Если же редакторы регулярно вставляют ссылки на YouTube, X, WordPress.tv или другие поддерживаемые источники, нужно либо оставить oEmbed, либо заменить его на более контролируемый способ вставки.
Диагностика проблемы в исходном коде
Откройте страницу сайта и проверьте исходник. Ищите такие признаки:
- подключение
wp-emoji-release.min.js; - скрипт
wp-embed.min.jsв футере; - DNS-prefetch или дополнительные запросы к доменам, связанным с эмодзи;
- служебные фильтры oEmbed в HTML, если они вам не нужны.
Если сайт уже оптимизирован через кэш-плагин или CDN, полезно сравнить исходник до и после очистки кэша. Иначе можно сделать неверный вывод: код убрали, а в браузере всё ещё виден старый вариант.
Что отключать: emoji, oEmbed или оба механизма
Эти вещи решают разные задачи. Emoji-скрипт нужен для старых браузеров и совместимости с отображением некоторых символов. На современных проектах он чаще всего не нужен. oEmbed — это механизм автоподстановки встраиваемого контента по URL. Если редакция не использует автоподстановку, его можно отключить, но тогда вставки придётся делать вручную.
| Подход | Что даёт | Компромисс |
|---|---|---|
| Отключить через код | Минимум лишнего, контроль в теме или mu-plugin | Нужно не забыть обновлять код при смене темы |
| Использовать плагин оптимизации | Удобно для редактора и техподдержки | Ещё один слой настроек и зависимость от плагина |
| Ничего не трогать | Максимальная совместимость «из коробки» | Лишние запросы и служебные скрипты остаются |
Если нужен не только этот набор оптимизаций, но и чистка дублей, служебных ссылок и лишних элементов ядра, на практике часто смотрят в сторону Clearfy Pro. Но если задача точечная, проще и надёжнее обойтись кодом.
Пошаговое решение через functions.php или mu-plugin
Для точечной настройки лучше не править ядро и не лезть в сторонние плагины. Самый предсказуемый вариант — добавить код в functions.php дочерней темы или, ещё лучше, в mu-plugin, если это серверный проект и вы хотите, чтобы оптимизация не зависела от темы.
1. Отключаем emoji-скрипты и стили
<?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-поддержку и связанные скрипты
<?php
add_action( 'init', function () {
// Убирает автопреобразование URL в embed-контент.
remove_filter( 'the_content', [ $GLOBALS['wp_embed'], 'autoembed' ], 8 );
// Убирает REST endpoint для oEmbed discovery, если он не нужен.
remove_action( 'rest_api_init', 'wp_oembed_register_route' );
// Убирает discovery links из head.
remove_action( 'wp_head', 'wp_oembed_add_discovery_links' );
remove_action( 'wp_head', 'wp_oembed_add_host_js' );
} );
add_action( 'wp_enqueue_scripts', function () {
wp_deregister_script( 'wp-embed' );
} );Здесь важно понимать разницу: удаление wp-embed убирает фронтенд-скрипт, а отключение autoembed и discovery links влияет на сам механизм автоподстановки. Если оставить только wp_deregister_script( 'wp-embed' ), часть логики всё ещё может работать через ядро, и вы получите неочевидное поведение.
3. Если нужен только фронтенд, а автоподстановка должна остаться
Иногда редакторы вставляют ссылки на поддерживаемые сервисы, и автоподстановка важна. Тогда не отключайте autoembed, а уберите только лишние скрипты и discovery links. Это более безопасный компромисс, если контент живой и часто редактируется.
Как проверить, что решение сработало
Проверка должна быть не визуальной, а технической. После внедрения очистите кэш плагина, серверный кэш и CDN, если он есть. Затем откройте страницу в режиме инкогнито и проверьте:
- в исходном коде нет
wp-emoji-release.min.js; - в исходном коде нет
wp-embed.min.js; - в
<head>отсутствуют oEmbed discovery links; - в Network нет лишних запросов к этим ресурсам;
- в редакторе записи не ломается сохранение и предпросмотр;
- вставки, которые вы реально используете, продолжают работать.
Если хотите проверить быстро через консоль, можно использовать поиск по исходнику страницы:
curl -s https://example.com/ | grep -E 'wp-emoji-release|min.js|wp-embed|oembed'Если команда ничего не возвращает, это хороший знак. Но не забывайте, что кэш может отдавать старую версию страницы, поэтому после изменений всегда проверяйте именно очищенную копию.
Частые ошибки и как их исправить
Скрипт удалили, но в браузере он всё ещё есть
Обычно причина в кэше. Очистите кэш плагина, объектный кэш, CDN и браузер. Если сайт работает через reverse proxy, проверьте и его. Ещё одна частая причина — код добавили в тему, а активна другая тема или дочерняя тема не наследует нужный файл.
После отключения oEmbed перестали вставляться видео
Это ожидаемо, если вы убрали autoembed. Решение простое: либо верните фильтр, либо вставляйте видео через iframe вручную. Для редакторов это нужно зафиксировать в инструкции, иначе проблема будет повторяться после каждого обновления контента.
Код добавили в неправильный хук
Если попытаться снять часть действий слишком рано, WordPress ещё не успеет зарегистрировать нужные callback’и. Поэтому в примерах выше используется init и wp_enqueue_scripts. Это не случайный выбор: в этих точках ядро уже собрало большую часть публичной логики, и удаление работает предсказуемо.
Сломали админку или редактор
Если вы отключили emoji-скрипты в админке, а у редакторов есть старые браузеры или специфические плагины, возможны визуальные артефакты. В таком случае оставьте админскую часть нетронутой и уберите только фронтенд. Это лучше, чем экономить один запрос ценой неудобной работы редакторов.
Практические советы по безопасности и производительности
Любую такую оптимизацию лучше хранить отдельно от темы. Для проекта с долгим сроком жизни удобнее вынести код в небольшой mu-plugin: он не исчезнет после смены темы и не потеряется при обновлении. Если у вас несколько сайтов, такой подход проще сопровождать, чем правки в functions.php.
Ещё один практический момент: не отключайте oEmbed «на всякий случай», если редакция использует внешние вставки. Сначала посмотрите, какие типы контента реально публикуются. Иногда достаточно убрать только discovery links и фронтенд-скрипт, а сам механизм оставить для отдельных записей.
Если задача шире и вы хотите одновременно убрать дубли, служебные мета-теги, лишние скрипты и часть мусора из ядра, имеет смысл смотреть на комплексную настройку. Но даже тогда полезно понимать, какие именно функции отключаются и как это проверить руками, а не верить галочке в интерфейсе.
Мини-чек-лист перед выкладкой на прод
- Проверить, используется ли автоподстановка embed-контента в редакции.
- Сохранить код в дочерней теме или mu-plugin, а не в ядре.
- Очистить кэш плагина, сервера и CDN.
- Сравнить исходный код страницы до и после изменения.
- Проверить, не сломались ли вставки видео и предпросмотр записей.
- Открыть сайт в инкогнито и убедиться, что лишние скрипты исчезли.
Если после этого в исходнике больше нет emoji- и oEmbed-обвязки, а редакторы не жалуются на вставки, значит оптимизация сделана правильно. В WordPress такие изменения ценны именно тем, что они маленькие, но проверяемые: убрали конкретный механизм, увидели конкретный результат, не трогая остальной сайт.