Если сайт работает на классической теме или на WooCommerce-проекте, а emoji в контенте не используются, WordPress всё равно может подключать лишние скрипты и фильтры. На небольшом сайте это не критично, но в сумме такие мелочи добавляют запросы, усложняют HTML и иногда мешают чистой оптимизации фронтенда.
Задача здесь простая: отключить штатную поддержку emoji аккуратно, без поломки редактора и без удаления того, что может понадобиться в админке. Ниже — рабочий вариант для темы или небольшого mu-plugin.
Когда отключение emoji действительно нужно
Сценарий обычно один из трёх: сайт не использует emoji в контенте, вы хотите убрать лишние запросы из <head>, или нужно сократить количество подключаемых ресурсов перед дальнейшей оптимизацией. На практике это особенно полезно, если вы уже чистите сайт от лишнего кода и следите за количеством HTTP-запросов.
Важно понимать: речь не о «ускорении в разы», а о точечной чистке. Если на сайте есть другие тяжёлые скрипты, отключение emoji не решит проблему само по себе. Но как часть общей оптимизации это нормальная и безопасная правка.
Диагностика: как понять, что emoji вообще подключены
Проверка занимает минуту. Откройте исходный код страницы и найдите упоминания wp-emoji-release.min.js или инлайн-скрипт, который WordPress добавляет для проверки поддержки emoji. В старых или сильно кастомизированных проектах может быть и подключение стилей, связанных с emoji.
Ещё один быстрый способ — посмотреть список ресурсов в DevTools браузера на вкладке Network. Если на странице есть запрос к wp-emoji-release.min.js, значит штатная поддержка emoji активна.
Что именно отключаем
WordPress добавляет emoji не одним действием, а набором хуков и фильтров. Поэтому правильное решение — снять стандартные действия, а не пытаться «запретить emoji» одной несуществующей настройкой.
- убрать инлайн-проверку emoji из
wp_head; - убрать скрипт из админки и фронтенда;
- снять фильтры, которые подменяют emoji в контенте и комментариях;
- при необходимости оставить админку нетронутой, если вы не хотите менять поведение редактора.
Пошаговое решение без плагинов
Самый надёжный вариант — добавить код в functions.php дочерней темы или, лучше, в отдельный mu-plugin. Так правка не потеряется после обновления темы.
<?php
/**
* Отключение emoji в WordPress.
*/
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' );
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' );
remove_filter( 'the_content', 'wp_staticize_emoji' );
remove_filter( 'comment_text', 'wp_staticize_emoji' );
} );Этот вариант отключает emoji в публичной части и в большинстве типовых сценариев админки. Если вам нужно оставить админские подсказки и поведение редактора как есть, можно убрать только фронтенд-часть, но на практике чаще отключают всё целиком.
Если нужен более аккуратный вариант для фронтенда
Иногда удобнее не трогать админку, а убрать только фронтенд-скрипты. Тогда код будет короче и безопаснее для редакторов, которые привыкли к стандартному поведению WordPress.
<?php
add_action( 'init', function () {
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
remove_filter( 'the_content', 'wp_staticize_emoji' );
remove_filter( 'comment_text', 'wp_staticize_emoji' );
remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
} );Такой подход обычно достаточно безопасен для корпоративных сайтов и блогов, где контент редактируют несколько человек, а админку лучше не менять без необходимости.
Что выбрать: код, плагин или ничего не делать
| Подход | Когда подходит | Минусы |
|---|---|---|
| Код в теме / mu-plugin | Нужна точечная оптимизация без лишних зависимостей | Нужно не забыть сохранить правку при смене темы |
| Плагин для оптимизации | Уже используется набор функций для чистки сайта | Может добавить лишние настройки и конфликтовать с другими оптимизаторами |
| Ничего не делать | Emoji реально используются в контенте или проект очень маленький | Лишние запросы и код остаются |
Если у вас уже стоит плагин для чистки сайта, например Clearfy Pro, подобные отключения часто есть в интерфейсе. Но если задача узкая и вы не хотите раздувать стек, код обычно проще и прозрачнее. У Clearfy Pro есть смысл, когда вы параллельно отключаете и другие лишние элементы, а не только emoji: https://wpshop.ru/plugins/clearfy.
Проверка результата после внедрения
После добавления кода откройте главную страницу и исходник HTML. В нём не должно быть ссылки на wp-emoji-release.min.js, а также инлайн-скрипта emoji detection. Затем проверьте вкладку Network в DevTools: запрос к этому файлу должен исчезнуть.
Дополнительно стоит проверить комментарии, RSS-ленты и письмо из WordPress, если они используются на сайте. Это важно, потому что фильтры emoji затрагивают не только обычные записи.
- откройте страницу в режиме инкогнито;
- посмотрите исходный код и поиск по
emoji; - обновите кэш, если используется серверный или плагинный кэш;
- проверьте письмо-уведомление из формы или из WordPress;
- убедитесь, что в редакторе контент сохраняется без изменений.
Частые ошибки и как их исправить
Код добавили в неправильное место
Если вставить его в шаблон страницы или в файл, который не загружается на всех запросах, отключение сработает частично или не сработает вовсе. Надёжнее использовать functions.php дочерней темы или mu-plugin.
Ожидали, что исчезнут все emoji из контента
Этот код отключает штатные скрипты WordPress, но не переписывает уже опубликованный текст. Если в записях есть emoji как символы Unicode, они останутся в контенте — и это нормально. Задача кода не в удалении символов из базы, а в отключении лишней поддержки.
Кэш мешает увидеть изменения
После правки часто остаётся старый HTML из кэша страницы или CDN. Если вы не очистили кэш, может показаться, что ничего не изменилось. Сначала сбросьте кэш, потом проверяйте исходник.
Удалили слишком много фильтров
Иногда пытаются «почистить» WordPress агрессивно и снимают лишние хуки, которые уже не относятся к emoji. Это может сломать RSS или email-уведомления. Если задача только в фронтенде, не трогайте лишние фильтры для почты и лент.
Практические советы по безопасности и производительности
Любую такую правку лучше держать отдельно от темы. Если проект живёт долго, mu-plugin удобнее: он не зависит от смены шаблона и не теряется при обновлении. Для небольших сайтов это самый предсказуемый вариант.
Если вы уже делаете аудит фронтенда, проверьте рядом и другие мелкие источники шума: лишние эмодзи, неиспользуемые стили, дублирующиеся скрипты, тяжёлые блоки в шапке. Но не отключайте всё подряд без проверки — в WordPress слишком легко убрать то, что потом нужно редактору или плагину.
Для типового проекта логика простая: сначала измерить, потом убрать только то, что реально не используется, и после этого ещё раз проверить исходник и Network. Такой подход надёжнее, чем набор случайных «ускоряющих» сниппетов из интернета.