Аннотация. 12 марта 2024 года рабочая группа W3C по веб-производительности официально заменила First Input Delay (FID) на Interaction to Next Paint (INP) как Core Web Vital. Переход обнажил системную слепую зону: 94% сайтов имели оценку 'Good' по FID, но лишь 54% прошли более строгий порог INP. Согласно HTTP Archive Web Almanac 2025, 43% мобильных источников по-прежнему не укладываются в 200 мс. Статья представляет формальную таксономию причин отказов, декомпозиционную модель трёх фаз и шесть конкретных векторов оптимизации для приложений на Next.js 16 с данными производственных бенчмарков.
Смена парадигмы: почему FID был недостаточным прокси
FID измерял исключительно задержку ввода перед самым первым взаимодействием на странице - как правило, кликом до завершения гидратации JavaScript. Фундаментальный статистический изъян: пользователь, нажавший 'Добавить в корзину' через три секунды после загрузки, вообще не влияет на показатель FID - независимо от скорости отклика интерфейса. INP фиксирует задержку всех квалифицированных взаимодействий за сессию и возвращает значение на уровне 98-го перцентиля. По Web Almanac 2025: снижение общего показателя прохождения CWV на 5 п.п. после перехода с FID на INP. Google подтвердил в мае 2023 года, что INP входит в сигналы page experience для органического ранжирования.
Модель измерения: три субинтервала и пороги
- Задержка ввода (input delay): от аппаратного прерывания до начала выполнения первого обработчика события.
- Время обработки (processing time): суммарная длительность всех синхронных обработчиков и DOM-мутаций.
- Задержка презентации (presentation delay): от завершения последнего обработчика до коммита кадра в compositor.
- Good: ≤ 200 мс | Needs Improvement: 201–500 мс | Poor: > 500 мс.
- Правило 75-го перцентиля: не менее 75% сессий должны иметь 'Good' INP для классификации URL в CrUX.
Таксономия причин отказов
- Монополизация главного потока (~67%): Синхронный блок JS > 50 мс блокирует обработку событий ввода. Наиболее частая причина в React-приложениях.
- Гидратация (~20%): На Moto G Power гидратация 200-компонентной страницы занимает 350–800 мс непрерывного времени главного потока.
- Re-render-трэшинг (~10%): Без мемоизации один
setFilter()провоцирует O(n) вычислений компонентов. - Сторонние скрипты (~3%): 47 сторонних запросов на медианной eCommerce-странице, 1.2 с блокировки главного потока (HTTP Archive 2025).
Вектор I: scheduler.yield() - декомпозиция главного потока
- Антипаттерн: Последовательный
useEffectс 4+ функциями инициализации - составная задача 300–700 мс. - Паттерн:
async function init() { await step1(); await scheduler.yield(); await step2(); }- каждый yield создаёт границу задачи для очереди событий ввода. - Полифилл:
const yield_ = () => 'scheduler' in window ? scheduler.yield() : new Promise(r => setTimeout(r, 0)); - Эффект: Фрагментация одной задачи 500 мс в несколько задач < 50 мс. Снижение input delay на 60–150 мс.
Вектор II: Компилятор React 19 и автоматическая мемоизация
React Compiler (v1.0, октябрь 2025) автоматически вставляет мемоизацию там, где статический анализ доказывает ссылочную стабильность, устраняя потребность в ручных React.memo, useMemo, useCallback. Бенчмарки Meta и Vercel: −20–40% повторных рендеров, −30–80 мс INP на листинговых страницах. Включение в Next.js 15.1+: experimental: { reactCompiler: true }. Проверка совместимости: npx react-compiler-healthcheck.
Вектор III: React Server Components
Компоненты без browser API, обработчиков событий и состояния рендерятся на сервере и не добавляют JavaScript в клиентский бандл. Меньший бандл → быстрее парсинг → короче гидратация → меньше конкуренции → ниже задержка ввода. По данным Vercel: миграция 200 КБ на RSC сокращает TTI на 800 мс–1.2 с. Ключевое правило: размещайте 'use client' максимально низко - только на действительно интерактивных 'островах'.
Вектор IV: startTransition
- Паттерн фильтрации:
startTransition(() => { setFilter(v); })- React прерывает дорогой рендер при новом взаимодействии. - Важно: Срочные обновления (инпут, кнопки) - синхронными.
startTransitionтолько для 'навигационных' переходов. - `isPending`: Для skeleton-состояний во время отложенного рендера - предотвращает CLS.
Вектор V: Изоляция сторонних скриптов
- Partytown: Web Worker для сторонних скриптов. TBT −200–600 мс на страницах с 5+ маркетинговыми скриптами.
- Facade Pattern: Заглушка вместо виджета; реальный скрипт - при первом взаимодействии.
- Next.js Script:
lazyOnload→ пиксели;afterInteractive→ A/B-тестирование;beforeInteractive→ только CMP/полифилы.
Вектор VI: Архитектурные паттерны Next.js 16
- Partial Prerendering: Статическая оболочка мгновенно из edge-кэша, персонализированный контент - асинхронный стриминг.
export const experimental_ppr = true. - `useOptimistic`: Немедленный отклик UI до ответа сервера. Воспринимаемый INP → 0 мс.
- Кэширование Route Handler:
s-maxage=60, stale-while-revalidate=300- устраняет искусственные задержки клиентской навигации.
Инфраструктура измерений и производственные бенчмарки
- CrUX API: Авторитетные полевые данные - 75-й перцентиль реальных пользователей.
- web-vitals.js:
onINP(({ value, rating }) => sendToAnalytics({ inp: value, rating }));- точный алгоритм CrUX. - Lighthouse CI: TBT ≤ 300 мс как ворота регрессии в CI/CD.
- RSC: INP −120–280 мс | scheduler.yield(): −60–150 мс | Compiler: −30–80 мс | Partytown: TBT −200–600 мс.
- Совокупно: Переход из 'Needs Improvement' в 'Good' достижим при базовом INP < 450 мс. Сайты с 'Good' CWV: +24% мобильная конверсия (Google, 2024).
Заключение
INP - фундаментальный архитектурный сигнал о качестве взаимодействия фронтенд-системы с главным потоком браузера. Устойчивость показателя отказов в 43% спустя два года отражает архитектурную природу проблемы - она не решается точечными правками. Шесть представленных векторов образуют системный подход к управлению главным потоком как явно управляемым ресурсом. Если ваш INP превышает 200 мс - это конкретная инженерная задача с устранимой первопричиной. Для структурированного аудита: услуга Core Web Vitals | кейсы | консультация.