Если на сайте уже отключены emoji-скрипты на фронтенде, это еще не значит, что они не грузятся в админке. В реальных проектах лишние запросы часто остаются в редакторе записей, на экранах настроек и в wp-admin, где они не дают заметного выигрыша по скорости, но добавляют шум в сетевых запросах и усложняют диагностику производительности.
Эта задача обычно всплывает после аудита Lighthouse, ручной проверки Network или когда разработчик видит в админке подключение wp-emoji-release.min.js и хочет убрать его там, где это безопасно. Ниже — рабочий способ отключить emoji в WordPress точечно и проверить, что ничего лишнего не осталось.
Когда отключение emoji в админке действительно имеет смысл
Не стоит трогать это «на всякий случай», если вы не понимаете, где именно грузится скрипт. Но если сайт большой, редакторов много, а в админке важна предсказуемость и минимизация лишних подключений, отключение emoji-обвязки оправдано. Особенно это полезно, когда вы уже чистите админку от ненужных скриптов, блоков и автоподгрузок.
Типичные симптомы
- в
wp-adminв списке запросов естьwp-emoji-release.min.js; - скрипт подключается даже на страницах, где эмодзи не используются;
- после отключения на фронтенде в админке запросы все равно остаются;
- в проекте есть строгие требования к чистоте админки и минимальному числу внешних/служебных ресурсов.
Диагностика: где именно грузится emoji-скрипт
Сначала проверьте, что именно подключается и на какой странице. Самый простой путь — открыть DevTools в браузере, перейти на экран редактирования записи или в wp-admin и посмотреть вкладку Network. Ищите запросы, связанные с emoji, а также inline-скрипт, который WordPress добавляет для их поддержки.
Если используете Query Monitor, проверьте список скриптов на административной странице. Вам важно понять, отключается ли только фронтенд, или код все еще добавляется в админке через стандартные хуки WordPress.
Что именно искать
wp-emoji-release.min.js;- inline-функцию, связанную с
wpemojiSettings; - подключения на экранах редактора, списка записей и настроек;
- следы плагинов, которые могут повторно включать emoji-совместимость.
Пошаговое решение через код
Самый надежный способ — убрать стандартные действия WordPress, которые добавляют emoji-скрипты и стили. Код лучше разместить в дочерней теме или в небольшом mu-plugin, если вы управляете несколькими сайтами и не хотите зависеть от темы.
<?php
/**
* Disable WordPress emoji scripts and styles.
*/
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-обвязку и на фронтенде, и в админке. Если вам нужно оставить поддержку в одной из зон, можно убрать только часть строк. Например, если вы хотите чистый фронтенд, но не трогать админку, не удаляйте административные хуки.
Если проект использует собственную сборку или вы хотите сделать отключение более явным, можно добавить фильтр на TinyMCE, чтобы WordPress не подмешивал emoji-поддержку в редактор.
<?php
add_filter( 'tiny_mce_plugins', function ( $plugins ) {
if ( ! is_array( $plugins ) ) {
return $plugins;
}
return array_diff( $plugins, array( 'wpemoji' ) );
} );
Альтернатива: отключать только в админке
Иногда фронтенд уже очищен, а в админке вы хотите убрать только лишние подключения, не затрагивая поведение сайта для посетителей. Тогда используйте условие is_admin(). Это удобно, если вы не уверены, не завязаны ли какие-то старые интеграции на emoji-совместимость на публичной части.
<?php
add_action( 'init', function () {
if ( ! is_admin() ) {
return;
}
remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
remove_action( 'admin_print_styles', 'print_emoji_styles' );
} );
Но на практике чаще имеет смысл отключать все сразу. Emoji-скрипты не дают пользы в большинстве корпоративных и контентных проектов, а частичное отключение иногда только усложняет поддержку.
Сравнение подходов
| Способ | Что делает | Когда выбирать | Компромисс |
|---|---|---|---|
| remove_action() | Убирает стандартные подключения WordPress | Нужен контролируемый и предсказуемый результат | Нужно добавить код в тему или mu-plugin |
| Плагин оптимизации | Отключает emoji через настройки | Если админке нужен интерфейс без кода | Меньше прозрачности, возможны лишние функции |
| Только фронтенд | Оставляет emoji в админке | Если есть сомнения по совместимости | Лишние запросы в wp-admin сохраняются |
Если вы уже используете плагин для технической чистки сайта, например Clearfy Pro, проверьте, не дублирует ли он эту настройку. Важно не складывать несколько решений поверх одного и того же хука: это не ускорит сайт, а только усложнит отладку.
Как проверить, что решение сработало
После внесения кода не ограничивайтесь визуальной проверкой. Нужно убедиться, что WordPress больше не добавляет emoji-скрипты ни в HTML, ни в списке подключенных ресурсов.
- Откройте страницу редактирования записи в
wp-adminи проверьте вкладку Network. - Убедитесь, что запросов к
wp-emoji-release.min.jsбольше нет. - Посмотрите исходный код страницы: не должно быть inline-скрипта с
wpemojiSettings. - Если используете Query Monitor, проверьте список scripts и styles на админ-странице.
- Повторите проверку после очистки кеша браузера и, если есть, кеша плагина или CDN.
Если скрипт все еще появляется, значит, его добавляет не ядро WordPress, а тема, плагин или кастомный код. В таком случае ищите повторное подключение через wp_head, admin_print_scripts или через фильтры в плагинах оптимизации.
Частые ошибки и как их исправить
Отключили только один хук
Иногда убирают только print_emoji_detection_script, но забывают про стили. В результате часть следов остается, а проверка показывает неполную чистку. Исправление простое: удаляйте и скрипт, и стили, и в админке, и на фронтенде, если это соответствует задаче.
Добавили код не туда
Если вставить код в шаблон, который не загружается в админке, он не сработает. Для системных правок лучше использовать functions.php дочерней темы или mu-plugin. Для проекта с несколькими темами mu-plugin обычно надежнее.
Не проверили конфликт с плагином оптимизации
Некоторые плагины повторно подключают оптимизацию или, наоборот, восстанавливают стандартное поведение WordPress. Если после правки emoji-скрипт остался, временно отключите плагины оптимизации и проверьте результат еще раз.
Сделали вывод по одному экрану
В админке WordPress разные экраны могут вести себя по-разному. Проверка только на странице записей не гарантирует, что скрипт не грузится в редакторе блоков, в медиа-библиотеке или на странице настроек.
Практические советы по безопасности и производительности
Не редактируйте основной файл темы на боевом сайте без резервной копии. Если правка нужна как часть технической оптимизации, лучше вынести ее в отдельный mu-plugin с понятным названием и коротким комментарием, зачем он нужен. Так проще сопровождать сайт после обновлений темы.
Если вы используете тему с активной технической обвязкой, проверьте, не делает ли она похожие отключения уже внутри себя. В некоторых случаях лучше держать такие правки в одном месте, чем размазывать по теме, дочке и плагинам. Для проектов, где важна системная чистка WordPress, имеет смысл смотреть в сторону инструментов вроде Clearfy Pro, но только если вы понимаете, какие именно опции включаете и не дублируете ими собственный код.
После внедрения не забудьте зафиксировать правку в репозитории или хотя бы в внутренней документации проекта. Такие мелкие оптимизации часто теряются, а потом возвращаются при следующем обновлении темы или переносе сайта.