Тема блога
Справочная страница о TBT: как рассчитывается Total Blocking Time, что означает высокий показатель, как связаны долгие задачи и главный поток и чем TBT отличается от INP.
Материалы
Total Blocking Time помогает обнаруживать длительные задачи JavaScript, мешающие браузеру быстро реагировать на действия пользователя. Разбираем расчёт, нормативные ориентиры, инструменты диагностики и…
TBT, или Total Blocking Time, это лабораторная метрика производительности, которая показывает суммарное время блокировки главного потока во время загрузки страницы. Метрика помогает оценить ситуации, когда браузер занят длительной работой и поэтому не может своевременно обработать потенциальное действие пользователя. web.dev относит TBT к лабораторным показателям отзывчивости при загрузке страницы.
TBT полезен прежде всего для технической диагностики. Высокое значение указывает, что во время загрузки главный поток занят продолжительными задачами. Это может быть выполнение JavaScript, работа сторонних скриптов, вычисления, разбор кода или другие операции, которые не дают браузеру быстро перейти к обработке пользовательского ввода.
На Vagizov.com TBT выделен в отдельную тему технической оптимизации. Это позволяет рассматривать саму метрику, причины блокировки и методы диагностики отдельно от общей темы скорости сайта и от работы с PageSpeed Insights. В разделе технической оптимизации уже существуют отдельные материалы о скорости сайта и PageSpeed Insights, поэтому задача страницы TBT заключается именно в раскрытии Total Blocking Time.
TBT рассчитывается по длительным задачам, выполняемым в главном потоке. В контексте этой метрики Long Task считается задача продолжительностью более 50 миллисекунд. В TBT попадает не вся продолжительность такой задачи, а только время сверх первых 50 миллисекунд.
Например, если задача занимает 70 миллисекунд, её вклад в Total Blocking Time составит 20 миллисекунд. Если во время измеряемого периода возникает несколько таких задач, блокирующие части складываются. Итоговая сумма и формирует TBT.
При стандартном измерении загрузки Lighthouse отслеживает блокирующее время после First Contentful Paint и до Time to Interactive. Таким образом, TBT характеризует период, когда пользователь уже может видеть содержимое страницы, но главный поток всё ещё способен быть занят длительными операциями.
Именно поэтому визуально быстро появившаяся страница не обязательно имеет хороший TBT. Контент может уже отображаться, а браузер в это время продолжает выполнять тяжёлые задачи JavaScript.
web.dev рекомендует стремиться к Total Blocking Time менее 200 миллисекунд при лабораторном тестировании на среднем мобильном оборудовании. Этот ориентир следует воспринимать в контексте конкретной тестовой среды, поскольку TBT является лабораторной метрикой и может меняться при других условиях запуска.
Сравнивать результаты полезнее при одинаковых условиях. Один запуск Lighthouse не следует рассматривать как абсолютную характеристику сайта, особенно если изменения показателя невелики. Для технической работы важнее определить, какие долгие задачи создают блокировку и действительно ли изменения в коде уменьшают нагрузку на главный поток.
Высокий TBT возникает, когда главный поток подолгу занят работой и не может своевременно освободиться для обработки других задач. Одной из наиболее распространённых причин является большое количество JavaScript или слишком длительное выполнение отдельных фрагментов кода. web.dev рекомендует при работе с TBT обращать внимание на блокирующие скрипты, длительные задачи, сторонний код, время выполнения JavaScript и общую нагрузку на главный поток.
Причина не обязательно находится в одном большом файле. Несколько независимых скриптов могут последовательно создавать Long Tasks и в сумме заметно увеличивать показатель.
Загрузка JavaScript файла сама по себе не описывает всю проблему. Полученный код браузеру необходимо разобрать, скомпилировать и выполнить. Если такая работа занимает главный поток на длительное время, пользовательский ввод в этот момент может обрабатываться с задержкой.
Поэтому уменьшение размера передаваемых файлов и уменьшение времени выполнения кода являются связанными, но не идентичными задачами. При диагностике TBT важно смотреть на фактическую работу главного потока.
Аналитика, реклама, виджеты, системы отслеживания, чаты и другие внешние компоненты также способны выполнять JavaScript в основном потоке страницы. Для TBT имеет значение не происхождение кода, а длительность задач, которые он создаёт.
При оптимизации стоит определять реальный вклад стороннего кода, а не отключать интеграции только потому, что они внешние. web.dev отдельно относит снижение влияния стороннего кода к направлениям работы с TBT.
Long Task является ключевым понятием для понимания TBT. Чем дольше задача продолжается после порога в 50 миллисекунд, тем больше её вклад в итоговое блокирующее время. Несколько долгих задач также могут накопить высокий TBT, даже если каждая из них по отдельности не выглядит критической.
Цель диагностики заключается не в механическом достижении определённого количества задач, а в поиске участков работы, которые неоправданно долго удерживают главный поток.
TBT предназначен прежде всего для лабораторных измерений. web.dev рекомендует использовать Lighthouse, а среди лабораторных инструментов также указывает WebPageTest.
В Lighthouse значение Total Blocking Time выводится среди показателей производительности. Однако само число сообщает только о наличии блокировки. Для исправления проблемы необходимо перейти от метрики к источникам долгих задач.
Lighthouse позволяет воспроизводимо оценить TBT в лабораторной среде и связать результат с диагностическими аудитами. В частности, анализ долгих задач главного потока помогает определить скрипты и участки работы, которые создают задержки.
На Vagizov.com работа с самим отчётом PageSpeed Insights рассматривается отдельно. Страница TBT не должна дублировать полное руководство по PageSpeed, а объясняет конкретную метрику и способы интерпретации её значения.
Для более глубокой диагностики недостаточно видеть итоговое число TBT. Инструменты производительности браузера позволяют исследовать временную шкалу выполнения и искать длительные задачи, обработку JavaScript и другие участки, которые занимают главный поток.
Такой подход помогает перейти от формулировки «высокий TBT» к конкретной технической причине. После оптимизации измерение повторяют в сопоставимых условиях и проверяют изменение продолжительности блокировки.
Снижение Total Blocking Time требует уменьшения работы, которая надолго блокирует главный поток. Универсальной настройки для этого нет, поскольку источник нагрузки зависит от архитектуры конкретной страницы.
web.dev среди основных направлений называет оптимизацию Long Tasks, снижение влияния стороннего кода, уменьшение времени выполнения JavaScript и сокращение работы главного потока.
Большая синхронная задача может надолго занять главный поток. В зависимости от приложения такую работу можно разделять на меньшие части или переносить выполнение таким образом, чтобы браузер получал возможность обрабатывать другие задачи между ними.
При этом само количество JavaScript не является единственным критерием. Важна фактическая продолжительность выполнения и то, насколько долго конкретная задача не освобождает главный поток.
Код, который загружается и выполняется без необходимости для текущей страницы, создаёт дополнительную работу браузеру. Поэтому при высоком TBT стоит проверять, какой JavaScript действительно требуется при первоначальной загрузке.
Оптимизация может включать изменение момента запуска функциональности, удаление ненужного кода и пересмотр подключения тяжёлых компонентов. Конкретное решение зависит от устройства сайта и не сводится к одному атрибуту или настройке.
Если заметная доля долгих задач создаётся сторонним скриптом, необходимо оценить его ценность для сайта и возможности изменения способа подключения. Иногда проблема связана не с собственным кодом страницы, а с несколькими внешними сервисами, которые одновременно начинают работу после загрузки документа.
После изменения сторонних интеграций необходимо проверять не только TBT, но и работоспособность аналитики, форм, рекламы и другого функционала, ради которого эти скрипты подключались.
TBT и INP связаны с отзывчивостью страницы, но измеряют её по разным принципам. TBT является лабораторной метрикой и оценивает блокировку главного потока. INP ориентирован на фактические взаимодействия пользователя со страницей.
Низкий TBT часто коррелирует с хорошим INP, поэтому TBT полезен как диагностический индикатор в лаборатории. Однако web.dev прямо указывает, что TBT не является заменой INP.
Лабораторный тест загрузки не знает, когда и с каким элементом взаимодействует реальный пользователь. Страница может иметь небольшой TBT во время первоначальной загрузки, но выполнять тяжёлую работу после конкретного клика. Такая задержка способна повлиять на INP, не проявившись в обычном измерении TBT.
Возможна и обратная ситуация. Лабораторный тест фиксирует блокировку во время загрузки, но реальные пользователи начинают взаимодействовать со страницей уже после завершения этой работы. Поэтому высокий TBT является диагностическим сигналом, а не прямым измерением пользовательского опыта каждого посетителя.
TBT не входит в набор Core Web Vitals. Использовать его корректнее как лабораторную диагностическую метрику, которая помогает искать проблемы с занятостью главного потока и потенциальной отзывчивостью страницы.
Для оценки пользовательского опыта TBT необходимо рассматривать вместе с полевыми показателями, прежде всего INP. Такой подход не смешивает лабораторную диагностику с данными реальных пользователей и позволяет использовать каждую метрику для той задачи, для которой она предназначена.
Total Blocking Time отвечает на достаточно узкий технический вопрос: сколько времени во время измеряемого периода главный поток был заблокирован длительными задачами сверх допустимого для расчёта порога.
Метрика не определяет качество SEO страницы, не показывает скорость сервера и не заменяет остальные показатели производительности. Её задача заключается в диагностике блокирующей работы в браузере.
Поэтому при высоком TBT правильная последовательность работы состоит не в погоне за итоговым числом, а в поиске Long Tasks, определении создающего их кода, устранении ненужной нагрузки и повторном лабораторном измерении. Для оценки реальной отзывчивости после этого необходимо учитывать INP и данные пользователей.
