WordPress по умолчанию подгружает небольшой набор скриптов и стилей для поддержки emoji. На современных сайтах это часто лишняя нагрузка: дополнительные запросы в <head>, лишний JavaScript на фронтенде и еще одна точка для конфликта с оптимизаторами. Если сайт уже собран на нормальной теме и вы не рассчитываете на старые браузеры, emoji-обвязку обычно можно отключить без побочных эффектов.
Когда это имеет смысл
Сценарий простой: в отчете по производительности видно несколько запросов, связанных с wp-emoji-release.min.js, а в исходнике страницы присутствуют inline-скрипты для emoji detection. Это не катастрофа, но на нагруженных страницах и при агрессивной оптимизации такие мелочи лучше убрать. Особенно если вы уже используете кеширование, минификацию и не хотите тащить в HTML то, что не влияет на контент.
Что именно отключается
Речь не о самих emoji в контенте. WordPress продолжит корректно сохранять и выводить символы Unicode. Отключается только проверка старых браузеров и подгрузка вспомогательных скриптов/стилей, которые нужны в основном для совместимости с очень старыми окружениями.
Диагностика: как понять, что emoji-скрипты реально грузятся
Перед правкой проверьте исходник страницы и список сетевых запросов. Это можно сделать в браузере через DevTools:
- откройте страницу сайта;
- посмотрите вкладку
Networkи отфильтруйте поemoji; - в исходнике страницы найдите
wp-emoji-release.min.jsили упоминанияemojiв inline-коде; - если используете PageSpeed или WebPageTest, сравните количество запросов до и после изменения.
Если скрипта нет, значит отключать уже нечего. В таком случае проблема может быть не в WordPress, а в теме или плагине, который добавляет собственные emoji-иконки или сторонние шрифты.
Как отключить emoji-скрипты кодом
Самый надежный способ — убрать стандартные действия WordPress через remove_action(). Этот вариант предсказуемее, чем правка ядра или ручное удаление строк из шаблона.
<?php
// Добавьте в functions.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' );
} );
Если вы работаете с сайтом через отдельный функциональный плагин, лучше вынести код туда. Так он не потеряется при смене темы. Для дочерней темы тоже допустимо, но это менее удобно, если у проекта есть несколько сред или тема может обновляться и заменяться.
Если нужен более точечный вариант
Иногда достаточно убрать только фронтенд, но оставить админку. Тогда можно не трогать административные стили и скрипты. Это полезно, если редакторы работают в старой среде или если вы не хотите менять поведение панели без необходимости.
<?php
add_action( 'init', function () {
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
} );
В этом случае emoji-скрипт в админке останется, а на публичной части сайта исчезнет. Для большинства проектов этого достаточно.
Плагин или код: что выбрать
Если у вас уже стоит плагин для технической оптимизации, проверьте, не умеет ли он отключать emoji без отдельного кода. Но если задача узкая и вам нужен контроль, код обычно проще и прозрачнее.
| Подход | Плюсы | Минусы |
|---|---|---|
| Код в functions.php или мини-плагине | Нет лишних зависимостей, легко проверить, работает предсказуемо | Нужно не забыть про дочернюю тему или отдельный плагин |
| Плагин оптимизации | Можно собрать несколько мелких правок в одном месте | Часть настроек может быть спрятана, бывают конфликты с кешем и минификацией |
| Не трогать вообще | Ничего не сломаете | Лишние запросы и код остаются на фронтенде |
Если у вас уже используется Clearfy Pro, проверьте его настройки технической оптимизации: в подобных плагинах часто есть отдельные переключатели для отключения emoji, oEmbed и других мелких источников лишнего кода. Но даже в этом случае полезно понимать, какой именно код убирается и как это проверить вручную.
Проверка результата после внедрения
После добавления кода не ограничивайтесь визуальной проверкой. Нужно убедиться, что скрипты действительно исчезли, а не просто перестали бросаться в глаза.
- откройте исходник страницы и убедитесь, что
wp-emoji-release.min.jsбольше не подключается; - проверьте, что в
<head>нет inline-скрипта с emoji detection; - сравните количество запросов в DevTools до и после;
- проверьте админку: редактор записей, комментарии и страницу профиля;
- если есть кеш-плагин, очистите кеш и CDN-кеш, иначе вы увидите старую версию страницы.
Отдельно проверьте публикации с нестандартными символами: кавычками, тире, смайлами, символами валют. Они должны отображаться так же, как и раньше. Если символы ломаются, проблема обычно не в отключении emoji, а в кодировке базы, теме или внешнем фильтре контента.
Частые ошибки и как их исправить
Код добавили не туда
Если вставить remove_action() в шаблон страницы или в файл, который не загружается на всех запросах, эффект будет случайным. Код должен выполняться рано, обычно через init, либо через отдельный плагин, который активен всегда.
Правят родительскую тему
После обновления темы изменения исчезнут. Для таких задач безопаснее использовать дочернюю тему или мини-плагин. Это особенно важно, если сайт поддерживается не одним разработчиком и нужно быстро понять, где лежит техническая правка.
Не очищают кеш
Если на сайте есть page cache, object cache или CDN, старый HTML может продолжать отдаваться пользователям. В результате вы проверяете уже исправленный код, но в браузере все еще видите старую версию. После изменения всегда очищайте все уровни кеша.
Путают emoji-скрипты с иконками темы
Некоторые темы используют собственные SVG-иконки или webfont-иконки, и их отключение к emoji не относится. Если после правки что-то пропало в интерфейсе, проверьте, не завязаны ли элементы темы на отдельный набор стилей или шрифтов.
Практические советы по безопасности и производительности
Отключение emoji само по себе не делает сайт быстрее в разы, но это хороший пример дисциплины: убирайте только то, что реально не нужно. Если вы уже чистите фронтенд, посмотрите на соседние вещи:
- не грузится ли на каждой странице
wp-embed.min.js, если встраивание записей не используется; - не подключается ли лишний CSS от плагинов, которые нужны только на одной странице;
- не дублируются ли скрипты после минификации и объединения файлов;
- не ломает ли оптимизатор порядок загрузки критичных скриптов.
Если вы предпочитаете не собирать такие мелкие настройки вручную, имеет смысл держать их в одном техническом инструменте и документировать, что именно отключено. Это упрощает поддержку сайта, когда через полгода нужно понять, почему в <head> исчез тот или иной блок.
Что должно измениться после правки
После корректного отключения emoji-скриптов на фронтенде вы увидите более чистый исходник страницы, меньше мелких запросов и меньше лишнего JavaScript в зоне, где он не нужен. На контент и редактор это не должно влиять. Если влияние есть, значит в проекте есть дополнительная обвязка, и ее нужно искать отдельно, а не возвращать emoji обратно целиком.