Компоновщик и бюджет кадра: какие свойства бесплатны

Пять стадий, три выхода

Каждое визуальное изменение проходит некоторый префикс одного конвейера, раз на выходной кадр: JS (обработчики событий, колбэки rAF, render и commit React) → style (пересчитать, какие правила применяются и каковы вычисленные значения) → layout (геометрия: где стоит каждый бокс и какого он размера — одно изменение width каскадирует по соседям, предкам и строкам текста) → paint (растеризовать боксы в битмапы слоёв: текст, цвета, тени, рамки) → composite (расставить уже растеризованные слои друг относительно друга и показать кадр).

Дорогая правда: свойства различаются не «тяжестью», а тем, где они входят в конвейер. Измените width, top, margin, font-size — вы пачкаете layout, и всё ниже перезапускается: layout, paint, composite, на каждом кадре вашей анимации. Измените color, background, box-shadow — layout выживает, но элемент перерисовывается. Измените transform или opacity у элемента с собственным композитным слоем — не пересчитывается ничего, кроме итогового размещения готового битмапа: ни layout, ни paint. Компоновщик сдвигает текстуру. Вот вся причина, по которой «анимируй transform и opacity» — правило, а не вкусовщина: это два повсеместно анимируемых свойства, чьи обновления могут целиком миновать главный поток (плюс filter в современных движках, с оговорками).

Поток компоновщика — ваш единственный союзник вне главного потока

Composite — не просто последняя стадия: она живёт на другом потоке. Поток компоновщика держит растеризованные слои и может заново расставлять их на экране, не обращаясь к главному потоку. Декларативные анимации — CSS-переходы, CSS-анимации и вызовы Web Animations API — на transform и opacity передаются ему: после передачи главный поток может блокироваться на сотни миллисекунд в reconcile или GC, а анимация не уронит ни кадра, потому что производство её кадров целиком происходит вне главного потока. Это и есть финал Hook: панель на CSS-переходе проплыла сквозь 70-миллисекундный reconcile, который раньше съедал четыре кадра целиком.

Обратная сторона: любая анимация, которую JavaScript ведёт по кадрам — цикл rAF, spring-библиотека, мутирующая стили, состояние React, — по построению живёт в главном потоке. Она всё ещё может выдавать 60 fps, но за каждый кадр конкурирует со всем остальным на этом потоке и по умолчанию проигрывает всякий раз, когда React коммитит что-то большое. И CSS-анимация layout-свойства — тоже работа главного потока: декларативная форма не спасает; спасает класс свойства.

Арифметика бюджета кадра

Числа здесь важны: пропущенный дедлайн — не медленный кадр, а выброшенный кадр. При 60 Гц кадр — 16,7 мс. При 120 Гц — всё чаще это умолчание на телефонах и ноутбуках, на которых вы не тестируете, — 8,3 мс. Бюджет не весь ваш: часть каждого кадра браузер тратит на обработку ввода, пересчёт стилей, layout, paint и передачу компоновщику. Остаток для вашего JS — примерно 10 мс при 60 Гц и 3–5 мс при 120 Гц. Числа, которые стоит носить с собой: пересчёт стилей на нескольких тысячах узлов — 1–4 мс; layout сложной страницы — 4–12 мс; средний React-коммит — 2–8 мс. Каждое — допустимо раз на взаимодействие. Ни одно — недопустимо на каждом кадре при 120 Гц. Промахнитесь мимо дедлайна — и кадр не опоздает, он будет выброшен: предыдущий кадр останется на экране лишние 16,7 (или 8,3) мс, а в непрерывном движении глаз надёжно читает один выброшенный кадр как рывок.

Специфический грех React: рендер на каждый кадр

// ❌ рендер на каждый кадр: rAF → setState → render → reconcile → commit, 60×/с
useEffect(() => {
  let raf;
  const tick = () => {
    setX((x) => x + dx);              // планирует полный React-рендер каждый кадр
    raf = requestAnimationFrame(tick);
  };
  raf = requestAnimationFrame(tick);
  return () => cancelAnimationFrame(raf);
}, []);

// ✅ React рендерит один раз; кадры мутируют ref — никакого reconcile в горячем цикле
useEffect(() => {
  let raf, x = 0;
  const tick = () => {
    x += dx;
    el.current.style.transform = `translateX(${x}px)`;
    raf = requestAnimationFrame(tick);
  };
  raf = requestAnimationFrame(tick);
  return () => cancelAnimationFrame(raf);
}, []);

Первый цикл платит за полную машинерию React на каждом кадре: отрендерить компонент, реконсилировать поддерево, закоммитить — а затем style, layout и paint, если записанное свойство их требует. Коммит в 3 мс — это треть бюджета в 8,3 мс до того, как браузер сделал хоть какую-то работу по отрисовке. Второй цикл стоит микросекунды JS и пачкает только то, что пачкает мутируемое свойство — с transform на продвинутом слое это ничего из того, что волнует главный поток.

Лестница, по убыванию предпочтения: сначала CSS-переходы и анимации (декларативны, годятся компоновщику, прерывание берёт на себя браузер); WAAPI el.animate(), когда нужны динамические значения или управляемый из JS тайминг (всё ещё годится компоновщику); rAF + мутация ref, когда значение действительно вычисляется по кадрам в JS — жесты, физика — главный поток, но без reconcile; setState на каждый кадр — никогда. Работа React — состояние на границах: запустить анимацию и один раз закоммитить финальное значение, когда она закончилась.

will-change, честно

will-change: transform просит браузер продвинуть элемент в собственный композитный слой заранее, чтобы первый кадр анимации не платил за продвижение (которое само может вызвать paint). Прежде чем добавить его, спроси себя: действительно ли нужна экономия на первом кадре, или ты добавляешь его по всему дереву на всякий случай? Цена — то, что обнаружило фольклорное лечение из Hook: слой — это битмап, примерно width × height × 4 байта × devicePixelRatio² — один полноэкранный слой при 2× DPR весит порядка 30 МБ, а четыреста продвинутых строк таблицы — четыреста растеризованных текстур, которые GPU обязан держать и компоновать каждый кадр. Больше слоёв — медленнее растеризация и длиннее кадры компоновщика, так что ковровое продвижение делает медленные машины ещё медленнее. Дисциплина: продвигайте точно вовремя — ставьте will-change по намерению нажатия или прямо перед анимацией и убирайте по её окончании, — и никогда в wildcard-правиле стилей. И помните: браузеры и так автоматически продвигают элементы с идущими анимациями transform или opacity — will-change покупает вам первый кадр, а не анимацию.

Чтение флеймов — и связь с INP

В панели Performance в DevTools запишите дёргающееся взаимодействие и читайте три вещи. Трек Frames: выброшенные и частично показанные кадры показывают, когда именно сломался бюджет. Флейм-чарт Main: фиолетовый блок Layout, повторяющийся каждые 16 мс во время вашей анимации, — подпись анимируемого layout-свойства; широкие зелёные блоки Paint — шторм перерисовок (непродвинутая анимация или тяжёлое для paint свойство вроде box-shadow); длинные жёлтые JS-задачи с красными треугольниками — ваша покадровая работа React. Вкладка Rendering с paint flashing и layer borders вживую отвечает «что перерисовывается» и «что продвинулось», пока вы воспроизводите проблему.

Связь с INP делает это больше, чем косметикой: работа анимации и обработка ввода делят главный поток. Событие указателя, пришедшее, пока выполняется ваш 24-миллисекундный кадр анимации, ждёт его; задержка взаимодействия за 200 мс — и INP оценивается как «плохо»: дёргающаяся анимация теперь регрессия Core Web Vitals. Анимация, ведомая компоновщиком, освобождена по построению: она не может блокировать ввод на потоке, который никогда не делит.