Как отключить emoji и дублирующиеся скрипты в WordPress без поломки темы

Лишние скрипты в WordPress обычно не выглядят как проблема, пока не начинаешь смотреть исходный код, отчёт Lighthouse или список запросов в DevTools. Чаще всего всплывают два сценария: WordPress сам добавляет emoji-поддержку, а тема или плагины дублируют одни и те же библиотеки, стили или inline-инициализацию. В результате страница получает больше запросов, чем нужно, а при агрессивной оптимизации легко сломать редактор, формы или меню.

Ниже — рабочий способ сначала найти источник, потом убрать лишнее и проверить, что сайт не потерял функциональность.

Как понять, что у вас действительно есть лишние подключения

Не стоит отключать всё подряд только потому, что «так советуют». Сначала нужно увидеть, что именно грузится дважды или без пользы. Для этого достаточно открыть исходный код страницы и DevTools.

Что искать в исходнике

• wp-emoji-release.min.js — стандартный emoji-скрипт WordPress;
• одинаковые версии jQuery, Swiper, Slick, Lightbox и других библиотек, подключённые разными плагинами;
• повторяющиеся inline-скрипты с одинаковой инициализацией;
• стили и скрипты, которые есть на всех страницах, хотя нужны только в одном шаблоне.

Если вы видите один и тот же файл в HTML несколько раз, это уже повод искать конфликт в теме, плагине или кастомном коде.

Быстрая диагностика через браузер

Откройте страницу, затем:

1. включите DevTools;
2. перейдите на вкладку Network;
3. обновите страницу с включённой записью запросов;
4. отфильтруйте по js и css;
5. посмотрите, нет ли одинаковых URL, загруженных дважды.

Если дублируется не сам URL, а логика инициализации, это видно по консоли или по повторному созданию одного и того же виджета на странице.

Как отключить emoji-скрипты штатным способом

WordPress до сих пор может подключать emoji-поддержку на фронтенде и в админке. Если сайт не использует старые браузеры с проблемной поддержкой emoji, этот код обычно можно убрать. Делать это лучше через дочернюю тему или небольшой mu-plugin, а не через правку ядра.

<?php
// functions.php дочерней темы или mu-plugin
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. Он не трогает сами символы в контенте и не влияет на отображение эмодзи в современных браузерах.

Как убрать дублирующиеся скрипты и стили из темы или плагина

Если один и тот же файл подключается дважды, сначала найдите, кто именно его добавляет. В WordPress это обычно делается через wp_enqueue_script() и wp_enqueue_style(). Дубли возникают, когда:

• тема и плагин подключают одну библиотеку независимо друг от друга;
• кастомный код добавляет файл без проверки, что он уже зарегистрирован;
• скрипт подключается и через enqueue, и вручную через <script> в шаблоне;
• одна и та же библиотека загружается в разных версиях.

Если вы контролируете код темы, можно аккуратно снять лишнее подключение через wp_dequeue_script() и wp_dequeue_style(). Важно делать это после того, как исходный скрипт уже зарегистрирован.

<?php
add_action( 'wp_enqueue_scripts', function () {
    // Пример: снимаем лишний скрипт, если он уже подключён другой частью сайта.
    wp_dequeue_script( 'plugin-slider' );
    wp_deregister_script( 'plugin-slider' );

    // Пример для стиля.
    wp_dequeue_style( 'plugin-slider' );
    wp_deregister_style( 'plugin-slider' );
}, 100 );

Здесь ключевой момент — приоритет 100. Если вызвать это слишком рано, WordPress ещё не успеет зарегистрировать нужный handle, и удаление не сработает.

Когда лучше не удалять, а переиспользовать

Если библиотека нужна нескольким компонентам, безопаснее оставить одно подключение и заставить остальные модули использовать уже загруженный файл. Это особенно важно для jQuery-плагинов и UI-библиотек. Иначе вы получите ситуацию, когда один модуль ожидает одну версию, а другой — другую.

Пошаговое решение: как чистить без риска

Рабочий порядок такой: сначала инвентаризация, потом точечное отключение, затем проверка на реальных страницах.

1. Сделайте список скриптов и стилей на главной, в записи, на странице контактов и в архиве.
2. Отметьте, что повторяется без необходимости.
3. Проверьте, какой плагин или шаблонный файл добавляет каждый handle.
4. Отключайте по одному элементу, а не пачкой.
5. После каждого изменения тестируйте страницу в приватном окне и под незалогиненным пользователем.

Если есть доступ к серверу и вы используете mu-plugin, это удобнее, чем править тему: изменения не исчезнут после обновления.

Как проверить, что решение сработало

Проверка нужна не только на глаз. Смотрите на три вещи: исходный код, сетевые запросы и функциональность.

• В исходнике больше нет wp-emoji-release.min.js, если вы его отключали.
• Одинаковый JS/CSS-файл не загружается дважды.
• Форма отправляется, меню открывается, слайдер работает.
• В консоли нет ошибок Uncaught ReferenceError или $ is not defined.
• Lighthouse или PageSpeed больше не показывают лишние блокирующие ресурсы, если они были связаны именно с этими файлами.

Если после отключения скрипта что-то сломалось, значит зависимость была скрытой. В этом случае возвращайте файл и ищите, какой модуль реально его использует.

Частые ошибки и как их исправить

Удаляют скрипт слишком рано

Типичная ошибка — поставить wp_dequeue_script() без нужного приоритета. Скрипт ещё не зарегистрирован, и удаление не происходит. Решение простое: переносите код на более поздний хук, обычно wp_enqueue_scripts с приоритетом 100 или выше.

Снимают не тот handle

В HTML видно имя файла, но в WordPress удалять нужно именно handle, а не URL. Если handle неизвестен, его надо найти в коде темы или плагина. Иначе вы будете отключать «похожий» файл, а нужный останется на месте.

Ломают зависимости jQuery

Если убрать библиотеку, на которой завязаны другие скрипты, фронтенд начинает сыпать ошибками. Особенно часто это происходит с слайдерами, попапами и анимациями. Перед удалением проверьте, кто вызывает $.fn, jQuery(...) или инициализацию через data-атрибуты.

Правят файл темы напрямую

После обновления тема перезапишет изменения. Для технической чистки лучше использовать дочернюю тему или отдельный mu-plugin. Это не только безопаснее, но и проще для отката.

Безопасность и производительность: что стоит учесть

Чистка скриптов — это не только про скорость. Чем меньше сторонних подключений, тем ниже шанс конфликта версий и неожиданного поведения после обновления плагина. Но агрессивное удаление всего подряд тоже опасно: можно сломать формы, аналитику, редактор блоков или всплывающие окна.

Если у вас много технических дублей, имеет смысл сначала навести порядок в базовой оптимизации сайта: убрать лишние модули, отключить ненужные встроенные функции темы, проверить дубли мета-тегов и генераторов. Для этого иногда удобнее использовать специализированный инструмент вроде Clearfy Pro: он помогает закрыть часть типовых технических задач без ручного вмешательства в каждую мелочь. Но даже с таким плагином проверка после изменений остаётся обязательной.

Когда лучше остановиться и не отключать дальше

Если вы не можете точно определить, кто использует скрипт, не удаляйте его «на удачу». В WordPress техническая оптимизация работает только тогда, когда есть понятная связь между handle, страницей и зависимостью. Если такой связи нет, сначала найдите источник через поиск по коду темы и плагинов, а уже потом вносите изменения.

Самый надёжный сценарий — убрать очевидные системные лишние подключения, затем проверить реальные страницы и только после этого переходить к более тонкой оптимизации. Так вы получите чистый фронтенд без случайных поломок и бесконечного отката изменений.