Браузер и фронтенд-рантайм
Event loop: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту — семантика очередей, шаг рендеринга, requestAnimationFrame, starvation, scheduler.yield и Node event loop.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение из реального инцидента производительности — не определение для заучивания, а в какую очередь попадает примитив и чего это стоит следующему кадру.
Цель
Убедись, что связываешь семантику очередей, шаг рендеринга, троттлинг таймеров, starvation и различия рантаймов — тот синтез, к которому вели отдельные уроки.
Викторина
Completed
Внутри click-обработчика ты вызываешь setTimeout(t, 0), затем queueMicrotask(m), затем обработчик возвращается. В каком порядке выполнятся t и m относительно следующего paint?
Heads-up setTimeout(0) ставит task; microtask checkpoint опустошается до того, как loop возьмёт следующий task. queueMicrotask всегда выполняется раньше любого setTimeout-колбэка, поставленного в том же витке.
Heads-up Тайминг задаёт очередь, а не порядок регистрации. m — microtask (до рендера, немедленно); t — task (после рендера, после checkpoint и, возможно, кадра).
Heads-up Microtask drain происходит до шага рендеринга, а не после. m выполнится до любого paint; только t ждёт более поздней итерации.
Викторина
Completed
Click-обработчик выполняется 400 мс. Что из этого продолжает работать во время блокировки и почему?
Heads-up Microtask тоже нужен main thread. Он стоит в очереди за выполняющимся task и не может запуститься, пока 400-мс обработчик не вернётся.
Heads-up Таймер лишь ставит task; колбэку всё равно нужен заблокированный main thread. Накопившиеся interval-колбэки прорываются пачкой, когда поток освобождается.
Heads-up Поток ввода фиксирует событие, но обработчик идёт на main thread. Клик встаёт в очередь и ждёт — пользователь видит замороженный UI.
Викторина
Completed
Тебе нужно сделать 200 мс работы, не заморозив ввод. Ты пробуешь await Promise.resolve() между чанками, и страница всё равно зависает. Почему и что реально уступает поток?
Heads-up Стоимость аллокации тут пренебрежима. Заморозка структурная: microtask drain происходит до шага рендеринга, поэтому yield к вводу не случается никогда.
Heads-up Он всё равно приостанавливает функцию и возобновляет её через microtask-очередь — но microtask по определению выполняется до любого кадра, поэтому рендереру он не уступает.
Heads-up rAF выполняется только на границе кадра, поэтому как общий yield он плох. И setTimeout(0), и scheduler.yield() ставят task, позволяя вводу и рендерингу чередоваться.
Викторина
Completed
Фоновая вкладка крутит setInterval(poll, 1000). Спустя несколько минут в фоне, как часто срабатывает колбэк и что с этим складывается?
Heads-up setInterval троттлится ровно как setTimeout в скрытых вкладках. Минимум в 1 с применяется сразу, минимум в 1 мин — после более долгого периода в фоне.
Heads-up Клампинг вложенности в 4 мс применяется к глубоким цепочкам setTimeout/setInterval; в скрытой вкладке выигрывает гораздо больший фоновый троттлинг.
Heads-up Таймеры срабатывают по троттленной частоте, а не нулевой. Полная приостановка случается только если Page Lifecycle API заморозит вкладку — более сильный и поздний сигнал.
Викторина
Completed
Поисковый инпут показывает INP 410 мс. Long Tasks API логирует task на 312 мс, но атрибутирует его лишь как 'same-origin'. Какой следующий инструмент верный и почему?
Heads-up buffered:true лишь добирает записи, появившиеся до подключения observer; атрибуции на уровне скрипта он не добавляет. Атрибуция Long Tasks остаётся на гранулярности browsing-context.
Heads-up Локальное воспроизведение часто промахивается мимо production-размера payload и класса устройства. LoAF плюс разрешение sourcemap — верный путь production-атрибуции.
Heads-up User Timing требует заранее знать, куда ставить метки. LoAF авто-атрибутирует самый тяжёлый скрипт на медленный кадр без ручной инструментации.
Викторина
Completed
Библиотека, протестированная только в Node, цепляет process.nextTick(a), затем Promise.resolve().then(b) и полагается, что a выполнится до b. Перенесённая в браузер через polyfill для nextTick, она переворачивает порядок. Почему?
Heads-up Все microtask выполняются на main thread. Переворот — про приоритет очереди: nextTick в Node выше microtask; полифилленная версия — нет.
Heads-up process.nextTick специфичен для Node и в ECMA-262 отсутствует. Спека определяет лишь microtask-очередь (jobs), поэтому polyfill схлопывается до queueMicrotask.
Heads-up Корректный polyfill использует queueMicrotask, а не setTimeout — но в любом случае суть та же: пред-microtask-приоритета nextTick в браузере не существует.
Итог
Сквозная линия юнита — одно решение: в какую очередь попадает этот примитив и чего это стоит следующему кадру. Microtask (колбэки промисов, queueMicrotask, MutationObserver) дренируются до рендеринга и starve его при самопланировании; task (setTimeout, MessageChannel, диспетчеризация ввода) уступают рендерингу, но платят клампами и троттлингом; rAF выполняется только на границе кадра. Диагностируй воспринимаемую задержку через INP, атрибутируй её через LoAF плюс sourcemap и помни, что Node переупорядочивает всё это, ставя process.nextTick выше microtask.