INP (Interaction to Next Paint)

INP (Interaction to Next Paint) — це показник responsiveness, який оцінює затримку між взаємодією користувача та наступним візуальним оновленням сторінки. Він спостерігає за кліками, торканнями й натисканнями клавіш протягом усього візиту.

INP є Core Web Vital і замінив FID як основний показник інтерактивності. На відміну від FID, він охоплює не лише першу взаємодію та включає повний шлях до наступного кадру.

Актуальні пороги

• добре: до 200 мс включно;
• потребує покращення: понад 200 до 500 мс включно;
• погано: понад 500 мс.

Google рекомендує оцінювати 75-й перцентиль польових даних окремо для mobile і desktop.

Що входить в одну взаємодію

• input delay — очікування до запуску event handlers;
• processing duration — виконання обробників;
• presentation delay — час до відображення наступного кадру.

Оптимізація лише функції click handler не допоможе, якщо main thread заблокований іншими long tasks або браузер довго виконує layout і paint.

Як формується INP візиту

Браузер спостерігає за qualifying interactions і зазвичай повідомляє одну з найдовших затримок, відкидаючи окремі outliers у візитах із великою кількістю взаємодій. Тому швидка перша кнопка не компенсує повільний фільтр, меню чи checkout пізніше.

Практичний приклад

Користувач каталогу будматеріалів обирає фільтр «у наявності». Сторінка синхронно обробляє великий масив товарів, перебудовує DOM і запускає аналітичні скрипти. Галочка реагує через 850 мс. Навіть якщо мережевий запит швидкий, INP буде поганим через блокування main thread і пізній paint.

Поширені причини

• довгі JavaScript tasks;
• важкі сторонні скрипти й теги;
• надмірний DOM;
• дорогі style recalculation, layout і rendering;
• синхронна робота в event handler;
• hydration великого інтерфейсу;
• відсутність раннього візуального feedback.

Як покращити INP

• розбивати long tasks і періодично поступатися main thread;
• мінімізувати роботу обробників;
• відкладати некритичну аналітику;
• зменшувати DOM і вартість рендерингу;
• показувати негайний стан натискання або progress;
• використовувати web workers для придатних обчислень;
• видаляти застарілі плагіни, віджети й теги.

Field data і lab data

INP потребує реальних взаємодій, тому сторінка без дій у lab не дає повної оцінки. CrUX показує агреговані реальні візити, але не називає конкретну повільну кнопку. Для діагностики потрібні RUM із interaction attribution, Chrome DevTools і відтворення сценаріїв.

Сторінки без взаємодій

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

INP і конверсія

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

Типові помилки

• плутати INP з часом мережевого запиту;
• тестувати лише першу взаємодію;
• не давати візуального feedback;
• оптимізувати власний код і ігнорувати third-party scripts;
• оцінювати лише потужний desktop;
• вважати відсутнє польове значення добрим;
• не сегментувати шаблони й сценарії.

Професорська та директорська перевірка

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

Пов’язані поняття

Core Web Vitals · FID · Long task · Main thread · RUM · Event Timing API · LCP · CLS

Висновок

INP показує, чи реагує сторінка тоді, коли користувач намагається щось зробити. Покращення потребує скорочення блокування main thread, вартості рендерингу й некритичної роботи, а також швидкого видимого feedback.

Джерело

web.dev: Interaction to Next Paint