Загальний час блокування

Загальний час блокування вимірює сукупну тривалість, протягом якої головний потік браузера був заблокований довгими завданнями під час завантаження сторінки, що перешкоджало його реагуванню на введення користувача. Він підсумовує частину кожного завдання, що перевищує п'ятдесят мілісекунд, враховуючи лише перевищення, і вимірюється в лабораторних умовах між першим відображенням контенту та точкою, коли сторінка стає надійно інтерактивною.

Його мета — служити лабораторним показником швидкості реагування, яку важко виміряти без реальної взаємодії з користувачем. Оскільки взаємодія з наступним малюванням вимагає фактичного введення користувача, її неможливо зафіксувати в синтетичному тесті, де ніхто не натискає. Загальний час блокування наближається до тієї ж основної проблеми, вимірюючи, яку частину періоду завантаження браузер не зміг би відповісти, і він достатньо добре корелює, щоб бути корисним для діагностики.

Поріг у п'ятдесят мілісекунд відображає людське сприйняття, а не довільний вибір. Завдання, що тривають менше цього часу, дозволяють браузеру реагувати на ввід досить швидко, щоб інтерфейс відчувався миттєвим, тоді як довші завдання створюють помітну затримку. Враховуючи лише перевищення порогу, означає, що одне завдання тривалістю п'ятсот мілісекунд вносить набагато більше, ніж десять завдань тривалістю шістдесят, що правильно відображає те, що один довгий блок гірший за кілька коротких.

Причини майже повністю пов'язані з виконанням JavaScript. Великі пакети, які необхідно розібрати та скомпілювати, ініціалізація та гідратація фреймворку на сторінках, що відображаються на сервері, сторонні скрипти, що виконуються під час завантаження, та дорогі обчислення, що виконуються синхронно, – все це займає головний потік. Покращення мережі не вирішують цю проблему: скрипт, який завантажується миттєво, все одно блокує потік під час його виконання.

Виправлення полягає в визначенні того, які завдання є довгими та що вони містять. Стандартними підходами є розділення пакетів, щоб одразу завантажувався лише код, необхідний для початкового перегляду, відкладення некритичних скриптів, розбиття довгих завдань на менші частини, які поступаються місцем браузеру між ними, перенесення важких обчислень у робочий потік та видалення сторонніх скриптів, які не виправдовують свою вартість. Аудит сторонніх розробників окремо часто є кроком з найвищою віддачею, оскільки один контейнер менеджера тегів може домінувати у вимірюванні.

Його зв'язок з польовими даними вимагає обережної інтерпретації. Загальний час блокування – це лабораторне вимірювання в контрольованих умовах, тоді як дані про взаємодію з наступним малюванням збираються від реальних користувачів на реальних пристроях. Сторінка може зафіксувати прийнятний час блокування на швидкій тестовій машині та погану польову реакцію на телефонах середнього класу, якими фактично користується більша частина аудиторії. Тестування в умовах обмеженого доступу, що наближаються до розподілу реальних пристроїв, робить лабораторний показник прогностичним.

Він також охоплює лише період завантаження, що є справжнім обмеженням. Проблеми з реагуванням, що виникають пізніше, коли користувач фільтрує великий список або відкриває складне представлення, невидимі для вимірювання, яке зупиняється після завершення завантаження. Програми зі значною інтерактивністю після завантаження потребують польових вимірювань реальних взаємодій, а не покладаються на показник часу завантаження.

Оскільки засоби вирішення проблеми стосуються коду програми та залежностей від третіх сторін, а не доставки ресурсів, покращення вимагає інженерії, а не конфігурації. На практиці діагноз ставиться в межах веб-продуктивність робота, зміни пакету та виконання здійснюється через розробка продукту, а рішення щодо того, які сторонні скрипти виправдовують свою вартість в основному потоку, зазвичай повинні включати маркетингові послуги, оскільки більшість таких скриптів доступні за їхнім запитом.