Навчання
Оптимізація INP: як виправити Interaction to Next Paint і Core Web Vitals
Практичний гайд про Interaction to Next Paint: що метрика вимірює, чому її складніше виправити, ніж швидкість завантаження, і як прискорити реальні взаємодії.
Запусти свіжий аудит DomainLens і використовуй звіт як список пріоритетів.
Що насправді вимірює INP
Interaction to Next Paint (INP) вимірює чутливість: скільки часу минає, поки сторінка візуально відреагує після кліку, тапу чи натискання клавіші. Метрика стежить за всіма взаємодіями протягом візиту й показує майже найгіршу з них, тому одне «підвисле» меню або повільна кнопка «додати в кошик» можуть визначити оцінку всієї сторінки.
Хороший поріг — 200 мс або менше; понад 500 мс — погано. На відміну від LCP, яка про те, як швидко зʼявляється контент, INP — про те, що відбувається, коли сторінка вже на екрані. Саме тому сторінка може швидко завантажитись і все одно «гальмувати», коли ти починаєш нею користуватися.
Чому INP складніше виправити, ніж швидкість завантаження
Метрики завантаження залежать переважно від мережі й сервера, тому кешування та швидший хостинг дають багато. INP залежить від твого власного JavaScript, який виконується в main thread. Коли спрацьовує клік, браузер не може відмалювати відповідь, поки не завершиться обробник події, ре-рендер фреймворку й уся інша робота в черзі — тож довгі задачі, непомітні на швидкому ноутбуці, стають видимими затримками на середньому телефоні.
INP замінила First Input Delay у березні 2024 року. FID вимірювала лише затримку до початку обробки першої взаємодії; INP вимірює повний час до наступного відмальованого кадру, і то для взаємодій протягом усього візиту. Це набагато суворіше — і саме тому сайти, які легко проходили FID, можуть провалювати INP.
Де знайти найгірші взаємодії
Починай з field data — INP це метрика реальних користувачів, і лабораторний інструмент не знає, з якою саме кнопкою мучаться твої відвідувачі.
- Chrome UX Report / Search Console: підтверди, що INP провалюється в реальних користувачів, і поглянь, це mobile, desktop чи конкретні шаблони.
- Розширення Web Vitals або панель Performance: відтвори взаємодію й прочитай розклад INP на input delay, processing time і presentation delay.
- Трек long tasks у панелі Performance: запиши, поки клікаєш проблемний елемент, і знайди задачу понад 50 мс, яка блокує наступний paint.
- Devtools фреймворку (React Profiler, Vue Devtools): знайди компоненти, що ре-рендеряться набагато частіше, ніж потрібно, на одну взаємодію.
Як прискорити реакцію на взаємодії
Мета — дати браузеру шанс відмалювати кадр, перш ніж робити важку роботу. Розбий велику задачу на маленьку видиму реакцію зараз і важку роботу після неї.
- Віддавай main thread: після оновлення того, що бачить користувач, відклади несрочну роботу через requestIdleCallback, setTimeout або await scheduler.yield(), щоб браузер устиг відмалювати.
- Зменшуй вартість hydration: на React, Vue, Nuxt чи Next.js віддавай менше клієнтського JavaScript і надавай перевагу server components або islands, щоб на завантаженні чіплялося менше обробників.
- Приборкай сторонні скрипти: analytics, чат-віджети, tag manager і рекламні скрипти працюють у тому ж main thread — вантаж їх ліниво й прибирай ті, що нічого не дають.
- Debounce і memoize: не давай важкій фільтрації, розрахунку layout і оновленням стану спрацьовувати на кожне натискання клавіші чи скрол, і кешуй похідні значення.
Помилки, через які INP лишається червоним
- Оптимізувати тільки Total Blocking Time у Lighthouse і вважати, що польовий INP підтягнеться — TBT це проксі часу завантаження, а не реальні взаємодії користувачів.
- Тестувати на швидкому desktop, коли трафік — середні Android, де той самий обробник виконується в кілька разів довше.
- Залишати кожен сторонній тег, бо він «здається маленьким» — вартість накопичується й лягає на interaction path.
- Виправляти середню взаємодію замість найгіршої; INP визначається повільним «хвостом», а не медіаною.
Як підтвердити, що INP справді покращився
Польові метрики рухаються повільно, бо агрегують 28 днів реальних візитів, тож не чекай, що графік у Search Console стрибне того ж дня, коли ти зробив деплой. Перевіряй у два шари: відтвори конкретну взаємодію в панелі Performance і переконайся, що довга задача зникла, а потім стеж за трендом field data наступні тижні.
У DomainLens розглядай INP у тому ж ланцюжку доказів, що LCP, CLS і швидкість сторінки — найсильніші виправлення ті, що роблять живу сторінку справді швидшою у користуванні, а не просто зеленішою в лабораторному прогоні.