Голодание микрозадач, длинные задачи и LoAF

Пользователь сообщает, что страница «полностью зависла» на несколько секунд. DevTools Performance показывает один непрерывный жёлтый скриптовый прямоугольник. Ни один вызов функции не доминирует в flame chart — работа продолжает перепланировать себя как микрозадачи, и цикл никогда не вырывается.

Паттерн отказа: голодание микрозадач

Микрозадачи дренируются до пустой между задачами. Если микрозадача планирует ещё одну микрозадачу до возврата, цикл никогда не вырывается из microtask checkpoint — нет рендеринга, нет ввода, нет дальнейших задач. Патологический пример:

function loop() {
  Promise.resolve().then(loop);  // планирует себя как микрозадачу
}
loop();

Это вешает страницу бесконечно: очередь микрозадач никогда не пуста, шаг 4 (рендеринг) никогда не выполняется, пользователь видит замороженную вкладку. DevTools Performance показывает это как один непрерывный жёлтый скриптовый прямоугольник. Тот же паттерн встречается в продакшене как случайная рекурсия через async-цепочки: .then, который переподписывается на тот же observable, роутер-мидлвар, который ре-резолвится при каждом изменении, библиотека состояния, которая перезапускает реакции внутри реакции.

Обнаружение: записи длинных задач без явной доминирующей функции, скриптовый прямоугольник растёт без границ, INP > 1 с.

Лечение: вставить хотя бы одну уступку уровня задачи (setTimeout, MessageChannel, scheduler.postTask) в цепочку.

Long Tasks API и Long Animation Frames

PerformanceLongTaskTiming. Появился в 2017, вызывает запись PerformanceObserver для любой задачи, превышающей 50 мс на главном потоке. Каждая запись включает время начала, длительность и массив attribution с исходным контекстом просмотра. Ограничение: attribution редко указывает на конкретную функцию; он говорит «что-то внутри iframe A заняло 230 мс» — полезно для SLO-дашбордов, менее полезно для поиска корневой причины. Используйте Long Tasks API для подсчёта длинных задач за сессию, а не для их отладки.

PerformanceLongAnimationFrameTiming (LoAF). Появился в 2023–2024 в Chromium. Срабатывает для любого кадра, время рендеринга которого превышает 50 мс. Запись LoAF включает атрибуцию по скриптам: массив того, какие скрипты выполнялись в кадре, что они делали (event-handler, classic-script, module-script, user-callback), сколько каждый занял. Это именно тот продакшен-диагностический инструмент, которым Long Tasks должны были быть с самого начала. Совместно с INP: когда INP регрессирует, запрашивайте записи LoAF из той же сессии, находите виновный кадр, получайте атрибуцию скриптов, деплойте фикс. Полный конвейер: от воспринимаемой пользователем метрики (INP) до конкретного скрипта (LoAF) до конкретной функции (sourcemap по URL скрипта).

[Long Task] 312 мс
attribution: same-origin
startTime: 2456.3
duration: 312.4

[Long Task] 287 мс
attribution: same-origin
startTime: 5102.7
duration: 287.1

[INP candidate] 410 мс
type: pointerdown -> click -> next paint
startTime: 2401.0
processingStart: 2456.3
processingEnd: 2768.7
presentationTime: 2811.0
attribution: handleSearch (search.js:142)

scheduler.yield() и Scheduler API

Что делает scheduler.yield(). Scheduler API (Chrome 115+, частично в Edge, Firefox/Safari за флагом на конец 2025) даёт платформе первоклассный примитив уступки. await scheduler.yield() приостанавливает текущую задачу, дренирует очередь микрозадач, позволяет ввоту и рендерингу выполниться, и возобновляет приостановленную задачу как следующую задачу — с приоритетом, который предотвращает низкоприоритетную работу от вклинивания вперёд. Раньше уступка через setTimeout(0) работала для рендеринга, но теряла позицию в очереди (любая задача, запланированная тем временем, выполнялась первой). С scheduler.yield() можно разбить задачу 200 мс на четыре куска по 50 мс, которые с точки зрения пользователя остаются одной логической операцией.

scheduler.postTask() с приоритетами. Тот же API предоставляет scheduler.postTask(callback, { priority }) с тремя приоритетами: user-blocking (работа ответа на ввод), user-visible (по умолчанию), background (несрочная). Практический паттерн: направлять обработчики ввода через user-blocking, чтобы они прыгали в очереди вперёд фоновой работы вроде сброса аналитики; направлять фоновую аналитику через background, чтобы она уступала срочному. Планировщик имеет доступ к системным сигналам (батарея, тепловой троттлинг, видимость страницы), которых нет у JS-кода.