В WordPress поддержка emoji включена по умолчанию и на небольших сайтах это часто незаметно. Но если вы чистите фронтенд, сокращаете количество запросов или просто убираете лишний код из <head>, emoji-скрипты — один из самых простых кандидатов на отключение. Важно сделать это аккуратно: не просто «вырезать всё подряд», а проверить, где именно они подгружаются и что останется работать после изменения.
Когда emoji-скрипты действительно мешают
Проблема обычно не в самих emoji, а в лишнем JavaScript и дополнительной логике, которая загружается на каждой странице. В типичной установке WordPress это два отдельных фрагмента: скрипт в <head> и набор фильтров, которые подменяют рендер emoji в контенте. Если сайт технический, с минималистичной темой или строгими требованиями к чистоте HTML, это выглядит как лишний шум.
Отключение имеет смысл, если:
- вы оптимизируете фронтенд и убираете ненужные запросы;
- на сайте не нужна старая fallback-совместимость для очень старых браузеров;
- вы хотите убрать лишние inline- и внешние скрипты из шаблона;
- нужно привести сайт к более предсказуемому набору подключений перед аудитом производительности.
Что именно отключается
WordPress использует стандартный механизм emoji, который добавляет обработку через хук wp_head, а также подключает скрипт в админке и на фронтенде. Если отключить только один кусок, можно получить частичный эффект: на сайте код останется, но часть логики продолжит работать в редакторе или в панели управления. Поэтому лучше сразу закрыть все точки подключения, а потом проверить результат.
Диагностика: где посмотреть, есть ли emoji-скрипты
Перед правкой откройте исходный код страницы и найдите упоминания wp-emoji-release.min.js или похожие вставки. На большинстве сайтов это видно прямо в <head>. Если используете DevTools, проверьте вкладку Network: при загрузке страницы не должно быть отдельного запроса к emoji-скрипту после отключения.
Полезно также проверить админку и редактор записей. Иногда на фронтенде всё убрано, а в панели управления скрипт продолжает грузиться. Это не всегда критично, но если цель — полная чистка, нужно смотреть обе стороны.
Пошаговое решение через functions.php или мини-плагин
Самый безопасный вариант — добавить код в дочернюю тему или в небольшой mu-plugin. Так вы не потеряете правку после обновления темы. Для отключения emoji в WordPress обычно используют стандартные фильтры и удаление действий из wp_head, admin_print_scripts и wp_print_styles.
<?php
// Отключаем emoji-скрипты и стили на фронтенде и в админке.
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' );
add_filter( 'emoji_svg_url', '__return_false' );
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' );
Если вы добавляете код в тему, убедитесь, что он выполняется после загрузки WordPress. Обычно это делают через after_setup_theme или просто в functions.php, если код не зависит от условий. Для мини-плагина достаточно стандартного заголовка плагина и этого же набора вызовов.
Если нужен более управляемый вариант
Если на сайте уже есть плагин для технической оптимизации, проще собрать такие правки там, чем размазывать их по теме. Например, в Clearfy Pro есть инструменты для чистки лишнего кода и отключения отдельных функций WordPress, но даже в этом случае полезно понимать, что именно выключается и как это проверить вручную. Для технического сайта это важнее, чем просто поставить галочку в интерфейсе.
| Подход | Плюсы | Минусы |
|---|---|---|
| Код в functions.php | Прозрачно, без лишних зависимостей | Нужно не забыть про обновления темы и дочернюю тему |
| Мини-плагин | Не зависит от темы, удобно переносить | Нужно поддерживать отдельный файл |
| Плагин оптимизации | Быстро включить и отключить, есть UI | Меньше контроля над деталями, возможны лишние функции |
Проверка результата после внедрения
После отключения откройте главную страницу и любую запись, затем проверьте исходный код. В идеале вы не должны видеть wp-emoji-release.min.js, а также inline-фрагменты, связанные с emoji detection. В DevTools на вкладке Network не должно быть запросов к emoji-скрипту при обычной загрузке страницы.
Дополнительно проверьте:
- редактор записей в админке — не должно быть визуальных ошибок при вводе текста;
- комментарии, если они включены, — текст должен сохраняться и отображаться нормально;
- RSS-ленты и письма, если они используются, — в них не должно появиться сломанной разметки;
- кэш сайта — после правки очистите серверный и плагинный кэш, иначе вы можете смотреть старую версию страницы.
Если у вас есть автоматический аудит через Lighthouse или PageSpeed, сравнивайте не только общий балл, а конкретно список загружаемых ресурсов. Emoji-скрипт обычно небольшой, но на сайтах с жёсткой оптимизацией важен сам факт его отсутствия.
Частые ошибки и как их исправить
Отключили только фронтенд
Частая ошибка — убрать скрипт из wp_head, но оставить его в админке. Это не ломает сайт, но создаёт ощущение, что оптимизация сделана не до конца. Если цель — полная чистка, проверьте обе области отдельно.
Добавили код в родительскую тему
После обновления темы правка исчезнет. Для таких изменений лучше использовать дочернюю тему или мини-плагин. Это особенно важно, если вы регулярно обновляете шаблон и не хотите вручную возвращать код.
Смешали отключение emoji с другими оптимизациями
Иногда код для emoji вставляют рядом с отключением REST API, XML-RPC, эмбедов и других функций. В результате потом сложно понять, что именно сломало отображение или редактор. Разносите изменения по блокам и проверяйте по одному.
Не очистили кэш
Если сайт отдаёт старые HTML-страницы из кэша, вы можете решить, что код не сработал. Сначала сбросьте кэш плагина, затем серверный кэш, затем CDN, если он есть. Только после этого проверяйте исходник страницы.
Безопасность и производительность: что учитывать
Отключение emoji-скриптов само по себе безопасно, если вы используете стандартные функции WordPress и не трогаете лишнее. Но есть важный принцип: не удаляйте код «вслепую» через поиск по шаблонам и не правьте ядро. Любые изменения должны быть обратимыми.
Если сайт обслуживает редакцию или несколько авторов, лучше оформить правку как отдельный мини-плагин с понятным названием. Тогда при переносе на staging или при разборе инцидента вы быстро увидите, что именно отключено. Для производительных проектов это удобнее, чем искать фрагмент в functions.php среди десятков других хуков.
Практический чек-лист перед выкладкой на прод
- Код добавлен в дочернюю тему или мини-плагин.
- Проверен исходный код страницы на наличие
wp-emoji-release.min.js. - Открыт редактор записей и проверено, что он работает без визуальных ошибок.
- Сброшен весь кэш: плагин, сервер, CDN.
- Проверены RSS и письма, если они используются на сайте.
- Изменение задокументировано, чтобы не потерять его при следующем аудите.
Если вам нужен не только этот пункт, а более широкая чистка WordPress от лишних подключений и дублей, подобные задачи обычно удобнее вести через отдельный технический набор настроек, а не вручную по одному фрагменту. Но даже в этом случае полезно сначала понять, что именно отключается и как это потом проверить на живом сайте.