INP-оптимизация в Next.js 16: почему 43% сайтов проваливают метрику и как это исправить

12 марта 2024 года Google официально заменил FID на INP в качестве Core Web Vital. Переход обнажил огромную слепую зону: 94% сайтов имели 'Good' по FID, но лишь 54% прошли более строгий порог INP. По данным HTTP Archive Web Almanac 2025, 43% мобильных ресурсов по-прежнему не укладываются в 200 мс - и эта цифра почти не движется уже два года. В статье разбираю причины, три фазы измерения и шесть векторов оптимизации для Next.js 16 с данными из реальных продакшн-деплойментов.

Почему Google заменил FID на INP в Core Web Vitals?

FID измерял исключительно задержку ввода перед самым первым взаимодействием на странице - как правило, кликом до завершения гидратации JavaScript. Фундаментальный статистический изъян: пользователь, нажавший 'Добавить в корзину' через три секунды после загрузки, вообще не влияет на показатель FID - независимо от скорости отклика интерфейса. INP фиксирует задержку всех квалифицированных взаимодействий за сессию и возвращает значение на уровне 98-го перцентиля. По Web Almanac 2025: снижение общего показателя прохождения CWV на 5 п.п. после перехода с FID на INP. Google подтвердил в мае 2023 года, что INP входит в сигналы page experience для органического ранжирования.

Как браузер на самом деле измеряет INP?

• Задержка ввода (input delay): от аппаратного прерывания до начала выполнения первого обработчика события.
• Время обработки (processing time): суммарная длительность всех синхронных обработчиков и DOM-мутаций.
• Задержка презентации (presentation delay): от завершения последнего обработчика до коммита кадра в compositor.
• Good: ≤ 200 мс | Needs Improvement: 201–500 мс | Poor: > 500 мс.
• Правило 75-го перцентиля: не менее 75% сессий должны иметь 'Good' INP для классификации URL в CrUX.

Каковы четыре главных причины плохого INP?

• Монополизация главного потока (~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).

Как scheduler.yield() снижает INP при длинных задачах?

• Антипаттерн: Последовательный 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 мс.

Действительно ли компилятор React 19 улучшает INP, и насколько?

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.

Помогают ли React Server Components с INP, и сколько JS они убирают?

Компоненты без browser API, обработчиков событий и состояния рендерятся на сервере и не добавляют JavaScript в клиентский бандл. Меньший бандл → быстрее парсинг → короче гидратация → меньше конкуренции → ниже задержка ввода. По данным Vercel: миграция 200 КБ на RSC сокращает TTI на 800 мс–1.2 с. Ключевое правило: размещайте 'use client' максимально низко - только на действительно интерактивных 'островах'.

Когда стоит оборачивать обновления состояния в startTransition ради INP?

• Паттерн фильтрации: startTransition(() => { setFilter(v); }) - React прерывает дорогой рендер при новом взаимодействии.
• Важно: Срочные обновления (инпут, кнопки) - синхронными. startTransition только для 'навигационных' переходов.
• `isPending`: Для skeleton-состояний во время отложенного рендера - предотвращает CLS.

Как изолировать сторонние скрипты, чтобы они не блокировали INP?

• Partytown: Web Worker для сторонних скриптов. TBT −200–600 мс на страницах с 5+ маркетинговыми скриптами.
• Facade Pattern: Заглушка вместо виджета; реальный скрипт - при первом взаимодействии.
• Next.js Script: lazyOnload → пиксели; afterInteractive → A/B-тестирование; beforeInteractive → только CMP/полифилы.

Какие паттерны Next.js 16 конкретно помогают INP в продакшене?

• Partial Prerendering: Статическая оболочка мгновенно из edge-кэша, персонализированный контент - асинхронный стриминг. export const experimental_ppr = true.
• `useOptimistic`: Немедленный отклик UI до ответа сервера. Воспринимаемый INP → 0 мс.
• Кэширование Route Handler: s-maxage=60, stale-while-revalidate=300 - устраняет искусственные задержки клиентской навигации.

Какого улучшения INP стоит ожидать после применения этих исправлений?

• 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 | кейсы | консультация.