Как отключить отложенную загрузку скриптов в WordPress для критических сценариев

Автор: Максим Белов | Опубликовано: 24.09.2026

Отложенная загрузка JavaScript в WordPress часто помогает ускорить страницу, но иногда она же ломает то, что должно работать сразу: меню, слайдер, форму, табы, попап, счетчик аналитики или скрипт в шапке. Типичный симптом — на десктопе все выглядит нормально, а на мобильном часть интерфейса появляется только после второго клика или вообще не инициализируется.

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

Когда отложенная загрузка действительно мешает

Не каждый “тормозящий” скрипт нужно трогать. Но есть сценарии, где отложенная загрузка почти гарантированно создает побочные эффекты:

скрипт инициализирует элементы выше первого экрана;
код зависит от порядка загрузки и ожидает jQuery или другой библиотечный файл;
скрипт должен отработать до первого взаимодействия пользователя;
в консоли появляются ошибки вида Uncaught ReferenceError, $ is not defined, Cannot read properties of undefined;
после включения оптимизации ломается меню, аккордеон, галерея, фильтр, форма обратной связи.

Что именно ломается чаще всего

На практике чаще всего страдают файлы, которые подключаются через wp_enqueue_script() и завязаны на DOM-ready, но при этом оптимизатор переносит их в футер или добавляет defer. Если зависимость загружается позже, код стартует раньше времени и падает.

Диагностика: как найти проблемный скрипт

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

Откройте страницу в режиме инкогнито.
Посмотрите ошибки в DevTools → Console.
Во вкладке Network найдите JS-файлы, которые грузятся с defer или после основного HTML.
Временно отключите оптимизацию только для одного файла и проверьте результат.

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

Пошаговое решение: отключаем defer точечно

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

<?php
add_filter( 'script_loader_tag', function( $tag, $handle, $src ) {
    $exclude = array( 'theme-main', 'contact-form-7', 'my-slider' );

    if ( in_array( $handle, $exclude, true ) ) {
        $tag = sprintf(
            '<script src="%s"></script>',
            esc_url( $src )
        );
    }

    return $tag;
}, 10, 3 );

Здесь важно понимать логику: если ваш оптимизатор добавляет defer к тегу скрипта, то замена на обычный <script> убирает отложенную загрузку именно для выбранных handle. Такой код лучше размещать в дочерней теме или в небольшом mu-plugin, а не в основной теме, чтобы не потерять правку при обновлении.

Как узнать handle скрипта

Handle задается при регистрации или подключении скрипта в wp_enqueue_script(). Пример:

<?php
wp_enqueue_script(
    'my-slider',
    get_stylesheet_directory_uri() . '/assets/js/slider.js',
    array( 'jquery' ),
    '1.0.0',
    true
);

В этом примере my-slider и есть handle. Именно его удобнее исключать, а не пытаться ловить файл по URL, если у вас есть доступ к коду темы или плагина.

Если оптимизация включена в плагине кеша

У многих плагинов есть список исключений для JavaScript. Это предпочтительнее, чем править ядро темы: после обновления все останется на месте. Логика простая — сначала ищете настройку типа “Exclude JavaScript”, “Delay JS”, “Defer JS”, затем добавляете туда проблемный файл или handle, если плагин это поддерживает.

Подход	Когда подходит	Минус
Исключение в плагине	Если проблема в одном-двух файлах	Зависит от интерфейса конкретного плагина
Хук `script_loader_tag`	Если нужен контроль на уровне кода	Нужно аккуратно поддерживать список handle
Полное отключение defer	Только для диагностики	Падает производительность без необходимости

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

Проверка результата после внедрения

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

Откройте исходный код страницы и найдите нужный <script>.
Проверьте, что у него нет defer или async, если вы их убирали.
Снова откройте Console и убедитесь, что старые ошибки исчезли.
Пройдитесь по сценарию пользователя: открыть меню, отправить форму, переключить таб, запустить слайдер.
Проверьте страницу в мобильной версии и в приватном окне, чтобы исключить влияние кеша браузера.

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

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

Слишком широкое исключение

Самая частая ошибка — отключить defer для всех скриптов сразу. В результате сайт начинает работать, но теряет часть выигрыша по скорости. Правильнее исключать только конкретный handle или файл, который реально ломается.

Правка не в том месте

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

Исключили файл, но забыли зависимость

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

Проверили только кэшированную версию

После правок очистите кеш плагина, серверный кеш и кеш CDN, если он есть. Иначе вы можете смотреть на старый HTML и делать неверные выводы.

Чек-лист перед публикацией изменений

Проблемный скрипт найден по Console или Network.
Исключение добавлено точечно, а не для всех JS-файлов.
Проверен исходный код страницы.
Функция, которая ломалась, работает в мобильной и десктопной версии.
Очищен кеш плагина, сервера и CDN.
Изменение внесено в дочернюю тему или mu-plugin.

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

Не отключайте отложенную загрузку “на всякий случай”. Для большинства страниц defer полезен, а проблема обычно сидит в одном конфликтном файле. Если вы управляете оптимизацией через код, держите список исключений коротким и документируйте, почему каждый handle туда попал. Это упростит поддержку после обновлений темы и плагинов.

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