Как убрать лишние скрипты и стили WordPress с помощью functions.php

Если сайт на WordPress грузит слишком много CSS и JavaScript, чаще всего проблема не в самом движке, а в теме и плагинах. Они подключают ресурсы на всех страницах, даже когда нужны только на одной. Убрать лишние скрипты и стили можно через functions.php, но делать это нужно точечно: сначала понять, что именно подключается, потом отключать только ненужное и сразу проверять результат.

Самый безопасный подход такой: не править ядро WordPress и не удалять файлы плагинов вручную, а снять регистрацию или вывод конкретных ресурсов на нужных страницах через хуки wp_enqueue_scripts и admin_enqueue_scripts. Это работает в большинстве обычных тем и плагинов, если они подключают ассеты стандартным способом.

Что именно можно отключать без риска

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

Обычно безопаснее всего начинать с ресурсов, которые:

  • подключаются глобально, но нужны только на отдельных страницах;
  • относятся к неиспользуемым функциям темы;
  • приходят от плагинов, которые работают только в админке, а не на фронтенде;
  • дублируют уже загруженные библиотеки, если вы точно знаете, что вторая копия не нужна.

Если сомневаетесь, сначала отключайте ресурс только на одной конкретной странице или типе записей, а не на всём сайте.

Как понять, какой файл подключает тема или плагин

Перед тем как что-то убирать, нужно увидеть список подключённых ресурсов. Проще всего открыть инструменты разработчика в браузере и посмотреть вкладку Network, либо использовать плагины для анализа ассетов. В исходном коде страницы CSS обычно виден как <link rel="stylesheet" ...>, а JS — как <script src="...">. По имени файла часто уже понятно, откуда он пришёл: тема, конкретный плагин или библиотека вроде jQuery.

Если ресурс подключён через WordPress стандартно, у него обычно есть handle — внутреннее имя, по которому его можно снять с очереди. Именно это имя и нужно для кода в functions.php. Важно: в HTML вы видите URL файла, а в коде WordPress отключают не URL, а handle.

Отключение скриптов и стилей через functions.php

Для точечного отключения используют wp_dequeue_script(), wp_dequeue_style(), а иногда ещё wp_deregister_script() и wp_deregister_style(). В большинстве случаев достаточно снять ресурс с очереди, а не удалять его регистрацию.

Ниже пример, который отключает конкретный скрипт и стиль на фронтенде. Перед использованием замените example-handle на реальный handle вашего ресурса.

add_action( 'wp_enqueue_scripts', function () {
    if ( ! is_admin() ) {
        wp_dequeue_script( 'example-handle' );
        wp_dequeue_style( 'example-style-handle' );
    }
}, 100 );

Приоритет 100 здесь важен: он помогает выполнить код позже, чем тема или плагин успеют подключить свои файлы. Если поставить слишком ранний приоритет, отключение может не сработать.

Если нужно убрать ресурс только на определённой странице, используйте условные теги WordPress. Например, так можно отключить файл только на странице контактов:

add_action( 'wp_enqueue_scripts', function () {
    if ( is_page( 'contacts' ) ) {
        wp_dequeue_script( 'example-handle' );
        wp_dequeue_style( 'example-style-handle' );
    }
}, 100 );

Вместо contacts можно указать ID страницы, её слаг или другой подходящий условный тег. Это удобнее и безопаснее, чем отключать ресурс по всему сайту.

Когда нужен wp_deregister_*

wp_deregister_script() и wp_deregister_style() используют реже. Они не просто убирают файл из очереди, а полностью снимают регистрацию. Это полезно, если плагин или тема потом снова пытаются подключить тот же ресурс, или если вы хотите заменить его своей версией. Но для обычной оптимизации чаще хватает wp_dequeue_*.

Если вы не уверены, начинайте именно с wp_dequeue_*. Так меньше шанс сломать зависимости между файлами.

Как отключать ресурсы только там, где они не нужны

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

Пример для отключения скрипта комментариев на страницах, где комментарии закрыты или не используются:

add_action( 'wp_enqueue_scripts', function () {
    if ( ! is_singular() || ! comments_open() || ! get_option( 'thread_comments' ) ) {
        wp_dequeue_script( 'comment-reply' );
    }
}, 100 );

Это штатный скрипт WordPress, и его часто можно убрать, если у вас нет древовидных комментариев. Но если комментарии на сайте используются, не отключайте его без проверки сценария ответа на комментарий.

Ещё один рабочий сценарий — отключать ресурсы плагина только на страницах, где его функциональность не нужна. Например, если плагин форм подключает CSS на всех страницах, а форма стоит только на одной, имеет смысл оставить его стили только там.

Что проверить после отключения

После каждого изменения обновите страницу в режиме инкогнито или с очищенным кэшем и проверьте три вещи: не сломалась ли верстка, не исчез ли нужный функционал и действительно ли ресурс пропал из HTML. Иногда кэш плагина, CDN или браузера мешает увидеть результат сразу.

Проверка обычно выглядит так:

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

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

Типичные ошибки, из-за которых отключение не работает

Чаще всего проблема не в самом коде, а в том, что ресурс отключают не тем способом или не в том месте. Вот что встречается на практике:

  • пишут правильную функцию, но указывают не тот handle;
  • добавляют код слишком рано, до подключения ассетов;
  • пытаются отключить файл, который тема выводит не через enqueue, а напрямую в шаблоне;
  • забывают про кэш;
  • отключают библиотеку, от которой зависят другие скрипты.

Если файл подключён напрямую через <script> или <link> в шаблоне темы, стандартные функции WordPress его не уберут. Тогда нужно править сам шаблон или дочернюю тему, а не только functions.php.

Как не сломать сайт при чистке ресурсов

Работайте через дочернюю тему или через отдельный мини-плагин, если изменения должны пережить обновление темы. Перед правками сделайте резервную копию файлов и базы данных. Это не формальность: одна неверная строка в functions.php может дать белый экран, если в коде будет синтаксическая ошибка.

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

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

В итоге логика простая: сначала находите, что именно грузится, потом отключаете только ненужное и только там, где это безопасно. Для WordPress это самый надёжный способ убрать лишние скрипты и стили без лишнего риска для темы и плагинов.

Вам также может быть интересно:

Как закрыть от индексации страницы поиска WordPress
01.11.2026
Как добавить многофакторную авторизацию в WordPress для защиты входа
25.08.2026
Как настроить кэширование в WordPress: страницы, браузерный кэш и серверный кэш
16.10.2026
Как добавить защиту reCAPTCHA на страницу входа в WordPress
25.09.2026
Как защитить WordPress от взлома и автоматических атак
03.10.2026
×

AI-плагин

WPGPT
Сам создает статьи для вашего сайта WordPress

SEO и мета-теги

Парсинг конкурентов

Изображения

Комментарии

Подробнее