Анотація. 12 березня 2024 року W3C офіційно замінила FID на INP як Core Web Vital. 94% сайтів мали 'Good' за FID, але лише 54% пройшли суворіший поріг INP. За Web Almanac 2025, 43% мобільних ресурсів досі не вкладаються у 200 мс. Стаття подає формальну таксономію відмов, модель трьох фаз і шість векторів оптимізації для Next.js 16 з виробничими бенчмарками.
Зміна парадигми: обмеження FID і переваги INP
FID вимірював затримку лише першої взаємодії - до завершення гідратації JS. Користувач, що натискає 'Додати до кошика' через 3 секунди після завантаження, не впливає на FID взагалі. INP фіксує всі кваліфіковані взаємодії за сесію і повертає 98-й перцентиль. Web Almanac 2025: −5 в.п. загального проходження CWV після переходу. INP - офіційний сигнал ранжування Google з травня 2023.
Три субінтервали та порогові значення
- Input delay: від апаратного переривання до початку виконання першого обробника.
- Processing time: сумарна тривалість синхронних обробників і DOM-мутацій.
- Presentation delay: від завершення обробника до коміту кадру в compositor.
- Good ≤ 200 мс | Needs Improvement 201–500 мс | Poor > 500 мс.
- 75-й перцентиль: ≥75% сесій мають бути 'Good' для класифікації у CrUX.
Таксономія причин відмов
- Монополізація головного потоку (~67%): Блок JS > 50 мс блокує обробку подій вводу.
- Гідратація (~20%): На Moto G Power - 350–800 мс безперервного часу головного потоку для 200-компонентної сторінки.
- Re-render-трешинг (~10%): Без меж мемоізації - O(n) обчислень компонентів на кожен
setFilter(). - Сторонні скрипти (~3%): 47 запитів, 1.2 с блокування на медіанній eCommerce-сторінці (Web Almanac 2025).
Вектор I: scheduler.yield()
- Антипатерн:
useEffect(() => { init1(); init2(); init3(); }, [])- задача 300–700 мс. - Патерн:
await init1(); await scheduler.yield(); await init2();- межі задач для черги вводу. - Поліфіл:
const y = () => 'scheduler' in window ? scheduler.yield() : new Promise(r => setTimeout(r, 0)); - Ефект: Input delay −60–150 мс.
Вектор II: Компілятор React 19
Автоматична мемоізація там, де статичний аналіз доводить стабільність. −20–40% рендерів, −30–80 мс INP. experimental: { reactCompiler: true } у next.config.ts. npx react-compiler-healthcheck для аналізу покриття.
Вектор III: React Server Components
Нуль JS у клієнтському бандлі → коротша гідратація → менша конкуренція → нижча затримка вводу. Vercel: −800 мс–1.2 с TTI при міграції 200 КБ на RSC. Розміщуйте 'use client' максимально низько - тільки на інтерактивних 'островах'.
Вектор IV: startTransition та паралельний рендеринг
- Патерн:
startTransition(() => { setFilter(v); })- React перериває рендер при новій взаємодії. - Важливо: Термінові оновлення (інпут, кнопки) - синхронні.
startTransition- тільки для 'навігаційних' переходів. - `isPending`: Для skeleton UI під час відкладеного рендеру - запобігає CLS.
Вектори V–VI: Сторонні скрипти та Next.js 16
- Partytown: Web Worker для сторонніх скриптів. TBT −200–600 мс.
- Facade Pattern: Статичне зображення замість важкого віджету; справжній скрипт - при першій взаємодії.
- Partial Prerendering: Статична оболонка миттєво, динамічний контент - стримінг.
experimental_ppr = true. - `useOptimistic`: Сприйманий INP → ~0 мс для операцій кошика та форм.
- Кешування:
s-maxage=60, stale-while-revalidate=300на частих API-маршрутах.
Бенчмарки та висновок
- 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 - архітектурний сигнал, а не косметична метрика. Шість векторів формують системний підхід до керування головним потоком.
Якщо ваш INP перевищує 200 мс - це конкретна інженерна проблема з вирішуваною першопричиною. Послуга Core Web Vitals | Кейси | Консультація.