React, Vue и наблюдаемость INP в продакшене

Пользователи сообщают, что строка поиска на вашем React-дашборде «ощущается медленной». INP показывает 380 мс p75. Вы деплоите фикс, и INP падает до 90 мс. Три недели спустя вас не будят в два ночи, когда PR другого инженера откатывает улучшение — потому что вы так и не подключили LoAF-телеметрию к CI-конвейеру.

Как работает планировщик React 18

Планировщик React выполняет рекоцилиацию кооперативными кусками по 5 мс. После каждого куска он уступает браузеру с помощью MessageChannel.postMessage — единственного кросс-браузерного механизма, ставящего задачу без зажима 4 мс от setTimeout. Цикл браузера получает возможность запустить ввод, рендеринг и другие задачи; React возобновляется на следующей задаче для следующего куска 5 мс.

Это реализация «конкурентного React»: один рендер разбивается на множество задач, ни одна из которых не превышает порог длинной задачи 50 мс. useTransition помечает обновление состояния как низкоприоритетное, позволяя обновлениям ввода прерывать его. Понять цикл — и планировщик React перестаёт быть загадкой.

Планировщик Vue 3

Vue 3 пакетирует реактивные обновления в микрозадаче: запись в ref планирует микрозадачу, которая сбрасывает все ожидающие обновления в конце текущей задачи. Это означает, что множество записей в одной задаче сворачивается в одно обновление — но это также означает, что сброс является микрозадачей и может продлевать голодание, если он вызывает больше реактивных записей.

Vue предоставляет nextTick(callback) для кода, который хочет выполниться после сброса; под капотом это просто ещё одна микрозадача, запланированная после микрозадачи сброса.

Конвейер поиска причин INP в продакшене

Рецепт поиска причин INP в продакшене:

Подпишитесь на записи LoAF с PerformanceObserver. Для каждой записи фиксируйте firstUIEventTimestamp, renderStart записи и массив scripts с атрибуцией. Когда INP срабатывает для медленного взаимодействия (тоже через PerformanceObserver), сопоставьте по id взаимодействия: найдите LoAF, перекрывавший ввод, атрибутируйте время самому тяжёлому скрипту, отправьте в телеметрию с URL скрипта и именем функции (разрешённым через sourcemap на стороне сервера). Этот конвейер превращает «пользователи жалуются на тормоза» в «деплой 3a4f1c регрессировал поле поиска, добавив вызов редьюсера на 320 мс».

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.entryType === 'long-animation-frame') {
      const heaviest = entry.scripts
        .sort((a, b) => b.duration - a.duration)[0];
      sendToTelemetry({
        frameStart: entry.startTime,
        frameDuration: entry.duration,
        scriptUrl: heaviest?.sourceURL,
        functionName: heaviest?.sourceFunctionName,
        charPosition: heaviest?.sourceCharPosition,
      });
    }
  }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

INP как CI-гейт. Продакшен-телеметрия ловит регрессии после того, как они достигли пользователей. Реалистичный гейт: синтетический тест Playwright/Puppeteer в headless Chrome воспроизводит критическое взаимодействие (набрать запрос в поиске, открыть меню, переключить вкладку), измеряет INP через тот же код PerformanceObserver, что и в продакшене, и блокирует слияние, если p75 превысил бюджет. Ключевая деталь: headless Chrome на CI-раннере обычно быстрее среднего телефона пользователя, поэтому без --cpu-throttling-rate=4 (или эквивалента CDP) тест проходит локально и падает в продакшене. Бюджеты размера бандла добавляют второй слой: размер JS напрямую конвертируется во время разбора+компиляции, которое конвертируется в длинные задачи при загрузке. Без всех трёх слоёв — синтетического INP-гейта, бюджета бандла и продакшен LoAF-алертов — регрессия проскальзывает тихо и живёт до следующего ручного профилирования.