FID пішов у минуле. Тепер важливий увесь досвід користувача.
Довгий час front-end команди були сфокусовані на First Input Delay.
Логіка була проста: якщо перша взаємодія користувача швидка, значить сторінка здається швидкою.
Тепер цього вже недостатньо.
Сучасний досвід користувача визначається не одним кліком, а всією сесією: відкриттям меню, друком у формах, фільтрацією списків, перемиканням вкладок, закриттям модалок, drag-and-drop, важкими state update та повторними рендерами. Сайт може бути швидким на першій дії і водночас дратівливо повільним через пів хвилини.
Саме тому фокус змістився на Interaction to Next Paint, або INP.
Що насправді вимірює INP.
INP набагато ближчий до того, як інтерфейс поводиться в реальному житті.
Замість того щоб дивитися лише на першу взаємодію, ця метрика оцінює чутливість інтерфейсу протягом усього візиту і звертає увагу на найповільніші значущі дії. Це значно ближче до того, що реально відчуває користувач.
Через це повністю змінюється логіка оптимізації.
Більше не можна радіти тому, що лендинг завантажується швидко, якщо при цьому зависає фільтр, смикається дашборд або форма на React блокує main thread під час валідації.
INP змушує оптимізувати не скріншот із завантаженням, а реальний продукт.
Чому "заморожений" інтерфейс так швидко вбиває довіру.
Користувач не думає мілісекундами. Користувач думає впевненістю.
У момент, коли він натискає кнопку і не бачить візуального відгуку, навіть якщо затримка коротка, інтерфейс починає здаватися зламаним. Це дорого коштує. З'являються повторні кліки, нервозність, перервані сценарії і непомітна втрата довіри до продукту.
У сучасних front-end застосунках погана взаємодія найчастіше виникає тоді, коли перевантажений main thread.
Таке стається, коли:
- JavaScript виконує занадто важку роботу
- state updates запускають зайві рендери
- великі payload парсяться в невдалий момент
- дорогі компоненти монтуються саме під час взаємодії
- після змін у DOM різко росте вартість layout і paint
Сайту не обов'язково впасти, щоб здаватися поганим. Достатньо просто пропустити той момент, коли користувач очікує негайного відгуку.
INP - це проблема архітектури продукту, а не лише проблема Lighthouse.
Багато команд досі сприймають performance як чекбокс в аудиті.
З INP цей підхід уже не працює.
INP карає ті архітектурні рішення, які роблять інтерфейс крихким:
- надто великі client-side bundle
- надмірні повторні рендери дерев компонентів
- синхронна важка логіка всередині input handler
- блокуючий parsing під час взаємодії
- повільна hydration
- невдало спроєктовані UI-оновлення, що залежать від мережі
Тому performance у 2026 році - це вже не про дрібні мікрооптимізації. Це про системний дизайн. Треба дробити роботу, відкладати неважливу логіку, уникати дорогих синхронних шляхів і робити взаємодії легкими.
Якщо один клік запускає занадто багато роботи, браузер просто не встигає намалювати наступний кадр.
Ось у цьому й уся суть.
CLS досі тихо псує навіть гарні інтерфейси.
Поки всі дивляться на responsiveness, Cumulative Layout Shift продовжує непомітно псувати враження.
Користувачі ненавидять рухомі цілі.
Якщо кнопки стрибають, текст зміщується, картки змінюють розмір, skeleton-екрани колапсують або зображення завантажуються без зарезервованого місця, продукт виглядає недбалим навіть тоді, коли він технічно швидкий.
Один із найпростіших і найефективніших способів захиститися - резервувати місце ще до того, як контент з'явиться:
- задавати width і height для медіа, де це можливо
- використовувати
aspect-ratio - не вставляти контент над уже видимим контентом
- стабілізувати динамічні банери та embed-блоки
- робити skeleton максимально схожим на фінальний layout
CLS - це не лише проблема метрики. Це питання поваги до користувача. Воно показує, наскільки ваш інтерфейс контрольований.
Новий трюк: майже миттєва навігація.
Одна з найцікавіших стратегій сучасної веб-продуктивності - скорочення відстані між наміром користувача і реакцією системи.
Якщо браузер може передбачити, куди користувач піде далі, він може почати готувати цей маршрут заздалегідь. Саме тут великої сили набувають рішення на кшталт Speculation Rules API.
Якщо використовувати їх обережно, predictive prefetching і prerendering можуть зробити навігацію майже миттєвою. Продукт починає поводитися не як сайт, що чекає мережу, а як локальний застосунок.
І це вже не просто технічний polish. Це відчуття класу продукту.
Що роблять команди, які реально мають хороші web vitals.
Команди, які справді добре працюють із сучасними метриками, зазвичай мають спільні звички:
- міряють реальні взаємодії, а не тільки лабораторні тести
- профілюють важкі користувацькі сценарії, а не лише page load
- сприймають responsiveness як фічу
- проєктують компоненти так, щоб вони поводилися гідно навіть під навантаженням
- агресивно борються з будь-яким синхронним блокуванням main thread
Різниця не в тому, що їм більше подобається Lighthouse. Різниця в тому, що їм більше важливо, що реально відчуває користувач.
Висновок.
Перехід від FID до INP - це значно більше, ніж проста заміна метрики.
Це зміна самого визначення слова "швидко".
Тепер швидкий сайт - це не той, що лише швидко завантажується. Швидкий сайт - це той, що продовжує плавно реагувати вже після того, як користувач почав із ним взаємодіяти.
І це, чесно кажучи, набагато правильніший стандарт.
М'який CTA.
Якщо продукт має виглядати професійно, швидкість уже не є опцією. Так само як і зручний сценарій презентації себе та бронювання.
Побудуйте чистіший клієнтський досвід разом із Meetfolio.