Представляем Scheduler.yield(): новейший API Chrome для оптимизации INP
Опубликовано: 2023-09-15Нет никаких сомнений в том, что в 2023 году Google уделяет особое внимание оперативности реагирования.
На данный момент они:
- Взаимодействие в «Следующей отрисовке» перенесено из экспериментального в ожидающий вариант;
- Объявлено, что INP заменит первую задержку ввода в качестве новой метрики Core Web Vital для оперативности реагирования в марте 2024 года;
- Начали отмечать проблемы INP в Search Console и отправлять электронные письма на веб-сайты, которые не соответствуют порогу хорошей реакции.
Теперь команда Chrome объявила, что в настоящее время они проводят пробную версию нового API планировщика — Scheduler.yield() .
Ожидается, что Scheduler.yield() поможет разработчикам улучшить отзывчивость своих сайтов, предоставив им более простой и лучший способ вернуть управление основному потоку.
Читайте дальше, чтобы узнать больше о новом API и о том, как опробовать его на своем веб-сайте.
Краткий обзор длинных задач и основного потока
Если вы хорошо понимаете, что такое длинные задачи и основной поток, смело пропустите эту часть. Если нет, мы рекомендуем вам прочитать этот краткий обзор, поскольку он имеет фундаментальное значение для понимания метода Scheduler.yield() и того, как его реализовать.
Все, что браузер делает как работу, считается задачей. Сюда входит рендеринг, анализ HTML и CSS, запуск написанного вами кода JavaScript и другие вещи, над которыми вы не можете иметь прямого контроля.
В основном потоке браузер выполняет большую часть работы.
К сожалению, основной поток можетобрабатывать только одну задачу одновременно .А если выполнение задачи занимает более 50 мс, она считается длинной задачей.
Встреча с длинной задачей означает, что браузер будет запускать ее столько, сколько необходимо для ее завершения. После завершения управление возвращается основному потоку, позволяя браузеру обработать следующую задачу в очереди.
Длинные задачи являются основным источником плохой реакции страницы, поскольку они задерживают способность браузера реагировать на ввод пользователя. Более того, JavaScript с его моделью выполнения до завершения является основным виновником блокировки основного потока.
Вот почему он считается ресурсом, блокирующим рендеринг: когда браузер встречает его, он должен загрузить, проанализировать и выполнить его, прежде чем делать что-либо еще.
Хорошая новость заключается в том, что тот факт, что ваш код запускает задачу в браузере, не означает, что вам нужно ждать завершения этой задачи, прежде чем управление будет возвращено основному потоку.
Вы можете разбить длинные задачи, явно уступив задачу.
Проще говоря, передача задач гарантирует, что браузер не будет настолько увлечен одной задачей, что пропустит или задержит реакцию на другие важные задачи или взаимодействия с пользователем.
К сожалению, нынешние стратегии доходности не идеальны…
Почему Scheduler.yield(): Проблема со стратегиями текущей доходности
Уступка основному потоку — не новая концепция. Разработчики уже довольно давно используют различные стратегии доходности для разделения длинных задач:
1. УстановитьТаймаут()
setTimeout() позволяет вам запланировать запуск задачи после указанной задержки или через регулярные промежутки времени. Это переносит выполнение обратного вызова в отдельную задачу, даже если вы укажете тайм-аут, равный 0. Этот метод эффективен, когда у вас есть несколько функций, которые должны выполняться одна за другой.
Недостаток: точность не гарантируется. Обратный вызов может не выполниться точно после указанной задержки из-за других задач в очереди. Кроме того, если вы обрабатываете огромный набор данных в цикле, задача может занять много времени, особенно с миллионами записей.
2. запросIdleCallback()
requestIdleCallback() позволяет вам запланировать запуск задачи во время любых периодов простоя браузера. Это полезно для выполнения несрочных задач, не влияя на удобство работы пользователя.
Недостаток: requestIdleCallback() планирует задачи с самым низким приоритетом, а это означает, что если основной поток перегружен, запланированные задачи могут никогда не запуститься.
3. isInputPending()
isInputPending() может быть выполнен в любое время, чтобы проверить, пытается ли пользователь взаимодействовать с элементом на странице. Если да, функция возвращаетtrue; если нет, он возвращаетfalse.
Представьте, что у вас есть ряд задач, которые нужно выполнить, но вы не хотите мешать взаимодействию с пользователем. Вы можете использовать isInputPending() и функцию yieldToMain() , чтобы гарантировать, что ввод пользователя не задерживается при взаимодействии со страницей.
Недостаток: isInputPending() не всегда может возвращать значение true сразу после ввода пользователем. Это связано с тем, что операционной системе требуется время, чтобы сообщить браузеру о том, что взаимодействие произошло. Это означает, что другой код, возможно, уже начал выполняться.
Это некоторые из популярных способов вернуться в основной поток. Как видите, у каждого есть свои недостатки.
Но самым существенным недостатком является то, что:
Когда вы переходите к основному потоку, откладывая выполнение кода в следующей задаче, этот код добавляется в самый конец очереди задач.
Почему это проблема?
Это тройной ответ:
- Повышенная вероятность логических ошибок: поскольку отложенный код размещается в конце очереди задач, браузер может выполнить другие задачи, прежде чем вернуться к отложенной задаче. Это может повлиять на порядок выполнения функций и потенциально вызвать логические ошибки или неожиданное поведение.
- Задержка выполнения . Если в очереди много задач, может пройти значительное время, прежде чем браузер достигнет и выполнит отложенный код.
- Непредсказуемость. Трудно точно предсказать, когда будет запущена отложенная задача, поскольку это зависит от количества и характера задач, уже находящихся в очереди. Эта непредсказуемость может затруднить отладку и оптимизацию производительности.
Подводя итог, можно сказать, что хотя использование текущих стратегий перехода к основному потоку может помочь сохранить отзывчивый пользовательский интерфейс, оно также может создать проблемы с обеспечением своевременного и упорядоченного выполнения кода.
Представляем Scheduler.yield()
Волнение по поводу того, что Chrome запускает пробную версию для Scheduler.yield(), связано с тем, что это API планировщика, который устраняет все недостатки других стратегий доходности.
Кроме того, это решение, которое позволит как разработчикам, так и владельцам получать адаптивные веб-сайты и хорошие оценки INP, одновременно беспрепятственно выполняя остальную часть кода.
Так что же за шумиха вокруг Scheduler.yield() ?
Начнем с того, что Scheduler.yield() — это специальная функция доходности. setTimeout(), например, используется для разбивки длинных задач и перехода к основному потоку, но это скорее побочный эффект функции, чем опция по умолчанию.
Во-вторых, Scheduler.yield() отправляет оставшуюся работу в начало очереди. Это означает, что работа, которую вы хотите возобновить сразу после завершения, не отойдет на второй план по сравнению с задачами из других источников.
Проще говоря:
Scheduler.yield() дает вам лучшее из обоих миров — вы можете дать, чтобы улучшить скорость реагирования вашего сайта и показатель INP, а также гарантировать, что работа, которую вы хотели завершить после передачи, не задерживается.
Как попробовать новый API планировщика
Начиная с Chrome 115, вы можете протестировать Scheduler.yield самостоятельно.
Чтобы поэкспериментировать с новым API, просто следуйте инструкциям Google:
- Если вы хотите поэкспериментировать с Scheduler.yield локально, введите и введите chrome://flags в адресной строке Chrome и выберите «Включить» в раскрывающемся списке в разделе «Экспериментальные функции веб-платформы». Это сделает Scheduler.yield (и любые другие экспериментальные функции) доступными только в вашем экземпляре Chrome.
- Если вы хотите включить Scheduler.yield для реальных пользователей Chromium в общедоступном источнике, вам необходимо подписаться на пробную версию Scheduler.yield Origin. Это позволяет вам безопасно экспериментировать с предлагаемыми функциями в течение определенного периода времени и дает команде Chrome ценную информацию о том, как эти функции используются в полевых условиях. Дополнительную информацию о том, как работают пробные версии происхождения, можно найти в этом руководстве.
После тестирования вы также можете оставить отзыв о том, как его можно улучшить.
Безопасное тестирование!
Как NitroPack может помочь разблокировать основной поток
Разбиение длинных задач на более мелкие части имеет важное значение для предоставления пользователям быстрого опыта.
Но не лучше ли было бы заранее оптимизировать часть тяжелого JavaScript?
Вот тут-то и приходит на помощь NitroPack.
Благодаря более чем 35 расширенным функциям повышения производительности в Интернете NitroPack помогает более чем 180 000 веб-сайтам по всему миру добиться превосходного пользовательского опыта, основных веб-показателей и показателей конверсии.
Одним из наиболее значительных преимуществ NitroPack является способ управления выполнением JavaScript.
После установки NitroPack наш сервис задерживает загрузку некритических ресурсов до тех пор, пока не будет обнаружено взаимодействие с пользователем.
Более того, благодаря нашему собственному механизму загрузки ресурсов , NitroPack может изменить способ подачи ресурсов в основной поток. Мы делаем это, чтобы воспользоваться преимуществами многоядерности современного процессора, выгружая задачи из основного потока.
Таким образом, мы можем гарантировать, что ваш основной поток останется разблокированным и доступен для взаимодействия с пользователем.