Если сайт на WordPress грузит лишние CSS и JS-файлы, это почти всегда можно точечно исправить без переделки темы. Но отключать всё подряд нельзя: часть ресурсов нужна самому ядру, часть — конкретным блокам, виджетам или плагинам. Задача здесь не в том, чтобы «обнулить» WordPress, а в том, чтобы убрать то, что реально не используется на вашем сайте.
Ниже разберём, какие встроенные стили и скрипты обычно можно отключить, как это сделать безопасно и как проверить, что после правок ничего не сломалось.
Что именно можно отключать, а что лучше не трогать
В WordPress часть стилей и скриптов подключается ядром автоматически, а часть — темой и плагинами. Отключать имеет смысл только то, что вы точно не используете на сайте. Например, если у вас нет встроенных комментариев, эмодзи, oEmbed-вставок или стандартных блоков, часть связанных ресурсов можно убрать. Если же вы используете эти функции, отключение приведёт к поломке интерфейса или внешнего вида.
Самая частая ошибка — пытаться удалить всё, что видно в исходном коде страницы. Это плохой подход: не каждый файл, который загружается, является лишним. Некоторые стили нужны для админки, некоторые — для отображения блоков Gutenberg, некоторые — для работы плагинов на конкретных страницах.
Практически полезный ориентир такой: сначала смотрите, что реально не используется на сайте, потом отключайте только это. Если ресурс нужен только на одной странице, лучше не удалять его глобально, а ограничить загрузку по условию.
Как понять, какие ресурсы лишние
Перед правками откройте страницу сайта в браузере и посмотрите список подключённых файлов в DevTools, вкладке Network, или через инструменты анализа производительности. Вам нужны именно CSS и JS, которые относятся к WordPress core, теме или плагинам, а не системные файлы браузера.
Полезно ответить на несколько простых вопросов:
- используются ли на сайте эмодзи WordPress;
- нужны ли встроенные комментарии;
- есть ли на сайте oEmbed-вставки из других сервисов;
- используются ли стандартные блоки Gutenberg и их стили;
- подключает ли плагин скрипт на всех страницах, хотя нужен только на одной форме или в одном блоке.
Если вы не уверены, не отключайте ресурс сразу на всём сайте. Сначала проверьте на тестовой копии или хотя бы на одной странице, где можно быстро увидеть побочный эффект.
Отключение встроенных скриптов и стилей через functions.php
Самый прямой способ — добавить код в functions.php дочерней темы или в собственный мини-плагин. Это важно: не правьте файл родительской темы, иначе изменения пропадут после обновления.
Ниже — рабочие примеры для типичных встроенных ресурсов WordPress. Используйте только те блоки, которые вам действительно нужны.
Отключение emoji-скриптов и стилей
Если на сайте не нужны встроенные эмодзи WordPress, можно убрать связанные скрипты и стили. Это безопасно для большинства обычных сайтов, если вы не полагаетесь на старое поведение WordPress в комментариях или редакторе.
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' );
} );Этот код убирает emoji-ресурсы и на фронтенде, и в админке. Если хотите оставить их в админке, не удаляйте строки для admin_print_scripts и admin_print_styles.
Отключение oEmbed
WordPress умеет автоматически превращать ссылки в встроенные блоки предпросмотра. Если вы этим не пользуетесь, можно отключить связанные скрипты и фильтры.
add_action( 'init', function () {
wp_deregister_script( 'wp-embed' );
} );
remove_action( 'rest_api_init', 'wp_oembed_register_route' );
remove_filter( 'oembed_dataparse', 'wp_filter_oembed_result', 10 );
remove_action( 'wp_head', 'wp_oembed_add_discovery_links' );
remove_action( 'wp_head', 'wp_oembed_add_host_js' );Здесь есть важный нюанс: если на сайте уже стоят вставки, завязанные на oEmbed, они могут перестать отображаться корректно. Поэтому сначала проверьте страницы с такими вставками.
Отключение глобальных стилей блока Gutenberg
Если вы не используете стандартные блоки WordPress или у вас тема и так полностью переопределяет их оформление, можно убрать часть встроенных стилей блоков. Но это решение подходит не всем: если на сайте есть обычные записи с блоками, после отключения внешний вид может измениться.
add_action( 'wp_enqueue_scripts', function () {
wp_dequeue_style( 'wp-block-library' );
wp_dequeue_style( 'wp-block-library-theme' );
wp_dequeue_style( 'global-styles' );
}, 100 );Этот вариант часто используют на сайтах, где контент собирается не из стандартных блоков, а из шаблонов темы или конструктора. Если же редактор Gutenberg используется активно, сначала проверьте, не ломается ли типографика, отступы и оформление кнопок.
Отключение Dashicons для гостей
Иконки Dashicons нужны в админке, но на фронтенде они часто не требуются для незалогиненных посетителей. Если тема или плагин не используют их на публичной части сайта, можно не грузить этот файл для гостей.
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_user_logged_in() ) {
wp_deregister_style( 'dashicons' );
}
}, 100 );Это безопаснее, чем отключать Dashicons полностью. Админка продолжит работать, а на фронтенде файл не будет грузиться для обычных посетителей.
Как отключать стили и скрипты плагинов точечно
С плагинами ситуация сложнее: у каждого свой набор стилей и скриптов, а названия handle зависят от конкретного разработчика. Здесь нельзя дать универсальный код для всех случаев. Сначала нужно узнать, как именно называется ресурс, а потом уже отключать его на нужной странице.
Обычно это делается через wp_dequeue_style() и wp_dequeue_script() в хук wp_enqueue_scripts. Пример:
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_page( 'contact' ) ) {
wp_dequeue_style( 'plugin-style-handle' );
wp_dequeue_script( 'plugin-script-handle' );
}
}, 100 );Здесь plugin-style-handle и plugin-script-handle — это не название файла, а внутренний идентификатор, под которым ресурс зарегистрирован в WordPress. Его нужно смотреть в коде плагина, в документации или через инструменты разработчика.
Если ресурс нужен только на одной странице, такой подход лучше глобального отключения. Например, форма обратной связи может использовать свой скрипт только на странице контактов, а на остальных страницах он просто создаёт лишнюю загрузку.
Когда лучше не отключать вручную
Есть ситуации, где ручное отключение встроенных ресурсов даёт больше проблем, чем пользы. Например, если сайт собран на сложной теме с большим количеством зависимостей, а вы не знаете, какой файл за что отвечает. В таком случае легко убрать нужный стиль и получить «поехавшую» верстку или нерабочую кнопку.
Ещё одна типичная ситуация — когда ресурс нужен только на части страниц, но вы не хотите поддерживать собственный набор условий в коде. Тогда удобнее использовать инструмент, который умеет управлять подключениями без ручного редактирования темы. Для таких задач иногда подходит Clearfy Pro: он помогает отключать лишние функции WordPress и чистить сайт от ненужных подключений без постоянного вмешательства в шаблоны. Но даже с таким инструментом всё равно нужно понимать, что именно отключается и где это используется.
Как проверить, что отключение прошло без поломок
После правок не ограничивайтесь одной главной страницей. Откройте несколько типовых разделов сайта: главную, запись, страницу, архив, форму обратной связи, страницу с комментариями, если они есть. Смотрите не только на внешний вид, но и на поведение элементов: меню, кнопки, слайдеры, формы, всплывающие окна, табы.
Проверка должна быть простой и практичной:
- страница открывается без ошибок в консоли браузера;
- не исчезли стили у блоков и виджетов;
- не сломались формы и интерактивные элементы;
- в исходном коде или Network больше не видно отключённого файла;
- страница не потеряла нужный функционал после очистки кэша.
Если у вас включён кэш плагина или серверный кэш, обязательно очистите его после изменений. Иначе вы можете проверять старую версию страницы и сделать неверный вывод, что код не сработал.
Что делать, если после отключения сайт сломался
Если после удаления стиля или скрипта что-то перестало работать, не пытайтесь угадывать наугад. Верните последний изменённый блок кода и проверьте сайт снова. Обычно проблема в одном из трёх случаев: отключили не тот handle, убрали ресурс, который нужен теме, или забыли про зависимость другого скрипта от отключённого файла.
Самый надёжный способ отладки — отключать ресурсы по одному и сразу проверять результат. Так вы быстро поймёте, какой именно файл был критичным. Если изменения делались в functions.php, держите под рукой доступ к файлам сайта через FTP, файловый менеджер хостинга или SSH, чтобы быстро откатить правку.
Если задача именно в точечной оптимизации, а не в глубокой переработке темы, лучше идти от малого: убрать очевидно лишнее, проверить результат, затем переходить к следующему ресурсу. Такой подход безопаснее, чем массово вырезать всё подряд и потом искать, что именно сломалось.