Total Blocking Time: зачем нужен, как проверить и снизить TBT для SEO

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

Total Blocking Time (TBT) помогает обнаружить такую нагрузку. Метрика измеряет суммарную блокирующую часть длительных задач во время начальной загрузки страницы. Её используют в Lighthouse и PageSpeed Insights для диагностики отзывчивости.

При этом TBT нельзя воспринимать как самостоятельную оценку SEO. Его задача — показать техническую проблему, найти её источник и помочь проверить эффект оптимизации.

Как рассчитывается Total Blocking Time

Браузер выполняет в основном потоке множество операций: обрабатывает JavaScript, изменяет DOM, рассчитывает стили и подготавливает отображение элементов.

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

Длительной считается задача, которая выполняется более 50 миллисекунд. Но в TBT попадает не вся её продолжительность, а только время сверх этого порога.

Формула для отдельной задачи:

Блокирующее время = max(0, длительность задачи − 50 мс)

Предположим, во время измерения браузер выполнил три задачи:

Длительность задачи	Вклад в TBT
180 мс	130 мс
90 мс	40 мс
35 мс	0 мс
Итого	170 мс

Суммарное блокирующее время составит 170 мс, а не 305 мс — общей продолжительности этих задач.

В стандартном измерении Lighthouse учитывается интервал между First Contentful Paint (FCP) — появлением первого содержимого — и Time to Interactive (TTI), то есть моментом достижения устойчивой интерактивности по методике инструмента. TTI больше не выводится как самостоятельная основная метрика Lighthouse, но продолжает использоваться для определения периода расчёта TBT.

Какой TBT считается хорошим

Оценивать показатель нужно с учётом типа устройства. Lighthouse использует разные ориентиры для мобильных и десктопных измерений.

Оценка	Мобильная версия	Десктоп
Хорошо	До 200 мс	До 150 мс
Требует улучшения	Более 200–600 мс	Более 150–350 мс
Плохо	Более 600 мс	Более 350 мс

Это лабораторные ориентиры Lighthouse, а не норматив скорости для всех пользователей и не пороги индексации.

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

Для реальной оценки отзывчивости используется Interaction to Next Paint (INP). Эта метрика входит в Core Web Vitals и отражает задержки взаимодействий реальных пользователей. Хорошим ориентиром INP считается значение не выше 200 мс.

TBT полезен для поиска причин плохой отзывчивости, но не заменяет INP. Низкий TBT при загрузке не исключает тяжёлого обработчика клика, который сработает позднее.

Как проверить TBT и найти конкретную блокирующую задачу

PageSpeed Insights и Lighthouse

Для первичной диагностики достаточно PageSpeed Insights. Инструмент позволяет запустить проверку конкретной страницы и отдельно изучить мобильную и десктопную версии.

TBT находится в лабораторной части отчёта Lighthouse. Его не следует искать среди пользовательских Core Web Vitals: в данных CrUX отображаются другие показатели, включая INP, LCP и CLS.

При анализе важно зафиксировать:

• значение TBT в миллисекундах;
• тип проверяемого устройства;
• объём времени, затраченного на выполнение JavaScript;
• наличие длительных задач основного потока;
• рекомендации по сокращению и оптимизации скриптов.

Одного числа недостаточно. TBT в 800 мс показывает масштаб проблемы, но не объясняет, какой именно файл её создаёт.

Chrome DevTools: поиск причины

Для детальной диагностики откройте Chrome DevTools и панель Performance, запишите загрузку проблемной страницы и изучите дорожку Main.

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

Особое внимание стоит уделить обработке JavaScript, пересчёту стилей, построению интерфейса и стороннему коду.

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

Что действительно помогает снизить TBT на WordPress

У TBT нет универсальной настройки в WordPress или параметра php.ini, который автоматически уменьшит блокировку браузера. Исправлять нужно операции, из-за которых основной поток остаётся занятым.

Убирать ненужный JavaScript

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

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

Правильнее загружать такой код там, где он действительно используется. Это сокращает объём обработки и уменьшает вероятность появления длительных задач.

Изменять стратегию подключения скриптов

WordPress поддерживает стратегии defer и async через функцию wp_enqueue_script().

Пример подключения собственного скрипта с defer:

add_action( 'wp_enqueue_scripts', function () {
    wp_enqueue_script(
        'site-ui',
        get_stylesheet_directory_uri() . '/assets/js/site-ui.js',
        array(),
        null,
        array(
            'in_footer' => true,
            'strategy'  => 'defer',
        )
    );
} );

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

Атрибут defer откладывает выполнение внешнего скрипта до завершения разбора HTML и сохраняет порядок выполнения отложенных скриптов. async выполняет код по готовности загрузки файла и не гарантирует такой порядок.

Но defer не является автоматическим исправлением TBT. Скрипт по-прежнему может выполнять тяжёлую задачу после появления первого содержимого страницы. WordPress также учитывает зависимости и может выбрать другую допустимую стратегию выполнения.

После изменения подключения необходимо проверить фактически сформированный HTML и работу интерфейса.

Разбивать длительные вычисления

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

Для этого используются подходы с разделением работы, планированием выполнения и, при подходящей архитектуре, Web Workers.

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

Контролировать сторонние скрипты

Системы аналитики, онлайн-чаты, рекламные модули и встроенные виджеты способны создавать собственные длинные задачи.

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

Практический пример: высокий TBT на странице услуги

Рассмотрим условную страницу WordPress с интерактивным меню, калькулятором стоимости, формой заявки и несколькими сторонними виджетами.

В мобильном тесте обнаружены три блокирующие задачи внутри измеряемого интервала:

Источник задачи	Длительность	Блокирующее время
Инициализация виджета	420 мс	370 мс
Обработка интерфейса	250 мс	200 мс
Построение дополнительного блока	120 мс	70 мс
Итого		640 мс

Это учебный пример расчёта, а не измерения конкретного сайта.

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

После исключения ненужного модуля и переработки кода оставшиеся операции занимают 140, 85 и 45 мс.

Новый расчёт:

(140 − 50) + (85 − 50) + 0 = 125 мс

В пределах модели блокирующее время уменьшилось с 640 до 125 мс.

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

Кроме того, успешной оптимизацией считается не только снижение TBT. Меню должно открываться, калькулятор — правильно считать, форма — отправлять данные, а события аналитики — регистрироваться согласно требованиям проекта.

Как TBT связан с SEO, рендерингом и индексацией

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

TBT не относится к Core Web Vitals. Google учитывает показатели Core Web Vitals в системах ранжирования, но не подтверждает отдельного прямого влияния TBT на позиции. Даже отличные показатели производительности не гарантируют высоких результатов поиска.

Второй момент — рендеринг JavaScript. Googlebot способен выполнять JavaScript и использовать обработанный HTML при индексировании. Поэтому ошибки в клиентском коде действительно могут приводить к отсутствию важного содержимого в отрисованной версии страницы.

Но высокий TBT сам по себе не доказывает такую ошибку. Он не сообщает, проиндексирована ли страница, видит ли Googlebot основной контент и обнаруживает ли внутренние ссылки.

Если есть подозрение на проблему с индексированием, нужны отдельные проверки:

• доступности URL и корректности HTTP-статуса;
• содержимого исходного и отрисованного HTML;
• видимости основного текста и ссылок для Googlebot;
• отчёта проверки URL в Google Search Console.

Снижать TBT ради исправления несуществующей проблемы индексации бессмысленно. А вот устранять ошибки JavaScript, из-за которых реальный контент отсутствует в отрисованном HTML, необходимо независимо от значения TBT.

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

Один удачный запуск Lighthouse ещё не означает устойчивого улучшения.

Корректное сравнение требует одинаковых условий: того же URL, режима устройства, версии инструмента и максимально сопоставимого окружения. Желательно выполнить несколько проверок до и после изменений и сравнить типичные результаты, а не выбирать наименьшее значение.

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

Технический: сократилось ли число и продолжительность длительных задач? Исчезли ли именно те операции, ради которых изменяли код?

Функциональный: работают ли меню, формы, интерактивные элементы, аналитика и другие необходимые функции?

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

Важно учитывать, что TBT и пользовательские метрики собираются разными способами. Полевые показатели не обязаны измениться сразу после публикации исправления.

Приоритет разумно отдавать изменениям, которые сокращают ненужное выполнение JavaScript, устраняют тяжёлые операции и не создают новых проблем для пользователя.

Главный ориентир — не идеальный балл Lighthouse, а страница, которая быстро отображается, отвечает на действия и сохраняет всю необходимую функциональность.