Profiler и измерения: найдите коммит на 600 мс прежде, чем трогать React.memo

Чтение флеймграфа: коммиты, а не компоненты

Профайлер React DevTools записывает сессию взаимодействий и нарезает её на коммиты — каждый раз, когда React реально донёс изменения до DOM, в таймлайне появляется один столбик. Выбрав коммит, вы видите флеймграф: каждая строка дерева — компонент, ширина его полосы — сколько он (вместе с детьми) рендерился в этом коммите, а серые полосы — компоненты, которые не рендерились вовсе. Эта рамка принципиальна: вопрос никогда не звучит «какой компонент медленный» вообще, он звучит «какой коммит медленный и что внутри него сожгло время». Один коммит на 600 мс с одной широкой полосой — совсем другая болезнь, чем шестьдесят коммитов по 10 мс от болтливой подписки, и лечатся они противоположно.

Две настройки превращают инструмент из картинки в диагноз. «Record why each component rendered» подписывает каждую полосу причиной: изменились пропсы (и какие именно), изменился стейт, сработал хук или просто отрендерился родитель. Одна эта подпись убивает большую часть гаданий — ремаунт графика из истории выше отобразился как «key changed», чего никакое разглядывание кода компонента не выявило бы. Вторая — галочка «Highlight updates», которая в реальном времени подсвечивает всё, что ре-рендерится: самый быстрый способ заметить провайдер контекста, перерисовывающий полстраницы на каждое нажатие клавиши. Профилируйте сначала в development ради богатых данных, но помните: dev-сборка React заметно медленнее — любое число, на котором строится решение, перепроверяйте на продакшен-сборке с профилированием (react-dom/profiling), её накладные расходы — единицы процентов.

Profiler API: числа, которые можно отправить в мониторинг

DevTools интерактивен; компонент <Profiler> программируем. Оберните поддерево — и React после каждого коммита внутри него вызовет onRender с таймингами, которые можно логировать, агрегировать или слать в систему мониторинга:

import { Profiler } from "react";

function onRender(id, phase, actualDuration, baseDuration, startTime, commitTime) {
  // actualDuration: сколько рендерился этот коммит (с учётом мемоизации)
  // baseDuration: оценка худшего случая — все потомки рендерятся, memo нет
  metrics.send("react-commit", {
    id,                       // "FilterPanel"
    phase,                    // "mount" | "update" | "nested-update"
    actual: actualDuration,   // напр. 4.2 (мс)
    base: baseDuration,       // напр. 38.7 (мс)
  });
}

<Profiler id="FilterPanel" onRender={onRender}>
  <FilterPanel />
</Profiler>

Пара, которую стоит усвоить, — actualDuration против baseDuration. actualDuration — реальная цена этого коммита; baseDuration — сумма последних времён рендера каждого потомка, то есть оценка худшего случая, где ничто не мемоизировано. Когда actualDuration сильно ниже baseDuration, мемоизация отрабатывает своё; когда числа идут вровень — обёртки React.memo стали декорацией. Именно этих доказательств команда из истории так и не собрала: их memo-кампания сдвинула actualDuration с 42 до 38 мс на коммите, который имел значение, — в пределах шума, потому что ремаунт на 620 мс обходил мемоизацию целиком. Компромисс: <Profiler> дёшев, но не бесплатен (React ведёт дополнительный учёт на каждый коммит внутри профилируемых деревьев), поэтому в продакшене оборачивайте две-три реально отслеживаемые интеракции, а не корень.

INP и миф о 16 мс

Число, которое цитируют все, — 16,7 мс, один кадр при 60 Гц — это бюджет непрерывного движения: анимации, скролла, перетаскивания. Промахнётесь во время драга — пользователь увидит рывок. Но клик — не анимация. Для дискретных взаимодействий пользовательская метрика — INP (Interaction to Next Paint): от нажатия до отрисовки следующего кадра, включая input delay (главный поток был занят, когда пришло событие), processing (ваши обработчики, рендер и коммит React) и presentation delay (стили, лейаут, отрисовка). Пороги: 200 мс — «хорошо», свыше 500 мс — «плохо», то есть примерно от 12 до 30 кадровых бюджетов, причём INP страницы — это примерно её худшее взаимодействие за визит, а не среднее.

Поэтому рамка «16 мс» сбивает оптимизацию в обе стороны. Она выставляет коммит в 30 мс по клику на кнопку нарушением, достойным рефакторинга, хотя пользователь не отличит 30 мс от мгновенного. И она молчит о настоящем убийце: любая задача в главном потоке дольше 50 мс — это long task, добавляющий input delay всему, что пользователь сделает следом; коммит на 620 мс не просто тормозит своё взаимодействие — он замораживает каждый клик, прилетевший во время него. Рабочий цикл, по порядку: прочитать INP из полевых данных (метрика привязана к конкретным взаимодействиям, поэтому лабораторные замеры на быстром ноутбуке её регулярно не видят), найти худшее взаимодействие, спрофилировать его, починить самую широкую полосу, измерить снова. Команда из истории прошла этот цикл задом наперёд — чинить сразу, не измерять никогда.