В WordPress поддержка emoji включена по умолчанию уже много лет, но на большинстве сайтов она не нужна. Проблема не в самих смайлах как таковых, а в том, что ядро добавляет дополнительные проверки и подключает скрипт с небольшим, но лишним весом. На одном сайте это почти незаметно, на другом — просто еще один источник мусора в фронтенде и админке.
Если задача звучит как «убрать лишнее без риска», лучше не вырезать все подряд из functions.php, а сначала понять, что именно WordPress добавляет, где это используется и как проверить результат после изменений.
Что именно отключаем и когда это имеет смысл
WordPress подгружает emoji-поддержку через набор фильтров и скриптов. Визуально это не ломает сайт, но добавляет лишние запросы и код, который большинству проектов не нужен. Особенно это заметно на сайтах с высокой конкуренцией за каждый запрос: новостники, корпоративные сайты, лендинги, каталоги без активного пользовательского контента.
Отключение имеет смысл, если:
- на сайте нет задачи поддерживать старые браузеры с особой обработкой emoji;
- вы не хотите лишний inline-скрипт в
<head>; - нужно сократить число подключаемых ресурсов в админке и на фронтенде;
- вы уже чистите сайт от лишних функций и хотите убрать еще один системный слой.
Не стоит отключать это «на всякий случай», если у вас нестандартная тема, старая корпоративная сборка или есть интеграции, где внешний вид текста в комментариях и редакторе уже проверен только на дефолтном поведении ядра.
Диагностика: как понять, что emoji действительно подключены
Перед правкой откройте исходный код страницы и найдите упоминания wp-emoji-release.min.js или inline-скрипта, который проверяет поддержку emoji. В DevTools это видно в списке загружаемых ресурсов и в HTML-коде страницы. Если сайт использует кэш-плагин, после очистки кэша проверяйте именно свежую версию страницы, а не старую копию.
Полезно посмотреть и админку: иногда лишний код мешает не фронтенду, а редактору или странице комментариев. Если вы отключаете emoji через код, проверяйте оба контекста — публичную часть и /wp-admin/.
Быстрая проверка в браузере
- Откройте страницу сайта в режиме инкогнито.
- Посмотрите исходный код и найдите
emoji. - Проверьте вкладку Network: нет ли запроса к
wp-emoji-release.min.js. - Сравните поведение до и после очистки кэша.
Рабочее решение через код
Самый предсказуемый способ — убрать стандартные действия WordPress через фильтры и действия. Это не требует плагинов и легко откатывается. Добавлять код лучше в дочернюю тему или в небольшой 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' );
} );Этот вариант обычно достаточно надежный для обычных сайтов. Он убирает подключение скрипта и стилей, а также отключает преобразование emoji в RSS и письмах.
Если вы хотите сделать это точечно только на фронтенде, можно ограничить часть кода проверкой is_admin(), но на практике удобнее отключать все системно и потом проверить, не нужен ли emoji в письмах или RSS-лентах.
Альтернатива: мини-плагин вместо темы
Если тема часто меняется, не привязывайте оптимизацию к functions.php. Для таких задач удобнее маленький плагин или mu-plugin. Тогда отключение emoji не исчезнет после смены темы и не потеряется при обновлении.
<?php
/**
* Plugin Name: Disable WordPress Emoji
*/
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' );
} );Когда лучше плагин, а когда код
Если у вас уже стоит плагин для технической чистки сайта, отключение emoji можно сделать там же. Но если задача узкая, отдельный код обычно прозрачнее: меньше настроек, меньше зависимостей, проще аудит.
| Подход | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Контроль, минимум зависимостей, легко проверить | Нужно не забыть про обновления и место размещения |
| Плагин оптимизации | Удобно для нескольких правок сразу | Лишний слой, иногда слишком много функций в одном месте |
| Не трогать вообще | Ничего не сломаете | Оставите лишний код и запросы |
Если вы уже используете плагин для технической очистки, например Clearfy Pro, проверьте, нет ли там готового переключателя для emoji и других системных мелочей. Это может быть удобнее, чем держать отдельный фрагмент кода, если вы централизуете оптимизацию сайта.
Пошагово: как внедрить без сюрпризов
- Сделайте резервную копию файла, куда будете добавлять код.
- Вставьте код в дочернюю тему или mu-plugin.
- Очистите кэш сайта, сервера и CDN, если они есть.
- Проверьте главную страницу, запись, архив и страницу комментариев.
- Откройте админку и убедитесь, что редактор и форма комментариев работают как раньше.
- Проверьте RSS, если он у вас реально используется.
Как проверить, что отключение сработало
Проверка должна быть не визуальной, а технической. Сам факт, что на странице «ничего не сломалось», еще не означает, что код исчез.
- В исходном коде страницы больше нет
wp-emoji-release.min.js. - В Network не загружается emoji-скрипт.
- В
<head>нет emoji detection script. - На странице записи и в комментариях текст отображается нормально.
- В админке редактор не показывает ошибок JavaScript.
Если используете PageSpeed Insights или Lighthouse, не ждите от этого шага чудес. Это не магическая оптимизация, а аккуратная уборка системного мусора. Но в сумме с другими мелкими правками эффект уже заметен по числу запросов и чистоте HTML.
Частые ошибки и как их исправить
Код добавили, но emoji-скрипт остался
Чаще всего причина в кэше или в том, что код вставили слишком поздно и тема/плагин уже успели подключить скрипт. Проверьте, что хук init действительно выполняется, и очистите все уровни кэша.
Сломались RSS или письма
Обычно это происходит, если вы удалили только часть фильтров или внесли правку в чужой код без понимания, что именно он отключает. Если RSS и email-рассылки важны, проверьте, не нужен ли вам преобразователь emoji в этих каналах. В таком случае можно оставить фильтры для контента и убрать только фронтенд-скрипты.
Правка исчезла после обновления темы
Это типичная ошибка при изменениях в functions.php родительской темы. Для постоянных технических правок используйте дочернюю тему или mu-plugin.
После отключения появилась проблема в старом браузере
Если проект обязан поддерживать очень старые браузеры, не отключайте все вслепую. Сначала проверьте, действительно ли у вас есть такая аудитория. Для большинства современных сайтов это уже не критично, но в корпоративных проектах лучше смотреть на аналитику, а не на догадки.
Что еще можно убрать рядом с emoji, если цель — чистка фронтенда
Если вы уже занялись технической уборкой, имеет смысл посмотреть и на другие системные вещи: лишние мета-теги, эмодзи в RSS, встроенные oEmbed-скрипты, ненужные стили плагинов. Но здесь важно не превращать оптимизацию в охоту на все подряд. Убирайте только то, что вы реально проверили на своем сайте.
Хорошая практика — вносить одну правку за раз и фиксировать результат. Тогда при проблеме вы быстро поймете, что именно вызвало побочный эффект, а не будете откатывать половину сайта.