На небольших и средних сайтах WordPress часто тащит за собой лишний фронтенд- и админский код: emoji-скрипты, эмодзи-стили, oEmbed, иногда еще и наборы CSS, которые не используются в текущей теме. Сам по себе один файл не делает сайт медленным, но в сумме это дает лишние запросы, шум в HTML и путаницу при аудите производительности.
Ниже — рабочая схема, как аккуратно убрать именно то, что обычно не нужно на обычном контентном сайте, и не сломать редактор, комментарии и базовую админку.
Когда это вообще имеет смысл
Отключать emoji-скрипты и связанные стили стоит не «ради красоты кода», а когда вы видите конкретную проблему:
- в исходнике страницы есть
wp-emoji-release.min.jsи дополнительные inline-скрипты; - в отчете Lighthouse или PageSpeed есть лишние ресурсы, которые не дают пользы;
- вы чистите тему или плагин перед переносом на прод и хотите убрать ненужные зависимости;
- сайт работает как контентный, без активного использования старых браузерных фолбэков для emoji.
Если у вас сложная интеграция с внешними сервисами, кастомный редакторский workflow или старые корпоративные браузеры, сначала проверьте, что именно используется на проекте. На большинстве современных сайтов отключение emoji безопасно, но проверка обязательна.
Диагностика проблемы
Сначала посмотрите, что реально подгружается на фронтенде. Не ориентируйтесь на ощущения — откройте исходный HTML и список сетевых запросов.
Что искать в исходнике
wp-emoji-release.min.js;- inline-скрипт, который проверяет поддержку emoji;
- лишние стили, добавленные плагинами для блоков, если они не используются;
- подключение
wp-embed.min.js, если вы не используете встраивание контента WordPress в сторонние сайты.
Если вы видите только emoji-скрипт, задача простая. Если вместе с ним тянется еще и лишний embed-код, можно убрать оба, но лучше делать это поэтапно.
Как проверить через браузер
Откройте DevTools → Network, обновите страницу и отфильтруйте запросы по emoji и embed. Затем посмотрите, есть ли эти файлы в списке и кто их добавляет. Это поможет не гадать, а убрать именно тот код, который действительно присутствует.
Пошаговое решение через functions.php или мини-плагин
Самый надежный вариант — вынести правки в дочернюю тему или небольшой mu-plugin. Так вы не потеряете изменения при обновлении темы.
Если нужен только emoji, используйте стандартный набор фильтров WordPress:
<?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' );
Этот код убирает стандартную emoji-обвязку WordPress. Он не трогает сам редактор блоков и не отключает возможность вставлять emoji как символы — браузер и так умеет их отображать без дополнительного скрипта.
Если на сайте не нужен встроенный embed WordPress, можно отключить и его:
<?php
add_action( 'wp_enqueue_scripts', function () {
wp_deregister_script( 'wp-embed' );
}, 100 );
Здесь важно не дергать wp_deregister_script() слишком рано. На практике безопаснее делать это на wp_enqueue_scripts с высоким приоритетом, чтобы не конфликтовать с темой или плагинами, которые регистрируют зависимости позже.
Если нужно убрать еще и лишние стили блоков
Это уже отдельная задача. Не стоит без разбора отключать все стили Gutenberg: на некоторых темах они нужны для нормального отображения кнопок, колонок и медиа-блоков. Но если вы точно знаете, что тема сама рисует нужные элементы, можно посмотреть на отключение глобальных стилей и части block-library CSS.
Сначала проверьте, какие файлы реально подключаются. Если видите wp-block-library и тема не использует стандартную разметку блоков, можно тестировать отключение точечно. Но делайте это только после проверки на нескольких типах страниц: запись, страница, архив, шаблон с блоками.
| Подход | Что дает | Риск |
|---|---|---|
| Плагин для оптимизации | Быстрое отключение части лишнего кода | Может задеть нужные стили, если включить все подряд |
| Код в дочерней теме / mu-plugin | Прозрачный контроль и минимум магии | Нужно самому тестировать после обновлений |
| Ничего не трогать | Нулевой риск поломки | Остаются лишние запросы и шум в HTML |
Если нужен готовый инструмент для чистки типовых дублей и лишнего кода, можно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином полезно понимать, что именно он отключает, чтобы не получить побочный эффект на теме.
Проверка результата после внедрения
После правки не ограничивайтесь визуальным просмотром страницы. Проверьте три вещи: исходник, сетевые запросы и работу редактора.
Чек-лист проверки
- в исходном коде страницы больше нет
wp-emoji-release.min.js; - в Network отсутствуют запросы к emoji-скрипту;
- в админке открывается редактор записей и блоков;
- комментарии, если они включены, работают как раньше;
- страницы с встраиваемым контентом не потеряли нужный функционал, если вы отключали
wp-embed.
Если используете кэш-плагин или серверный кэш, очистите его после изменений. Иначе вы можете смотреть на старую версию HTML и сделать ложный вывод, что код не сработал.
Для быстрой проверки можно временно открыть страницу в режиме инкогнито и сравнить исходник до и после. Если есть доступ к WP-CLI, полезно еще и сбросить объектный кэш, если он используется, но только в том случае, если вы понимаете, как он настроен на проекте.
Частые ошибки и как их исправить
Отключили emoji, а потом сломали админку
Обычно это происходит, когда код вставили не туда: в файл темы, который меняется при обновлении, или в место, где он выполняется слишком рано. Перенесите правку в дочернюю тему или mu-plugin и проверьте приоритеты хуков.
Удалили не только emoji, но и нужные стили
Это типичная ошибка при попытке «почистить все лишнее» одним махом. Не отключайте wp-block-library и глобальные стили без теста на реальных шаблонах. Сначала уберите только emoji и embed, потом смотрите на CSS.
Смотрели старую версию страницы из кэша
Если кэш не очищен, вы не увидите результат. Особенно часто это путает при проверке на хостинге с серверным кэшированием или CDN.
Проверяли только главную страницу
На главной может быть все нормально, а на записи с блоками или на странице контактов — уже нет. Тестируйте минимум несколько типов страниц.
Практические советы по безопасности и производительности
Не складывайте такие правки в случайный functions.php из интернета. Лучше держать их в отдельном файле, который легко отключить, если что-то пойдет не так. Для продакшена это удобнее и безопаснее.
Если сайт обслуживает несколько редакторов, после изменения кода проверьте не только внешний вид, но и сценарии в админке: вставку медиа, работу блоков, предпросмотр записи. Это дешевле, чем потом искать причину в «сломавшемся редакторе», когда проблема на самом деле в отключенном скрипте или конфликте плагинов.
И еще один практический момент: если вы уже занимаетесь чисткой фронтенда, не делайте это точечно и хаотично. Сначала снимите список подключаемых ресурсов, потом уберите только те, что точно не нужны. Так проще отследить, что именно дало эффект, и не потерять рабочий функционал.