TBT: как читать время блокировки браузера

Что блокируется

Главный поток выполняет JavaScript и другую работу, необходимую для интерфейса. Пока длинная задача не завершилась, браузер не может просто прервать её, чтобы обработать новое действие. В TBT считают часть длительности такой задачи свыше 50 мс. Короткие задачи в эту сумму не входят.

Поэтому TBT не равен суммарному времени всех скриптов. Две страницы с одинаковым объёмом вычислений могут по-разному распределять работу: одна выполняет её длинными непрерывными участками, другая даёт браузеру промежутки для обработки других задач. Для пользователя это может ощущаться по-разному.

Ноль является допустимым измеренным результатом TBT в выбранном интервале. Но отсутствие показателя нельзя записывать как 0. Если тест не выполнился, нужно сохранить ошибку или «нет данных». Даже настоящий ноль не подтверждает, что позже на странице не возникнет тяжёлое взаимодействие.

Интервал начинается после FCP, первого отображения содержимого. В обычном тесте загрузки Lighthouse наблюдение TBT по умолчанию заканчивается у TTI, момента устойчивой интерактивности. Другие режимы могут измерять более длинный участок записи. Поэтому при сравнении нужны не только миллисекунды, но и одинаковые границы теста.

Пример расчёта без скрытой формулы

Возьмём учебную последовательность из трёх задач: 40, 120 и 80 мс. У первой блокирующая часть равна 0, у второй 70, у третьей 30 мс. Сумма для TBT составляет 100 мс. Общая длительность этих задач равна 240 мс, поэтому подмена одного числа другим даст неверную интерпретацию.

Этот пример не является замером сайта. Он показывает, почему одна длинная задача может быть важнее нескольких коротких, и почему число запросов либо размер JavaScript не переводятся непосредственно в TBT. Чтобы исследовать настоящую страницу, нужны длительности задач и интервал конкретной записи.

Почему это не INP

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

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

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

Как найти тяжёлую работу

1. Зафиксируйте URL, мобильный или компьютерный режим, время и условия запуска. Сравнение разных страниц или разных режимов не проверяет одну и ту же проблему.
2. Посмотрите TBT в лабораторном отчёте и сохраните связанные рекомендации. Не делайте вывод о причине только по общему Performance.
3. Запишите загрузку страницы в Performance. Найдите длинные задачи и выясните, какие скрипты или операции занимают главный поток.
4. Отделите необходимую работу первого экрана от необязательных виджетов и поздних функций. Сформулируйте конкретное изменение, сохранив нужные действия пользователя.
5. После правки повторите сопоставимый запуск и важные взаимодействия. Проверьте ошибки, доступность элементов и правильное завершение операций, а не только уменьшение числа.

Что может уменьшить блокировку

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

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

Учебный пример: каталог пересчитывает большую таблицу сразу после загрузки. Возможные вопросы: нужен ли весь расчёт сейчас, можно ли сократить объём и показать полезный результат раньше? Это направления эксперимента. Из одного высокого TBT нельзя установить, виноват ли каталог, аналитика или другой код.

Ошибки при сравнении результатов

• Сравнивать только самый удачный запуск. Разброс требует проверки условий и повторов; выбор лучшего числа может скрыть реальное поведение.
• Удалять все внешние скрипты без проверки назначения. Так можно сломать формы, оплату или необходимые функции вместо обоснованного исправления конкретной задачи.
• Считать уменьшение TBT подтверждением всех Core Web Vitals. LCP, CLS и INP описывают другие стороны опыта и проверяются отдельно.

Как читать отчёт Seohonest

В проверке скорости TBT показан как лабораторная метрика рядом с LCP и CLS. Сохраняйте URL, режим и фактическую дату измерения, включая результат из кеша. Сравнивайте одинаковые условия. Общий балл и выполнение рабочего минимума не заменяют разбор конкретной блокирующей работы.

Для задачи разработчику приложите профиль, отмеченную длинную задачу и сценарий, которому она мешает или потенциально может мешать. Если взаимодействие не проверялось, не пишите «исправлен INP». Честный результат описывает измеренное изменение TBT и отдельно подтверждённое поведение интерфейса.