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 Vital?

FID вимірював затримку лише першої взаємодії - до завершення гідратації JS. Користувач, що натискає 'Додати до кошика' через 3 секунди після завантаження, не впливає на FID взагалі. INP фіксує всі кваліфіковані взаємодії за сесію і повертає 98-й перцентиль. Web Almanac 2025: −5 в.п. загального проходження CWV після переходу. INP - офіційний сигнал ранжування Google з травня 2023.

Як браузер насправді вимірює INP?

• Input delay: від апаратного переривання до початку виконання першого обробника.
• Processing time: сумарна тривалість синхронних обробників і DOM-мутацій.
• Presentation delay: від завершення обробника до коміту кадру в compositor.
• Good ≤ 200 мс | Needs Improvement 201–500 мс | Poor > 500 мс.
• 75-й перцентиль: ≥75% сесій мають бути 'Good' для класифікації у CrUX.

Які чотири основні причини поганого INP?

• Монополізація головного потоку (~67%): Блок JS > 50 мс блокує обробку подій вводу.
• Гідратація (~20%): На Moto G Power - 350–800 мс безперервного часу головного потоку для 200-компонентної сторінки.
• Re-render-трешинг (~10%): Без меж мемоізації - O(n) обчислень компонентів на кожен setFilter().
• Сторонні скрипти (~3%): 47 запитів, 1.2 с блокування на медіанній eCommerce-сторінці (Web Almanac 2025).

Як scheduler.yield() знижує INP від довгих задач?

• Антипатерн: 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 мс.

Чи дійсно компілятор React 19 покращує INP, і наскільки?

Автоматична мемоізація там, де статичний аналіз доводить стабільність. −20–40% рендерів, −30–80 мс INP. experimental: { reactCompiler: true } у next.config.ts. npx react-compiler-healthcheck для аналізу покриття.

Чи допомагають React Server Components з INP, і скільки JS вони прибирають?

Нуль JS у клієнтському бандлі → коротша гідратація → менша конкуренція → нижча затримка вводу. Vercel: −800 мс–1.2 с TTI при міграції 200 КБ на RSC. Розміщуйте 'use client' максимально низько - тільки на інтерактивних 'островах'.

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

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

Як ізолювати сторонні скрипти та які патерни Next.js 16 допомагають INP?

• Partytown: Web Worker для сторонніх скриптів. TBT −200–600 мс.
• Facade Pattern: Статичне зображення замість важкого віджету; справжній скрипт - при першій взаємодії.
• Partial Prerendering: Статична оболонка миттєво, динамічний контент - стримінг. experimental_ppr = true.
• `useOptimistic`: Сприйманий INP → ~0 мс для операцій кошика та форм.
• Кешування: s-maxage=60, stale-while-revalidate=300 на частих API-маршрутах.

Якого покращення INP очікувати після застосування цих виправлень?

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