Флейм-стрип DevTools и жизненный цикл кадра

Вы открываете DevTools Performance, записываете скролл и видите море цветных полос. Некоторые красные. Большинство жёлтые. Вы знаете, что jank где-то там — но не понимаете, какую полосу чинить. Флейм-стрип — это карта. Этот урок учит её читать.

Чтение флейм-стрипа Performance в DevTools

Откройте DevTools → Performance, нажмите запись, воспроизведите jank, остановите.

Цвета дорожек (главный поток):

• Жёлтый — scripting (исполнение JavaScript)
• Фиолетовый — rendering (пересчёт стилей + компоновка)
• Зелёный — paint
• Тёмно-синий — compositing

Цвета дорожек (кадры):

• Зелёный — кадр вовремя
• Жёлтый — опоздавший кадр
• Красный — пропущенный кадр

Флейм-стрип укладывает вызовы сверху вниз: верхняя полоса — то, что вызвал JS; каждая ниже — то, что вызвала она. Найдите длинную красную или жёлтую полосу — это ваше бутылочное горлышко. Наведите для точного значения в мс.

Жизненный цикл кадра: точный порядок

Внутри одного кадра браузер выполняет работу в строгом порядке, заданном HTML-спецификацией:

1. Сбор input-событий (mousemove, keypress)
2. Запуск setTimeout / setInterval-колбэков, если их время пришло
3. Запуск микрозадач (promise-резолюции) до опустошения очереди
4. Запуск requestAnimationFrame-колбэков
5. Запуск ResizeObserver и IntersectionObserver-колбэков
6. Пересчёт стилей и компоновка
7. Отрисовка
8. Композитинг

После шага 8 браузер отдаёт управление ОС и ждёт следующего vsync.

Ключевое свойство: rAF запускается до стилей/компоновки, поэтому запись внутри rAF приводит ровно к одному проходу компоновки на кадр — в этом весь смысл rAF. ResizeObserver срабатывает после компоновки, но до отрисовки: можно реагировать на изменения компоновки без форсированной повторной компоновки. IntersectionObserver срабатывает асинхронно между кадрами, не блокируя текущий.

Микрозадачи vs задачи: границы планирования

Очередь микрозадач (промисы, queueMicrotask) опустошается полностью между каждым шагом event loop, в том числе между rAF-колбэками.

Некорректная promise-цепочка, планирующая себя бесконечно, голодит рендеринг — браузер не может добраться до шага 6, пока очередь не опустеет. Именно поэтому длинные promise-цепочки и тесные await-циклы отображаются в DevTools как единая непрерывная жёлтая scripting-полоса, а не серия коротких.

Современный код, желающий уступить рендереру в середине задачи, использует:

• scheduler.yield() (Scheduler API, Chrome 115+) — создан именно для этого
• setTimeout(fn, 0) — помещает работу в очередь макрозадач и разблокирует рендеринг

Реактивные фреймворки и пайплайн

Когда React рендерит, DOM-обновления происходят на главном потоке, затем пайплайн запускает пересчёт стилей и компоновку на изменённых узлах. Сама реконсиляция — чистый JS, она отображается жёлтым в DevTools. Если ре-рендер затрагивает узел у вершины дерева, инвалидация стилей каскадирует вниз; затрагивает изолированный лист — инвалидация локальна.

Ключевая практика: держите состояние локальным, как можно ближе к листу. useState в листовом компоненте инвалидирует один узел; useContext в провайдере верхнего уровня может инвалидировать сотни. Тот же принцип работает для Svelte-stores, MobX-observables, Vue refs — каждая реактивная модель в итоге пишет в DOM, а DOM-запись запускает тот же пайплайн.