Як покращити INP: знайдіть повільну взаємодію до зміни коду

Починати варто з повільної дії, а не з бажаного розміру бандла. Interaction to Next Paint (INP) вимірює відгук у Core Web Vitals: від кліку, дотику або клавіатурного вводу до наступного відображення. Польова оцінка використовує 75-й перцентиль окремо для мобільних і десктопних користувачів: до 200 мс включно — добре, понад 200 до 500 мс — потребує покращення, понад 500 мс — погано. Межі класифікують результат, але не визначають проблемну функцію.

Джерела:[2] web.dev

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

Якщо є атрибуція реальних взаємодій, використайте її для вибору сценарію. Збірка web-vitals з атрибуцією надає ціль взаємодії та її складові: input delay, processing duration і presentation delay. Перед додаванням вимірювань перевірте версію бібліотеки та правила збору. Краще передавати дозволену назву компонента, ніж текст або селектор із даними користувача; значення полів форми не повинні потрапляти в телеметрію.

Джерела:[5] web.dev

Джерела:[4] Chrome for Developers

Джерела:[10] Chrome for Developers

Різницю між польовими даними URL, даними origin і синтетичним тестуванням розібрано в гайді з перевірки Core Web Vitals. Тут завдання вужче: знайти повільну взаємодію, змінити одну причину та перевірити правильність завершення дії.

Читайте взаємодію зліва направо. Input delay — очікування до початку обробників події. Processing duration охоплює виконання обробників. Presentation delay — проміжок після них до відображення наступного кадру. Зміна не тієї складової може прибрати частину коду, але залишити відчутну для користувача затримку.

Джерела:[3] web.dev

Джерела:[3] web.dev

Джерела:[3] web.dev[4] Chrome for Developers

Не класифікуйте роботу лише за назвою. Читання геометрії після зміни стилів може примусово запустити layout усередині JavaScript-обробника. Тому витрати на рендеринг іноді входять до processing duration. Перевірте стек і дані forced reflow, а не відносьте будь-який layout до presentation delay.

Джерела:[3] web.dev[9] Chrome for Developers

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

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

Джерела:[1] MDN Web Docs[7] web.dev

Навчальний стенд використовує scheduler.yield(), якщо API доступний, і таймер в іншому разі. Перевірка підтримки — частина реалізації: MDN досі позначає обмежену доступність API. Обидва варіанти продовжують роботу в пізнішій задачі, але не мають однакових пріоритетів планування.

Джерела:[6] MDN Web Docs[11] Chrome for Developers

function yieldToBrowser(forceTimer = false) {
  if (!forceTimer && typeof globalThis.scheduler?.yield === 'function') {
    return globalThis.scheduler.yield();
  }
  return new Promise(resolve => setTimeout(resolve, 0));
}

Джерела:[6] MDN Web Docs[11] Chrome for Developers

У повному прикладі запуск перевіряє обсяг роботи, встановлює стан busy та не дозволяє другому запуску перезаписати його дані. Режим із yield показує прогрес між частинами роботи. Кооперативне скасування відкидає частковий результат; контрольна сума з’являється лише після повного завершення. Завершальна обробка відновлює кнопки навіть за помилки. Ці умови важливіші за скорочення допоміжної функції на один рядок.

Yield не обіцяє й того, що перед продовженням відпрацюють усі таймери. Нативний API надає продовженням інший пріоритет, ніж звичайним задачам таймерів. Перевіряйте дію, яка має залишатися доступною, наприклад Cancel або наступну зміну фільтра. Кількість викликів yield не є результатом оптимізації.

Джерела:[11] Chrome for Developers

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

Завантажте стенд для дослідження взаємодій. Усередині — HTML, CSS, JavaScript, аркуш вимірювань та інструкція. Зовнішніх скриптів і телеметрії немає. Відкрийте index.html із розпакованої папки; якщо політики браузера забороняють локальні файли, використайте свій локальний сервер розробки. Код перевірено в DOM-середовищі, а не через production HTTP-маршрут.

Джерела:[2] web.dev

У доданій функціональній перевірці всі три режими завершили 10 000 елементів із сумою 2364371375. Нативний yield і примусова гілка таймера виконувалися у Chromium 144.0.7559.96. Запланована тестова дія високого пріоритету перевірила Ping і скасування; некоректний обсяг роботи було відхилено. Це синтетична перевірка правильності, а не польова вибірка, вимірювання Event Timing чи доказ переваги режиму у вашому застосунку.

Yield — не причина залишати зайву роботу. Якщо кожен ввід повторно обробляє весь набір даних, спочатку перевірте, чи можна отримати той самий результат із меншими обчисленнями. Коли переважає одна неподільна операція, worker може бути доречнішим за дедалі дрібніші частини навколо неї. Worker не працює з DOM напряму; передавання даних і подальше оновлення головного потоку все одно потрібно спроєктувати.

Джерела:[8] MDN Web Docs

Джерела:[3] web.dev[8] MDN Web Docs[9] Chrome for Developers

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

Оптимізація може перенести нестабільність в інше місце. Якщо відкладений результат розгортає панель, перевірте зарезервоване місце та кінцевий фокус. Несподівані зсуви розібрано в гайді з CLS, а запізнілий основний вміст — у гайді з LCP. Це окремі перевірки: менший INP не підтверджує їх успішність.

Я б не приймав скриншот меншого числа як критерій випуску. Збережіть разом базовий trace, змінену збірку, точний сценарій та очікуваний результат. Почніть із повторних парних запусків за сталих умов: наприклад, п’ять базових і п’ять змінених як робочу серію, а не доказ статистичної достовірності. Запишіть розкид, а не тільки типовий результат; розбіжні спроби потрібно пояснити, а не видалити.

Не усереднюйте перцентилі маршрутів, щоб отримати нібито перцентиль сайту, і не називайте найдовший із кількох ручних кліків production-розподілом INP. Збережіть у задачі рівень вимірювання: одна відтворена взаємодія, польова група сторінок чи звіт origin. Порівняння корисне лише за узгодженого охоплення.

Наступну перевірку почніть з одного trace проблемної дії та назви складової, на яку можете вплинути. Скорочуйте або переплановуйте лише роботу, підтверджену доказами. Виправлення завершене тоді, коли відгук придатний, операція правильна, а відповідні вимірювання після випуску підтверджують зміну, — не тоді, коли раніше з’явився спінер.