Если после обновления темы или плагинов вы смотрите в исходный код страницы и видите лишние подключения вроде wp-emoji-release.min.js, это не всегда критичная проблема. Но на небольших проектах, где важны чистый <head>, контроль над внешними запросами и минимизация лишнего JS, такие вещи имеет смысл убрать.
Чаще всего emoji-скрипты не нужны на сайте, где редакторы не используют встроенные эмодзи WordPress, а контент уже проходит через нормальный редактор, плагины или внешние сервисы. Ниже — рабочий способ отключить их без правки ядра и с проверкой, что ничего лишнего не осталось.
Когда это вообще имеет смысл
Отключать emoji стоит не ради «магического ускорения», а когда вы хотите убрать ненужные ресурсы из фронтенда и админки. Это особенно полезно после обновлений, когда в теме или плагинах внезапно появляется лишний код в head, а вы пытаетесь привести сайт к более предсказуемому состоянию.
Типичные признаки
- в исходнике страниц есть
wp-emoji-release.min.js; - в
<head>выводятся дополнительные inline-скрипты для emoji; - вы не используете встроенные эмодзи WordPress в редакторе;
- нужно сократить число мелких запросов на страницах с высокой посещаемостью;
- после обновления темы вы хотите проверить, что она не добавляет лишние зависимости.
Диагностика: что именно подключает WordPress
Сначала не трогайте код. Откройте исходный HTML страницы и найдите упоминания emoji. Если видите только один скрипт, это уже хороший ориентир. Если же тема или плагин дополнительно вставляют свои emoji-решения, отключение стандартного хука WordPress может быть недостаточным.
Проверьте три места:
- исходный код фронтенда;
- консоль браузера и вкладку Network;
- админку, если вы хотите убрать emoji и там тоже.
Для быстрой проверки удобно открыть DevTools и отфильтровать запросы по слову emoji. Если запросов нет после внедрения решения — значит, вы убрали именно стандартную загрузку WordPress, а не просто спрятали что-то визуально.
Пошаговое решение без правки ядра
Самый безопасный вариант — добавить код в дочернюю тему или в небольшой mu-plugin. Так вы не потеряете изменения после обновления темы.
Вариант 1: убрать emoji через functions.php
Этот способ отключает стандартные скрипты и фильтры WordPress. Он подходит для большинства сайтов.
<?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' );
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' );
} );
Если вы добавляете это в functions.php, убедитесь, что файл дочерней темы уже активен. Иначе обновление родительской темы затрёт правку.
Вариант 2: вынести в mu-plugin
Если сайт обслуживается несколькими людьми или тема часто обновляется, лучше сделать маленький mu-plugin. Тогда код не потеряется и не зависит от темы.
<?php
/**
* Plugin Name: Disable 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' );
} );
Файл можно положить в wp-content/mu-plugins/disable-emoji.php. Если папки mu-plugins нет, создайте её вручную.
Если нужен более точечный контроль
Иногда emoji нужно оставить в админке, но убрать на фронтенде. Тогда не стоит отключать всё подряд. Можно убрать только фронтенд-часть и оставить редактор нетронутым.
<?php
add_action( 'init', function () {
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
} );
Это полезно, если редакторы жалуются на поведение в админке после слишком агрессивной оптимизации. В таком варианте вы не вмешиваетесь в backend-скрипты и снижаете риск побочных эффектов.
Сравнение подходов
| Подход | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
| functions.php | Нужно быстро проверить гипотезу | Просто внедрить | Зависит от темы |
| mu-plugin | Нужна стабильность после обновлений | Не слетает при смене темы | Нужно создать отдельный файл |
| Плагин оптимизации | Уже используете инструмент для чистки сайта | Удобно управлять из админки | Лишняя зависимость от плагина |
Если у вас уже стоит инструмент для технической чистки сайта, например Clearfy Pro, проверьте, не дублируете ли вы настройки вручную. Два решения, которые отключают одно и то же, обычно только усложняют поддержку.
Проверка результата после внедрения
После добавления кода не ограничивайтесь визуальной проверкой страницы. Нужно убедиться, что отключение действительно сработало.
- Откройте исходный код страницы и найдите
wp-emoji-release.min.js— его быть не должно. - Проверьте Network в DevTools: запросов с emoji не должно быть.
- Посмотрите
<head>на наличие inline-скрипта emoji detection. - Проверьте главную страницу, запись и страницу с комментариями, если они есть.
- Если у вас RSS-ленты, убедитесь, что контент там отображается нормально.
Для более формальной проверки можно сравнить исходник до и после через любой diff-инструмент. Это особенно полезно после обновления темы: иногда разработчики темы сами добавляют свои оптимизации, и вы хотите понять, что именно изменилось.
Частые ошибки и как их исправить
Код добавили не туда
Если вставить фрагмент в файл, который не загружается, ничего не произойдёт. Проверьте, что это именно активная дочерняя тема или mu-plugin.
Отключили слишком много
Иногда пытаются удалить не только emoji, но и связанные стили или фильтры без понимания контекста. Если после этого ломается отображение в письмах или RSS, верните фильтры для email и лент, а на фронтенде оставьте только удаление скрипта и стилей.
Ожидали ускорения, но не увидели разницы
Это нормально. Emoji — не главный источник тормозов. Если сайт тяжёлый, сначала смотрите на изображения, сторонние скрипты, блокирующие CSS и неэффективные плагины. Отключение emoji — это скорее гигиена фронтенда, чем полноценная оптимизация.
Проверяли не ту страницу
На некоторых сайтах главная страница кэшируется отдельно, а запись — по-другому. Проверяйте несколько типов страниц, иначе можно сделать ложный вывод, что код не работает.
Безопасность и поддержка после обновлений
Если вы обновляете старую тему или переносите сайт на новую версию WordPress, не смешивайте техническую чистку с правками ядра. Любой кастомный код лучше держать в отдельном месте: mu-plugin, дочерняя тема или собственный мини-плагин.
Перед обновлением полезно сделать короткий чек-лист:
- сохранить текущий способ отключения emoji;
- проверить, не делает ли это уже тема или плагин;
- после обновления сравнить исходный код страницы;
- очистить кеш, если используется плагин или серверный кеш;
- проверить фронтенд и админку отдельно.
Если вы используете плагин для чистки сайта, не включайте сразу несколько одинаковых опций в разных местах. В WordPress это частая причина путаницы: код вроде бы есть, но понять, кто именно его отключает, уже сложно.
В итоге задача сводится не к «ускорению ради ускорения», а к нормальной технической дисциплине: убрать лишнее, проверить результат и оставить решение там, где оно не сломается после следующего обновления.