Що таке новий показника INP (Interaction To Next Paint): Все, що потрібно знати

Дізнайтеся про новий показник Core Web Vital від Google, що означає хороший INP-результат та як він може покращити вашу загальну SEO-продуктивність. У сфері SEO завжди вистачає акронімів.

Від SEO до FID і INP – це деякі з найпоширеніших термінів, з якими ви зустрінетеся, коли мова йде про швидкість завантаження сторінок.

З'явився новий показник: INP, який розшифровується як Interaction to Next Paint. Він визначає, як сторінка реагує на конкретні дії користувачів і вимірюється за допомогою лабораторних та польових даних Google Chrome.

Що таке Interaction To Next Paint?

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

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

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

Чим INP відрізняється від FID?

Основна відмінність між INP і First Input Delay (FID) полягає в тому, що FID враховує лише першу взаємодію на сторінці. FID вимірює тільки затримку введення і не враховує, скільки часу потрібно браузеру, щоб відповісти на цю взаємодію.

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

• Будь-яке клацання миші на інтерактивному елементі.
• Будь-яке торкання інтерактивного елемента на будь-якому пристрої з сенсорним екраном.
• Натискання клавіші на фізичній або екранній клавіатурі.

Яке значення INP є хорошим?

За даними Google, хороше значення INP становить приблизно 200 мілісекунд або менше. Воно має такі порогові значення:

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

Як вимірюється INP?

Google вимірює INP за допомогою анонімних даних з браузерів Chrome, вибираючи зразок з найдовших взаємодій, що відбуваються під час відвідування сторінки користувачем.

Кожна взаємодія складається з кількох фаз: час представлення, час обробки та затримка введення. Виклик відповідних подій містить загальний час виконання для всіх трьох фаз.

Якщо на сторінці менше ніж 50 взаємодій, INP враховує взаємодію з найгіршою затримкою; якщо більше ніж 50, він ігнорує найдовші взаємодії на кожні 50 взаємодій.

Після того, як користувач залишає сторінку, ці вимірювання надсилаються до звіту Chrome User Experience Report (CrUX), який агрегує дані про продуктивність для надання уявлення про реальні користувацькі досвіди, відомі як польові дані.

Які поширені причини високих значень INP?

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

• Довгі завдання, що блокують основний потік, затримуючи взаємодії користувача.
• Синхронні обробники подій на кліки, як ми бачили у прикладі відео вище.
• Зміни в DOM, що викликають численні перерисування та перерахування, що зазвичай трапляється, коли розмір DOM занадто великий (понад 1,500 HTML елементів).

Як усунути проблеми з INP?

По-перше, ознайомтеся з нашим посібником про вимірювання метрик Core Web Vitals та спробуйте запропоновані там методи усунення несправностей. Якщо це не допомогло визначити, які взаємодії спричиняють високий INP, скористайтеся звітом "Performance" у браузері Chrome (або ще краще, Canary).

• Перейдіть на веб-сторінку, яку хочете проаналізувати.
• Відкрийте DevTools вашого браузера Canary, який не має розширень (зазвичай, натисканням F12 або Ctrl+Shift+I).
• Перейдіть на вкладку Performance.
• Вимкніть кеш у вкладці Network.
• Оберіть мобільний емулятор.
• Натисніть кнопку Record і взаємодійте з елементами сторінки, як зазвичай.
• Зупиніть запис, як тільки захопите цікаву взаємодію.

Після цього, використовуючи меню "slowdown", знизьте продуктивність ЦП у 4 рази, щоб симулювати середні мобільні пристрої, і виберіть мережу 4G, яку використовують 90% мобільних пристроїв на відкритому повітрі. Якщо ви не зміните ці налаштування, симуляція буде виконуватися з потужним ЦП вашого ПК, що не відповідає мобільним пристроям.

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

Ось відео-посібник , що демонструє весь процес. Я настійно рекомендую спробувати це під час прочитання статті, щоб отримати практичний досвід.

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

Якщо розгорнути секцію Interactions, можна побачити детальний розбір довгого завдання, пов'язаного з цією взаємодією, і натискання на URL-адреси скриптів відкриє рядки коду JavaScript, відповідальні за затримку, які ви можете оптимізувати.

Звіт про продуктивність: основний потік Звіт про продуктивність: основний потік Звіт про продуктивність: приклад довгого завдання. Звіт про продуктивність: приклад довгого завдання. На вкладці Source показано затримки, викликані конкретними рядками коду JavaScript. На вкладці Source показано затримки, викликані конкретними рядками коду JavaScript.

Загальна тривалість взаємодії 321 мс складається з:

• Затримка введення: 207 мс.
• Тривалість обробки: 102 мс.
• Затримка представлення: 12 мс.

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

Під довгою червоною смугою можна побачити жовту смугу з позначкою “Evaluate Script,” що вказує на те, що довге завдання було переважно викликано виконанням JavaScript.

На першому знімку часу відстань між (точкою 1) і (точкою 2) є затримкою, викликаною довгим завданням через оцінку скрипта.

Що Таке Оцінка Скриптів?

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

Користувачі можуть взаємодіяти з частково завантаженою сторінкою, поки JavaScript файли ще завантажуються, аналізуються, компілюються та оцінюються.

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

Це забезпечує належну реєстрацію обробника подій і його можливість реагувати на взаємодію.

На знімку екрана (точка 2) затримка в 207 мс, ймовірно, виникла через те, що браузер все ще оцінював скрипт, який містив обробник подій для кліку.

Тут вступає в дію показник Total Blocking Time (TBT), який вимірює загальний час, протягом якого довгі завдання (довші за 50 мс) блокують основний потік, поки сторінка не стане інтерактивною.

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

Хоча це не є частиною основних метрик Core Web Vitals, високий TBT часто корелює з високими показниками INP. Тому для оптимізації INP слід прагнути знизити TBT.

Які JavaScript Викликають Високий TBT?

Аналітичні скрипти, такі як Google Analytics 4 , пікселі відстеження, Google reCaptcha або оголошення AdSense, зазвичай спричиняють довгий час оцінки скриптів, тим самим підвищуючи TBT.

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

Інший важливий момент – при відкладенні скриптів важливо пріоритезувати їх на основі впливу на користувацький досвід. Критично важливі скрипти (наприклад, ті, що необхідні для основних взаємодій) повинні завантажуватися раніше, ніж менш критичні.

Покращення INP – Не Панацея

Варто зазначити, що покращення INP не є панацеєю, яка гарантує миттєвий успіх у SEO .

Це лише один з багатьох аспектів, які потрібно враховувати в рамках комплексу якісних змін, що можуть вплинути на загальну продуктивність SEO.

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