На небольших и средних сайтах WordPress часто тянет на фронтенд лишнее: скрипт emoji, стили Dashicons, а иногда и оба сразу. По отдельности это не катастрофа, но в сумме они добавляют запросы, мешают чистке HTML и создают ложное ощущение “тяжёлой” темы. Проблема в том, что отключать их нужно не вслепую: Dashicons могут быть нужны админ-бару для авторизованных пользователей, а emoji иногда уже не нужны вообще.
Ниже — рабочий сценарий: как понять, что именно грузится, как отключить без побочных эффектов и как быстро проверить результат.
Когда это действительно стоит отключать
Если сайт не использует встроенные emoji-замены WordPress и не показывает иконки Dashicons гостям, эти ресурсы можно убрать с фронтенда. Чаще всего это полезно, когда:
- сайт открыт для всех, а админ-бар видят только редакторы и администраторы;
- тема не использует Dashicons в публичной части;
- нужно сократить число лишних запросов и упростить критический путь загрузки;
- вы чистите фронтенд от наследия старых установок и плагинов.
Если у вас есть кастомная тема или плагин, который явно использует Dashicons на публичной части, отключать их нельзя без проверки. То же самое относится к старым виджетам, блокам и фронтенд-скриптам, которые могли быть написаны с расчётом на стандартные иконки WordPress.
Диагностика проблемы: что именно грузится
Перед правкой кода посмотрите, есть ли на странице лишние подключения. Самый простой способ — открыть исходный код страницы и поискать emoji и dashicons. В DevTools это видно во вкладке Network по запросам к wp-emoji-release.min.js и dashicons.min.css.
Что проверить вручную
- есть ли на фронтенде ссылка на
wp-emoji-release.min.js; - подключается ли
dashicons.min.cssдля гостей; - не ломается ли админ-бар у авторизованного пользователя;
- не используются ли иконки Dashicons в меню, кнопках или виджетах темы.
Если сайт кэшируется на уровне плагина или CDN, после изменений обязательно очищайте кэш. Иначе вы можете смотреть на старую версию страницы и сделать неверный вывод.
Пошаговое решение через код
Самый надёжный вариант — убрать emoji и ограничить Dashicons только для тех, кому они действительно нужны. Код лучше добавлять в дочернюю тему или в небольшой mu-plugin, если вы не хотите зависеть от темы.
1. Отключаем 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-инфраструктуру WordPress. Если у вас нет старых требований к совместимости, этого обычно достаточно. На современных браузерах и так нормально отображаются Unicode-символы, а сам WordPress уже давно не нуждается в этой замене на большинстве проектов.
2. Ограничиваем Dashicons для гостей
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_user_logged_in() ) {
wp_deregister_style( 'dashicons' );
}
}, 100 );Здесь логика простая: если пользователь не авторизован, стили Dashicons на фронтенде не нужны. Для админ-барa и интерфейса в панели управления они останутся доступны. Но если ваша тема выводит Dashicons для гостей, этот код сломает отображение иконок — поэтому сначала проверьте, используются ли они вообще.
3. Более аккуратный вариант для темы с иконками
Если вы не уверены, что Dashicons нигде не нужны, можно не удалять их полностью, а ограничить только конкретные шаблоны или типы страниц. Например, отключать только на обычных страницах и записях, но оставить на страницах с пользовательским интерфейсом темы.
add_action( 'wp_enqueue_scripts', function () {
if ( is_user_logged_in() ) {
return;
}
if ( is_singular( array( 'post', 'page' ) ) ) {
wp_deregister_style( 'dashicons' );
}
}, 100 );Это не универсальное правило, а рабочий шаблон для точечной оптимизации. Его смысл в том, чтобы не трогать страницы, где иконки действительно нужны.
Сравнение подходов: код, плагин, компромисс
| Подход | Что даёт | Риск |
|---|---|---|
| Код в теме или mu-plugin | Точный контроль, минимум лишнего | Нужно проверить совместимость с темой и плагинами |
| Плагин для чистки фронтенда | Удобно, если не хотите лезть в код | Может отключить больше, чем нужно |
| Ничего не отключать | Нулевой риск поломки | Лишние запросы и шум в фронтенде остаются |
Если вы уже используете плагин для технической чистки сайта, например Clearfy Pro, проверьте, не дублирует ли он эти настройки. Два инструмента, которые одновременно трогают одни и те же хуки, часто создают путаницу при отладке.
Как проверить, что решение сработало
После внедрения откройте страницу в режиме инкогнито и проверьте исходный код. Вам нужно увидеть, что:
- в
<head>больше нет подключения emoji-скрипта; - для гостя не загружается
dashicons.min.css; - админ-бар у авторизованного пользователя отображается без ошибок;
- в консоли браузера нет новых ошибок, связанных с отсутствующими стилями или иконками.
Дополнительно можно посмотреть вкладку Network и сравнить список запросов до и после. Если вы используете кэш-плагин, очистите кэш, а затем проверьте страницу ещё раз в приватном окне. Иначе легко пропустить старые файлы.
Частые ошибки и как их исправить
Dashicons отключили, а иконки в теме пропали
Значит, тема или плагин реально использовали этот набор. Решение — вернуть подключение и искать, где именно иконки выводятся. Иногда достаточно подключать Dashicons только на конкретных шаблонах, а не на всём сайте.
Emoji убрали, но в письмах или RSS появились странные символы
Обычно это не из-за самого отключения, а из-за старых данных в контенте или кэше. Проверьте записи с эмодзи, очистите кэш и убедитесь, что база и кодировка сайта в порядке. Если контент создавался давно, не исключены проблемы на уровне исходных символов, а не WordPress.
После правки ничего не изменилось
Чаще всего виноват кэш: плагин, серверный кэш, CDN или браузер. Ещё одна причина — код добавили не туда. Если вы вставили его в файл темы, которая не активна, эффекта не будет. Для точечных правок mu-plugin обычно надёжнее.
Практические советы по безопасности и производительности
- Не редактируйте родительскую тему напрямую, если сайт живой и обновляется.
- Для теста используйте staging-копию или хотя бы локальную среду.
- Если отключаете ресурсы через плагин, проверьте, не конфликтует ли он с оптимизатором JS/CSS.
- После изменений сравните страницу в инкогнито и под авторизацией — поведение может отличаться.
- Не отключайте Dashicons “на всякий случай”, если не проверили тему и активные плагины.
Если нужен более широкий набор технической чистки — от дублей до лишних мета-тегов и стандартных WordPress-обвязок — удобнее собрать это в одном инструменте, чем держать несколько разрозненных сниппетов. Но даже в этом случае сначала проверьте, какие именно опции включены, чтобы не отключить что-то нужное для темы.