Как длительные задачи JavaScript повышают время Time to Interactive
Как обнаружить ресурсоемкие задачи, которые блокируют реакцию на действия пользователя
Резюме. Длительные задачи могут занимать основной поток, задерживая взаимодействие с пользователем. Инструменты Chrome DevTools теперь могут визуализировать длительные задачи, что упрощает поиск целей для оптимизации.
Если вы используете Lighthouse для аудита страниц, возможно, вы уже знакомы с метрикой Время загрузки для взаимодействия (Time to Interactive, TTI), которая показывает, как скоро пользователи могут начинать взаимодействовать со страницей и получать реакцию. Но знаете ли вы, что длительные задачи (JavaScript) могут серьезно ухудшить TTI?
Что такое длительные задачи? #
Длительной задачей называется код на JavaScript, который монополизирует основной поток на продолжительное время, вызывая «зависание» интерфейса.
Во время загрузки страницы длительные задачи могут занять основной поток и сделать страницу невосприимчивой к действиям пользователя, даже если она выглядит готовой к работе: элементы страницы не реагируют на нажатия, потому что прослушиватели событий, обработчики нажатий и т. д. еще не подключены.
Ресурсоемкие длительные задачи — результат сложных действий, занимающих более 50 мс. Почему именно 50 мс? Модель RAIL рекомендует обрабатывать ввод данных пользователем в течение 50 мс, чтобы обеспечить скорость визуальной реакции в рамках 100 мс. Если нарушить это правило, связь между действием и реакцией будет разорвана.
Как понять, есть ли на странице длительные задачи, замедляющие реакцию #
До сих пор, чтобы выяснить, какие задачи задерживают реакцию на действия пользователя, приходилось вручную искать в Chrome DevTools «длинные желтые блоки» скриптов длительностью более 50 мс или использовать Long Tasks API, что не очень удобно.
Теперь DevTools визуализирует длительные задачи, что упрощает аудит производительности. Если задача (показаны серым цветом) является длительной, она получает красный флажок.
- На панели «Производительность» (Performance) запишите трассировку для загрузки веб-страницы.
- Поищите красные флажки в области основного потока. Задачи показаны серым и помечены как «Задача» (Task).
- Наведя указатель мыши на полосу, вы увидите, сколько выполнялась задача и считается ли она «длительной».
Как определить источник длительных задач #
Чтобы узнать источник длительной задачи, выберите серую полоску Задача (Task). В выдвигающейся панели внизу выберите Снизу вверх (Bottom-Up) и вариант Группировка по действию (Group by Activity). Вы увидите, какие действия внесли больший (в целом) вклад во время выполнения задачи. В примере ниже это ресурсоемкий набор DOM-запросов.
Стандартные способы оптимизации длительных задач #
Часто основной источник длительных задач — большие скрипты. Попробуйте их разделить. Также следите за сторонними скриптами: их длительные задачи могут задерживать переход основного контента в интерактивное состояние.
Разбивайте всё на небольшие фрагменты (которые выполняются быстрее 50 мс) и выполняйте их в нужном месте и в нужное время — пусть даже вне основного потока, в воркере. Хороший материал по этой теме — Ждать, пока не понадобится (Idle Until Urgent) Фила Уолтона.
Веб-страницы должны быстро откликаться на действия пользователя. Сведите к минимуму длительные задачи, и пользоваться вашим сайтом станет намного приятнее. Подробнее о длительных задачах см. в статье Метрики производительности, ориентированные на пользователя.