От любого аспекта, который снижает скорость загрузки сайта, необходимо устранить в обязательном порядке. Каким бы не значительным на первый взгляд он не казался. Даже миллисекунды способны влиять на восприятие пользователя и являться причиной негативного пользовательского опыта. Он, в свою очередь, формирует отношение посетителя к странице, отражается на выгодах, в первую очередь — финансовых.
Что делаете вы, когда переходите на сайт и он, по вашему мнению, долго загружается. Уходите с него и идёте на другую, более быструю страницу. Пользователи вашего сайта поступают точно также. Поэтому, чем быстрее вы дадите им возможность эффективно взаимодействовать с ресурсом, тем больше выгод это принесёт в результате.
Многие думают, что могут самостоятельно провести все необходимые настройки. Но, оптимизация сайта веб-разработчиками потому и выполняется, что любые действия человеком, который не досконально разбирается в JavaScript, построении DOM, CSS и другой внутренней начинке, в лучшем случае не принесут результата. В худшем — придётся проводить «реанимационные мероприятия» и буквально переделывать всё заново. Профессиональная настройка сайта позволяет сделать его действительно быстрым и функциональным.
Одним из показателей, которые можно отследить в аудите Lighthouse — Общее время блокировки. В отчёте он располагается в разделе «Производительность». И каждый из показателей отображает отдельный аспект скорости загрузки страницы. Главное — не получить результаты с помощью проведения тестирования. Первоочередная задача — провести анализ, выявить закономерности и на их основании провести оптимизацию сайта по всем параметрам.
Что такое общее время блокировки
Общее время блокировки (TBT) — это метрика, основанная на времени, которая описывает активность основного потока JavaScript. Эти данные необходимы для понимания того, как долго страница не может ответить на ввод пользователя. ТВТ является более показательным нежели Time to Interactive на который могут оказывать влияние различные процессы в JavaScript.
Другими словами, показатель общего времени блокировки измеряет общее количество времени между первой содержательной краской (FCP) и временем до интерактивности (TTI). В данный период основной поток блокируется, предотвращая реакцию ввода и не реагирует на действия пользователя, такие как щелчки мыши, нажатия на экран или нажатия клавиш клавиатуры.
Вполне логично, что чем дольше пользователь не имеет возможности осуществлять взаимодействие со страницей, тем меньше ему это нравится. Необходимо определить факторы, которые кроются внутри скриптов и кодов, оказывая негативное воздействие. Но прежде чем их исправить, требуется точно знать с чем именно придётся работать.
Как рассчитывается общее время блокировки
Общее время блокировки рассчитывается путём сложения всех блокирующих частей длинных задач, которые находятся в интервалемежду First Contentful Paint и Time to Interactive. Если на выполнение задачи требуется более 50 миллисекунд, то она будет длинной. И не стоит обращать внимание на тот факт, что зачастую рекомендованным временем называют 100 миллисекунд. Это не совсем достоверная информация, так как 100 миллисекунд включают в себя общее время. Которое требуется браузеру для выполнения полностью всех работ.
Время, которое начинается после вожделенных 50 миллисекунд и является частью блокировки. К примеру, если Lighthouse обнаруживает задачу длительностью 70 миллисекунд, то её блокирующая часть будет составлять 20 миллисекунд.
Если говорить простыми словами, то заблокированным основной поток называется потому, что браузер не может прервать текущую задачу, которая ему уже была поставлен и переключиться на другую. Когда пользователь взаимодействует со страницей и хочет, чтобы она выполнила иное действие в середине длинной задачи (к примеру, переход к товару или услуге), то браузер должен дождаться завершения текущей задачи. И только после этого он сможет ответить. Если задание достаточно длинное, превышающее 50 миллисекунд, то в большинстве случаев пользователь заметит задержку и воспримет страницу как подвисающую или дерганную.
Рассмотрим на примере. Предположим, что в процессе загрузки данных, основной поток должен выполнить 5 задач. На работу с каждой из них, браузеру требуется своё время.
• Задача 1 — 250 миллисекунд
• Задача 2 — 90 миллисекунд
• Задача 3 — 35 миллисекунд
• Задача 4 — 30 миллисекунд
• Задача 5 — 155 миллисекунд
Таким образом, мы получаем общее время работы затраченное в основном потоке, равное 560 миллисекунд. Но общим временем блокировки будут являться 345 миллисекунд — превышение лимита в первой, второй и пятой задачах.
Почему ТВТ эффективнее ТТI
Говорить о том, что Total Blocking Time эффективнее Time to Interactive — не совсем корректно. TBT является отличным сопутствующим показателем для TTI, поскольку помогает количественно оценить степень неинтерактивности страницы до того момента, когда она станет надежно интерактивной.
TTI считает страницу «надежно интерактивной», если в основном потоке не было долгих задач в течении минимум 5 секунд кряду. Это означает, что три задачи продолжительностью 51 мс, распределенные в течение 10 секунд, TTI может пропустить. Или наоборот, посчитать превышением 10секундную задачу в рамках различных сценариев. При этом, для пользователя это будет иметь существенную разницу в восприятии.
Как улучшить показатель TBT
Чтобы сократить показатель ТВТ, необходимо провести детальный анализ всех компонентов и выявить, где кроются длинные задачи, которые превышают рекомендованные 50 миллисекунд. Среди наиболее частых причин следующие:
• Ненужная загрузка, анализ или выполнение JavaScript. Это происходит когда основной поток выполняет работу, которая на самом деле не нужна для загрузки страницы. Сокращение полезной нагрузки JavaScript с помощью разделения кода, удаления неиспользуемого кода или эффективной загрузки стороннего JavaScript должно улучшить ваш показатель TBT.
• Неэффективные операторы JavaScript. Например, после анализа вашего кода можете увидеть вызов document.querySelectorAll(‘a’), который возвращает 2000 узлов. В данном случае требуется провести рефакторинг кода для использования более конкретного селектора, который возвращает только 10 узлов и это также улучшит показатель TBT.
Приведённые примеры — наиболее часто встречающиеся ошибки, но далеко не все. В процессе оптимизации сайта, наша команда зачастую встречает ошибки там, где их не может быть по определению. Зачастую это связанно с тем, что для наполнения сайта он отдаётся удалённым маркетологам, копирайтерам или специалистам по продвижению, веб-разработчикам, которые не особо разбираясь в структуре, случайно влезают в коды. Поэтому, если уж вы передаёте «ключи» от сайта — убедитесь в квалификации компании или человека. Ключи от квартиры вы же не отдадите первому встречному.
