Показатель Total Blocking Time измеряет суммарную продолжительность блокировки основного потока браузера длительными задачами во время загрузки страницы, препятствуя его реагированию на ввод пользователя. Он суммирует долю каждой задачи, превышающую пятьдесят миллисекунд, учитывая только превышение, и измеряется в лабораторных условиях между моментом First Contentful Paint и моментом, когда страница становится надежно интерактивной.
Его цель — служить лабораторным аналогом отзывчивости, которую трудно измерить без реального взаимодействия с пользователем. Поскольку взаимодействие с функцией Next Paint требует фактического ввода данных пользователем, его невозможно зафиксировать в синтетическом тесте, где никто не щелкает мышкой. Показатель Total Blocking Time приблизительно отражает ту же основную проблему, измеряя, какую часть времени загрузки браузер не смог бы отреагировать, и он достаточно хорошо коррелирует с результатами, чтобы быть полезным для диагностики.
Порог в пятьдесят миллисекунд отражает человеческое восприятие, а не произвольный выбор. Задачи меньшей продолжительности позволяют браузеру достаточно быстро реагировать на ввод, так что интерфейс кажется мгновенным, в то время как более длительные задачи вызывают ощутимую задержку. Если учитывать только превышение порога, то одна задача длительностью в пятьсот миллисекунд вносит гораздо больший вклад, чем десять задач по шестьдесят, что правильно отражает тот факт, что один длинный блок хуже, чем несколько коротких.
Причины почти полностью связаны с выполнением JavaScript. Большие пакеты данных, которые необходимо проанализировать и скомпилировать, инициализация и заполнение фреймворка на страницах, отображаемых на сервере, сторонние скрипты, выполняющиеся во время загрузки, и ресурсоемкие вычисления, выполняемые синхронно, — все это занимает основной поток. Улучшения сети не решают эту проблему: скрипт, который загружается мгновенно, все равно блокирует поток во время своего выполнения.
Исправление ошибок начинается с определения того, какие задачи являются длительными и что они содержат. Стандартные подходы включают разделение пакетов таким образом, чтобы немедленно загружался только код, необходимый для первоначального отображения, откладывание загрузки некритичных скриптов, разбиение длительных задач на более мелкие части, уступающие место браузеру между ними, перенос ресурсоемких вычислений в рабочий поток и удаление сторонних скриптов, затраты на которые не оправданы. Аудит сторонних скриптов по отдельности часто является наиболее эффективным этапом, поскольку один контейнер менеджера тегов может доминировать в оценке производительности.
Сопоставление этих данных с полевыми данными требует осторожности при интерпретации. Общее время блокировки — это лабораторное измерение в контролируемых условиях, в то время как взаимодействие с следующей отрисовкой собирается от реальных пользователей на реальных устройствах. Страница может показать приемлемое время блокировки на быстром тестовом устройстве и низкую скорость отклика в полевых условиях на телефонах среднего класса, которые фактически использует большая часть аудитории. Тестирование в условиях ограничения скорости, приближенных к реальному распределению устройств, делает лабораторные данные прогностическими.
Кроме того, измерение охватывает только период загрузки, что является существенным ограничением. Проблемы с отзывчивостью, возникающие позже, когда пользователь фильтрует большой список или открывает сложное представление, незаметны для измерения, которое прекращается после завершения загрузки. Приложениям со значительной интерактивностью после загрузки необходимы полевые измерения реальных взаимодействий, а не полагаться на прокси-данные, полученные во время загрузки.
Поскольку предлагаемые решения касаются кода приложения и зависимостей от сторонних разработчиков, а не предоставления ресурсов, улучшение требует скорее инженерных разработок, чем настройки. На практике диагностика находится внутри системы. веб-производительность Изменения в работе пакета и выполнении передаются через разработка продуктаи решения о том, какие сторонние скрипты оправдывают свои затраты на основной поток, обычно требуют участия маркетинговые услуги, поскольку большинство подобных сценариев доступны по их просьбе.