Как снизить время блокировки страницы (TBT) с помощью отложенной загрузки JavaScript (defer/async)

Отложенная загрузка JavaScript — это метод оптимизации, который позволяет снижать Total Blocking Time (TBT) за счёт правильного последовательного запуска скриптов, не блокирующих отрисовку страницы браузером. Проще говоря, добавляя атрибуты defer или async к некритичным файлам JavaScript, вы уменьшаете нагрузку на главный поток, благодаря чему пользователь видит страницу быстрее, может раньше начать взаимодействовать с ней, а показатели Core Web Vitals улучшаются. Чтобы внедрить отложенную загрузку на вашем сайте, сначала нужно определить критичные скрипты, затем применять defer для зависимых между собой файлов, а async — для независимых сторонних скриптов и после изменений обязательно измерять TBT с помощью PageSpeed Insights, Lighthouse и Chrome DevTools.

В современных сайтах производительность зачастую страдает не из-за изображений, а из-за неконтролируемого использования JavaScript. Например, если на интернет-магазине одновременно грузятся фильтры товаров, онлайн-чат, рекламные пиксели, аналитика, виджеты для отзывов, инструменты A/B-тестирования и скрипты темы, главный поток браузера будет долго занят. Особенно это заметно на мобильных устройствах: пользователь может увидеть заголовок, но при касании меню реакция будет отсутствовать, а в отчёте Lighthouse TBT будет высоким.

В этом руководстве мы подробно расскажем, что делают атрибуты defer и async, когда и как их применять, как внедрить их в WordPress и кастомных проектах, на что обращать внимание при измерениях и какие реальные улучшения в TBT можно ожидать. Рекомендации подходят для сайтов на инфраструктуре Hostragons и базируются на общемировых веб-стандартах. Также мы затронем, как правильный хостинг, CDN, SSL и кэширование поддерживают оптимизацию JavaScript. Пакеты веб-хостинга Hostragons

Что такое TBT и почему он так тесно связан с JavaScript?

TBT (Total Blocking Time) — это метрика, измеряющая время блокировки главного потока браузера, из-за которой страница не готова к взаимодействию с пользователем. В лабораторных тестах Lighthouse TBT считается в промежутке между First Contentful Paint и Time to Interactive — если отдельные задачи JavaScript выполняются дольше 50 мс, их время сверх этого увеличивает TBT. К примеру, задача, выполняющаяся 180 мс, добавит к TBT 130 мс (180 минус 50).

Эта метрика критична для пользовательского опыта. Если посетитель пытается нажать на меню, кнопку "в корзину" или строку поиска, а браузер всё ещё обрабатывает JavaScript, реакция задерживается. Пользователь воспринимает это как зависание, медленную работу или проблемы с сайтом. В SEO-стандартах 2026 года Google не сводит оценку опыта страницы к одной цифре, но сайты с быстрой и стабильной интерактивностью получают преимущество как по удовлетворённости пользователей, так и по конверсии.

Типичные признаки высокого TBT

• В отчёте мобильного PageSpeed Insights значение TBT превышает 300 мс.
• В Lighthouse появляются предупреждения Reduce JavaScript execution time или Minimize main-thread work.
• Страница визуально загружена, но меню, слайдеры, фильтры или формы реагируют с задержкой.
• Третьесторонние рекламные, чат-виджеты или аналитические скрипты показывают высокую нагрузку в отчётах.
• На бюджетных Android-устройствах заметны задержки при прокрутке и нажатиях.

Хорошей практикой считается держать TBT ниже 200 мс для большинства контентных сайтов. Для более сложных интернет-магазинов или SaaS-интерфейсов одних defer и async может быть недостаточно: потребуется разделение кода, удаление лишних пакетов, улучшение кэширования, ускорение ответа сервера и оптимизация критического CSS. Тем не менее отложенная загрузка JavaScript — один из первых и наиболее эффективных шагов для большинства проектов.

Что такое defer и async?

По умолчанию, когда браузер встречает тег script, он приостанавливает парсинг HTML, загружает и выполняет скрипт, а затем продолжает обработку страницы. Это бывает необходимо для критичных скриптов, но при массовом использовании создаёт задержки. Атрибуты defer и async меняют этот процесс, позволяя загружать и запускать скрипты асинхронно по разным правилам.

Как работает defer?

Скрипт с defer загружается параллельно с разбором HTML, но выполняется только после полной загрузки и построения DOM. Несколько скриптов с defer выполняются строго в порядке появления в документе, что важно для зависимостей. Например, если сначала загружается библиотека, а затем связанный с ней скрипт темы — defer отлично подходит.

Пример: <script defer src=/js/app.js></script>. В этом случае app.js не блокирует первичную отрисовку, а запускается после готовности страницы. Современные браузеры широко поддерживают defer, и это надёжный способ оптимизации классических скриптов.

Как работает async?

Скрипт с async тоже загружается параллельно с парсингом HTML, но запускается сразу после загрузки, не дожидаясь окончания разбора документа. При этом HTML-парсер может на короткое время приостановиться. Async не гарантирует порядок выполнения — тот скрипт, который загрузится первым, запустится первым. Это подходит для независимых сторонних скриптов: аналитики, рекламы, пикселей и виджетов.

Пример: <script async src=/js/analytics.js></script>. Этот скрипт не должен зависеть от других локальных библиотек или переменных, иначе может возникнуть ошибка. Async быстрый, но требует аккуратной классификации файлов.

Таблица сравнения defer и async

Практическое правило: если скрипт должен выполняться по порядку — используйте defer. Если он полностью независим — async. Если сомневаетесь, сначала тестируйте defer в staging-среде, проверяйте консоль на ошибки и критические взаимодействия. Руководство по staging-окружению и резервному копированию

Пошаговый план внедрения отложенной загрузки JavaScript

Просто добавить defer или async ко всем скриптам — опасно. Это может сломать важные функции, такие как оплата, поиск, меню, валидация форм и корзина. Для корректной оптимизации нужен цикл: измерение, классификация, небольшие изменения, тестирование и мониторинг.

1. Измерьте текущую производительность

Перед началом создайте базовую метрику. Снимите результаты мобильного и десктопного PageSpeed Insights. В отчёте Lighthouse сохраните показатели TBT, First Contentful Paint, Largest Contentful Paint и Speed Index. В Chrome DevTools на вкладке Performance посмотрите главный поток, где длинные жёлтые блоки — это время парсинга, компиляции и выполнения JavaScript.

Например, можно подготовить таблицу: мобильный TBT 780 мс, время выполнения JS 2,8 с, работа главного потока 4,5 с. После оптимизации при снижении TBT до 280 мс вы получите около 64% улучшения. Такие данные помогают команде видеть, какие изменения работают.

2. Создайте инвентаризацию скриптов

В исходном коде страницы или во вкладке Network соберите список всех загружаемых JavaScript-файлов. Определите источник, размер, время необходимости и зависимости каждого. Разделите их на группы:

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

Иногда лучшая оптимизация — не отложить, а вовсе удалить ненужный скрипт. Сжатый файл 90 КБ на слабом устройстве может потребовать более 300 мс на парсинг и выполнение. Поэтому сначала убирайте лишнее, потом оптимизируйте оставшееся.

3. Определите скрипты для defer

Чаще всего это основные скрипты темы, меню, слайдеров, галерей и основных бандлов приложения. Важно, чтобы они не использовали устаревшие блокирующие методы вроде document.write и могли запускаться после готовности DOM.

В WordPress темы jquery-migrate, основные файлы темы и скрипты плагинов часто имеют сложные зависимости. Делать jQuery async рискованно — многие плагины ждут именно её загрузки. Лучше применять defer к зависимым скриптам или использовать оптимизированные настройки загрузки на уровне плагина. Руководство по оптимизации скорости WordPress

4. Выберите скрипты для async

Google Analytics, рекламные теги, Facebook Pixel, LinkedIn Insight Tag, некоторые сторонние чат-виджеты и коды соцсетей подойдут для async. Однако не все сторонние скрипты одинаковы: некоторые чаты хотят инициализироваться сразу, некоторые рекламные системы ждут определённого порядка загрузки. Проверяйте документацию.

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

5. Добавьте условную и событийную загрузку

Defer и async — отличный старт, но ещё сильнее снизить TBT помогает загрузка скриптов по поведению пользователя. Онлайн-чат можно запускать не сразу, а через 5 секунд или по клику на кнопку помощи. Карты загружать при прокрутке до контактов, видеоплеер — при нажатии кнопки воспроизведения.

Такой подход особенно эффективен для контентных и корпоративных сайтов, где не все виджеты нужны на каждой странице. Удаление из начальной загрузки 200 КБ JavaScript может уменьшить TBT на сотни миллисекунд на слабых мобильных устройствах.

6. Тестируйте и выкатывайте постепенно

Не внедряйте изменения сразу на боевой сайт — сначала проверяйте в тестовой среде. Прогоняйте ручное тестирование на главной, категориях, страницах товаров и услуг, контактах, формах входа и оплатах. Следите за консолью браузера на предмет ошибок типа Cannot read property, is not defined или undefined function — это признаки проблем с порядком загрузки или зависимостями.

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

Особенности применения defer и async в WordPress

В WordPress JavaScript подключается через wp_enqueue_script в темах и плагинах. Начиная с 2026 года, современные версии WP позволяют более гибко управлять стратегиями загрузки, но старые темы, конструкторы страниц и несовместимые плагины могут создавать конфликты.

Если используете плагин для оптимизации, не отложите весь JavaScript одним кликом — создайте исключения. Скрипты на страницах оплаты, авторизации, админ-панели, проверки безопасности и капчи должны работать без задержек. На сайтах с WooCommerce тщательно тестируйте скрипты корзины, платёжных шлюзов и селекторов вариаций. Решения хостинга WooCommerce

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

Что важно учитывать в кастомных проектах и фреймворках

В проектах на React, Vue, Angular, Next.js, Nuxt и других современных фреймворках оптимизация JavaScript — это не просто добавление defer к тегам script. Ключевые факторы — размер бандла, разделение кода, tree shaking, динамический импорт и стоимость hydration. Если главный бандл весит 700 КБ, даже с defer главный поток будет долго загружен.

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

Если в проекте используется серверный рендеринг или статическая генерация, будьте внимательны: даже при быстрой загрузке HTML при hydration может активироваться сотни компонентов одновременно, что увеличит TBT. Избегайте лишнего клиентского JavaScript там, где он не нужен — один из основных трендов производительности в 2026 году.

Влияние хостинга и времени ответа сервера на производительность JavaScript

TBT напрямую зависит от времени выполнения JavaScript в браузере, но инфраструктура хостинга косвенно влияет на скорость загрузки файлов. Медленный TTFB, отсутствие сжатия, поддержка только HTTP/1.1, слабое кэширование и удалённые серверы увеличивают задержки доставки скриптов. Чем позже файлы попадают в браузер, тем дольше длится жизненный цикл страницы и хуже опыт пользователя.

Качественный хостинг с поддержкой Brotli или Gzip, эффективным кэшированием, актуальной версией PHP, быстрыми дисками и интеграцией CDN улучшает оптимизацию. Правильная настройка SSL-сертификатов важна для современных браузерных функций, HTTP/2 и безопасной работы сторонних сервисов. SSL сертификаты Hostragons Проверка домена Hostragons

Например, JavaScript-файл размером 320 КБ без сжатия может уменьшиться до 95 КБ с Brotli. Это не значит, что TBT упадёт в 3 раза, поскольку метрика отражает время выполнения, а не загрузки. Но скачивание будет быстрее, браузер сможет приоритезировать ресурсы, и общий опыт улучшится. Поэтому defer, async, кэширование и правильный хостинг должны рассматриваться комплексно.

Контрольный список для проверки оптимизации

Чтобы понять, действительно ли оптимизация сработала, смотрите не только на PageSpeed, но и на реальные показатели:

• Сравните мобильный TBT до и после изменений.
• Уменьшилось ли время выполнения самых тяжёлых JavaScript-файлов?
• Снизилось ли количество длинных задач в Chrome DevTools Performance?
• Нет ли ошибок JavaScript в консоли?
• Работают ли меню, поиск, фильтры, формы, корзина и процесс оплаты без сбоев?
• Правильно ли запускаются сторонние аналитика и рекламные теги?
• Улучшились ли реальные показатели взаимодействия, такие как INP и задержки реакций?
• Проводились ли повторные тесты после очистки кэша?

Важный момент — разделять лабораторные и реальные данные. TBT — лабораторная метрика Lighthouse, а в реальных условиях важнее Interaction to Next Paint (INP). Тем не менее снижение TBT часто помогает улучшить INP за счёт уменьшения блокировок главного потока.

Типичные ошибки и как их избежать

Использование async для всех скриптов подряд

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

Неправильное отложение jQuery и зависимых плагинов

На многих WordPress-сайтах плагины зависят от jQuery. Если сделать jQuery async, плагины могут начать выполняться до её загрузки, что приводит к ошибкам. Решение — изучить зависимости и исключить критичные скрипты из отложенной загрузки.

Игнорирование контроля сторонних скриптов

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

Установка плагинов без предварительного анализа

Плагины для ускорения могут помочь, но без измерений новый инструмент может добавить лишний JavaScript и CSS. Сначала выявите проблему, затем выбирайте инструмент и проверяйте результаты тестами.

Пренебрежение конфликтами кэширования и минификации

Если минификация, объединение и отложенная загрузка применяются одновременно, порядок файлов может нарушиться. Это приводит к ошибкам в продакшене. Особенно если у вас CDN, серверное и клиентское кэширование — после изменений очищайте все слои кэша.

Реальный сценарий оптимизации

Представим корпоративный сайт среднего размера с 18 запросами JavaScript на главной странице. Из них 5 — скрипты темы и меню, 4 — слайдер и анимация, 3 — формы и карта, 6 — аналитика, пиксели и чат. Исходный TBT по Lighthouse для мобильных — 920 мс.

На первом этапе удаляются два неиспользуемых анимационных плагина, снижая объём сжатого JavaScript на 140 КБ, TBT падает до 760 мс. Затем основные скрипты темы и слайдеры переводятся в defer с проверкой зависимостей — TBT снижается до 480 мс. На третьем этапе скрипт карты загружается при прокрутке до контактов, чат запускается через 7 секунд после загрузки, аналитика и пиксели переводятся в async. Финальный TBT — около 210 мс.

Этот пример показывает, что однократной настройки недостаточно. Только комплексный, многоуровневый подход с удалением лишнего, условной загрузкой, кэшированием и качественным хостингом даёт наилучший результат.

Итог: сбалансированная и проверенная стратегия загрузки JavaScript для снижения TBT

Отложенная загрузка JavaScript — один из самых простых и эффективных способов снизить TBT. defer безопасно использовать для последовательных скриптов, запускаемых после готовности DOM, async отлично подходит для независимых сторонних скриптов. Для успешной оптимизации нужно сначала измерить текущие показатели, классифицировать скрипты, убрать ненужные, постепенно тестировать изменения и отслеживать реальный пользовательский опыт.

Использование быстрой, надёжной и масштабируемой инфраструктуры Hostragons совместно с оптимизацией JavaScript, кэшированием и правильной настройкой SSL обеспечит стабильную и высокую производительность вашего сайта. Начните с анализа текущих отчётов и двигайтесь малыми, но измеримыми шагами. Решения Hostragons помогут подобрать оптимальный хостинг и инфраструктуру. Пакеты веб-хостинга Hostragons

Часто задаваемые вопросы

Можно ли использовать defer и async одновременно?

Если в одном теге script указать одновременно defer и async, современные браузеры будут отдавать приоритет async, что нарушит порядок выполнения. Поэтому не рекомендуется применять оба атрибута к одному файлу. Лучше использовать defer для зависимых скриптов, async — для независимых.

Повысит ли отложенная загрузка JavaScript напрямую SEO-позиции?

Прямого гарантирующего улучшения в ранжировании нет, но улучшение пользовательского опыта, скорости отклика и Core Web Vitals способствует лучшему восприятию сайта поисковыми системами. Быстрые и отзывчивые страницы повышают удовлетворённость посетителей, конверсию и качество индексации.

Безопасно ли добавлять defer ко всем JavaScript-файлам?

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

Достаточно ли только defer и async для снижения TBT?

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

Какие скрипты в WordPress не стоит делать async?

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