Що таке INP і як зрозуміти, чи сайт швидко реагує на дії користувача

Зачіпка

INP часто плутають із загальною “швидкістю сайту”, але це не зовсім так. Якщо сторінка відкривається швидко, а кнопка все одно реагує із затримкою, у користувача лишається відчуття, що інтерфейс “тупить”. Саме це і намагається виміряти INP: наскільки швидко інтерфейс показує результат після реальної дії.

Для розробника це корисно, бо показує не лише те, що сайт завантажився, а те, чи він справді відгукується на натискання, введення тексту або іншу взаємодію. Для продукту це теж важливо: повільний відгук може зіпсувати довіру навіть тоді, коли Lighthouse виглядає пристойно.

Тому INP варто читати як практичний сигнал про відчутну затримку, а не як абстрактний бал. Якщо взаємодія з інтерфейсом здається “липкою”, INP допомагає знайти, де саме з’являється затримка.

Що саме означає INP

INP розшифровується як Interaction to Next Paint. Простими словами, це метрика про те, як швидко інтерфейс показує видиму відповідь після дії користувача.

Уявіть, що користувач:

• натискає кнопку;
• вводить символ у поле;
• відкриває меню;
• перемикає фільтр;
• перетягує елемент у drag-and-drop інтерфейсі.

INP дивиться на весь шлях від цієї дії до моменту, коли браузер вже намалював наступне оновлення екрана. Тобто важлива не лише обробка події, а й те, коли користувач реально побачив результат.

Це робить INP корисним для оцінки responsiveness, особливо коли інтерфейс має багато логіки на JavaScript або важке перерендерювання.

Де новачок найчастіше помиляється

Помилка 1: плутати INP із часом завантаження сторінки

Сторінка може відкритися швидко, але все одно погано реагувати на натискання після завантаження. INP якраз про цю взаємодію після першого рендеру.

Помилка 2: думати, що це лише про мережу

Іноді затримка пов’язана не з API, а з тим, що JS довго виконується або UI блокується на main thread.

Помилка 3: шукати проблему тільки в React або іншому фреймворку

Фреймворк може впливати на симптом, але причина часто лежить у конкретному handler, великому списку, важкому state update або зайвому render.

Помилка 4: оцінювати лише лабораторний тест

INP краще читати разом із field data. Лабораторний тест показує поведінку в контрольованих умовах, а реальні користувачі можуть мати повільніший пристрій, інший браузер або більше вкладок.

Як INP працює на практиці

Спрощений шлях такий:

1. Користувач виконує дію в інтерфейсі.
2. Браузер отримує event і ставить обробку в чергу.
3. JavaScript, layout або інший довгий task може затримати реакцію.
4. Після обробки браузер показує наступне оновлення екрана.
5. INP вимірює, наскільки довгим був цей цикл для взаємодії.

На практиці це допомагає побачити, чи інтерфейс:

• занадто багато працює на main thread;
• перерендерює занадто великий фрагмент UI;
• виконує дорогі обчислення синхронно;
• блокується на layout чи style recalculation;
• чекає на зайве оновлення state перед paint.

Що саме означає “повільний” INP

INP не про “все повільно взагалі”, а про те, що користувач відчуває затримку у відповіді інтерфейсу.

Практично це може виглядати так:

• кнопка натискається, але візуальної реакції немає одразу;
• текст у полі з’являється із запізненням;
• меню відкривається не миттєво;
• список фільтрів “підвисає” після кліку;
• мобільний інтерфейс реагує гірше, ніж desktop.

Для людини це відчувається як відсутність відгуку. Саме тому INP так добре пов’язаний із UX.

Як поліпшити INP без зайвої магії

Практичні кроки:

1. Знайдіть найдорожчу взаємодію.
2. Подивіться, чи не блокує main thread великий sync task.
3. Скоротіть роботу в event handler.
4. Розбийте важкі обчислення на менші частини.
5. Не перерендерюйте більше UI, ніж потрібно.
6. Перевірте, чи можна відкласти нешвидкі оновлення.
7. Оптимізуйте великі списки, фільтри та складні компоненти.
8. Перевірте поведінку на повільнішому пристрої.

INP часто покращується не через одну “магічну” оптимізацію, а через зменшення роботи, яку браузер має зробити синхронно до наступного paint.

На що дивитися в реальному проєкті

Коли ви перевіряєте INP у своєму проєкті, пройдіться по такому списку:

• яка саме взаємодія дає найгірший відгук;
• чи є довгі tasks на main thread під час цієї дії;
• чи не викликає handler важку синхронну роботу;
• чи не перерендерюється занадто великий шматок сторінки;
• чи є різниця між desktop і mobile;
• чи підтверджується проблема field data;
• чи не плутаєте INP із LCP, TTFB або CLS;
• чи допомагає спрощення UI або відкладене оновлення state.

Якщо у вас React, Vue, Svelte або інший фреймворк, окремо перевірте:

• чи не запускається зайвий re-render на кожен input;
• чи не тримає компонент великі масиви в memory без потреби;
• чи не тягне візуальне оновлення занадто багато синхронної логіки;
• чи можна винести частину роботи з interaction path.

Короткий висновок

INP показує, наскільки швидко сайт відгукується на реальні дії користувача. Це не просто технічна метрика, а дуже практичний сигнал про якість інтерфейсу.

Якщо користувач натискає кнопку, вводить текст або відкриває меню і бачить затримку, INP допомагає знайти, де саме губиться відгук. Для новачка хороше правило просте: дивіться не лише на завантаження сторінки, а й на те, як швидко інтерфейс відповідає на кожну дію.