Взаємодія з наступною фарбою (INP)

Показник «Взаємодія до наступного малювання» вимірює, як швидко сторінка візуально реагує на введення користувача, повідомляючи значення, що відображає найгірші затримки взаємодії під час відвідування. Він замінив показник «Затримка першого введення» як показник реагування Core Web Vitals у березні 2024 року, і зміна була значною: якщо попередній показник фіксував лише затримку перед початком обробки під час першої взаємодії, то цей вимірює повну тривалість від введення через обробку до наступного кадру, що малюється, для всіх взаємодій у сеансі.

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

Зазначене значення отримано на основі найдовших спостережуваних взаємодій з урахуванням викидів на сторінках з великою кількістю взаємодій, а опублікований Google поріг трактує 200 мілісекунд або менше як хороший час на рівні сімдесят п'ятого процентиля реального користувацького досвіду. Оскільки він охоплює весь шлях від введення до малювання, низькі показники можуть виникати з кількох причин: тривалі завдання в головному потоці, що блокують браузер від обробки події, обробники подій, що виконують надмірну роботу синхронно, порушення макета, спричинене чергуванням стилів читання та запису, та дороге рендеринг після зміни стану.

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

Виправлення відбувається після діагностики. Розбиття довгих завдань на менші частини з явним переходом дозволяє браузеру обробляти вхідні дані між ними. Відкладання несуттєвої роботи до візуального оновлення, щоб користувач бачив відповідь негайно, вирішує найпоширенішу закономірність. Зменшення обсягу переданого JavaScript, аудит сторонніх скриптів на предмет вартості основного потоку, віртуалізація довгих списків і перенесення важких обчислень до виконавця вирішують конкретні причини. Надання негайного візуального зворотного зв'язку для повільних операцій не покращує виміряне значення, але змінює те, як сприймається затримка.

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

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