Браузер и фронтенд-рантайм
React fiber: усмирить шторм перерендеров
Читать про bailout и lanes — не то же самое, что вытащить реальный UI из шторма перерендеров. Соберите живую интерактивную сетку данных, доведите её до jank, затем примените лестницу фиксов модуля — мемоизация, collocation, time-slicing, виртуализация, защита от tearing — пока цифры не вернутся, с доказательствами из Profiler на каждом шаге.
Превратите ментальную модель модуля в воспроизводимый инженерный цикл: инструментируйте React Profiler, читайте причину перерендера каждого fiber, чините на нужном уровне (референциальная стабильность, затем collocation состояния, затем приоритет, затем виртуализация), защититесь от tearing и проверьте фикс цифрами INP и времени commit до/после.
Возьмите намеренно дёргающуюся живую сетку данных (свою или по спецификации ниже) и доведите её INP по нажатиям до значения под 200 мс, а время commit — под один кадр, не переписывая на другом фреймворке, доказывая каждый шаг измерениями из React Profiler и панели Performance.
- Таблица до/после: INP по нажатиям (p75), самое длинное время commit и число перерендеров на нажатие — всё измерено под той же нагрузкой живых тиков, не оценено.
- Трейсы Profiler до и после: базовый показывает широкий шторм 'parent rendered, props unchanged'; исправленный трейс показывает рендер только реально изменившихся видимых строк, с commit под ~8 мс.
- INP по нажатиям держится под 200 мс p75 при непрерывном вводе, пока стор тикает ~10/секунду, и ни один Long Animation Frame не атрибутируется сетке за 30-секундную сессию.
- Абзац-описание, называющий, какой рычаг исправил каждый симптом (референциальная стабильность vs collocation состояния vs приоритет vs виртуализация vs tearing) и почему этот рычаг занял своё место.
- Включите React Compiler и перепрофилируйте: убедитесь, что он вставляет мемоизацию, которую вы написали вручную, отметьте компонент, где он делает bailout консервативно, и объясните, почему понимание механизма bailout позволило вам прочитать его вывод.
- Добавьте намеренный побочный эффект в render-фазе (вызов аналитики в теле компонента), запустите под StrictMode и покажите двойной учёт; затем перенесите в useEffect и покажите исправленный счёт — задокументировав, почему render должна быть чистой.
- Добавьте useLayoutEffect, измеряющий строку через getBoundingClientRect и меняющий стиль, затем покажите в Profiler, как он удлиняет commit (forced reflow); сравните с той же работой в useEffect после paint.
- Напишите однострочный on-call runbook: шаги триажа в Profiler, сигнатуру 'parent rendered + unchanged props', лестницу фиксов по порядку и чек-лист верификации, связывающий каждый фикс с измеримой дельтой Profiler/INP.
Это цикл, который вы запустите в каждом реальном инциденте производительности React: сначала инструментируйте Profiler, читайте причину перерендера по каждому fiber, затем чините на нужном уровне — референциальная стабильность до collocation состояния до приоритета до виртуализации — защититесь от tearing через useSyncExternalStore и проверьте цифрами INP и commit до/после под одинаковой нагрузкой. Один раз сделав это на игрушечной сетке, вы доводите продакшен-версию до мышечной памяти и превращаете вывод React Compiler в то, что можно читать, а не слепо доверять.