Производителността на сайта не е само колко бързо зарежда страницата.
Сайтът може да зарежда бързо и пак да дразни: бутоните реагират бавно, менютата са тромави, а след клик нищо не се случва.
Тук идва Interaction to Next Paint (INP).
От март 2024 г. INP е официална Core Web Vital метрика на мястото на First Input Delay (FID). Причината за смяната: FID мереше само забавянето преди обработката на първото взаимодействие. INP гледа колко отзивчива остава страницата през целия престой на потребителя.
В тази статия: какво е INP, с какво се различава от FID, как се оценяват резултатите и какво да направите за по-отзивчив сайт.
Какво е INP: от концепция до измерване
Interaction to Next Paint измерва колко бързо страницата реагира на взаимодействията на потребителя.
Взаимодействие е:
- кликване на бутон;
- докосване на елемент на тъчскрийн;
- писане на клавиатура;
- отваряне на меню;
- добавяне на продукт в кошницата;
- разгъване на акордеон;
- работа с форма или друг динамичен елемент.
При всяко от тях потребителят очаква да види нещо. Клик върху „Добави в кошницата“ трябва да покаже, че продуктът е добавен.
Ако няколкостотин милисекунди няма нищо, човекът се чуди дали изобщо е натиснал.
INP гледа закъснението на взаимодействията през целия престой, не само първото. Отчита една стойност за цялостната отзивчивост, обикновено по най-бавното наблюдавано взаимодействие, без крайните отклонения.
По-нисък INP значи по-бърза реакция.
Защо това има значение?
→ Клиент намира продукт и кликва Добави в кошницата.
→ Бутонът не прави нищо.
→ Клиентът кликва пак.
→ Пак нищо.
→ След няколко секунди кошницата се обновява и се оказва, че и двете кликвания са минали.
Лошо изживяване, макар сайтът технически да е заредил бързо.
INP улавя точно този тип проблеми.
Данните на Google показват и защо взаимодействията трябва да се мерят през цялото време. Хората прекарват по-голямата част от престоя си на страницата след зареждането. Отзивчивостта не може да се оцени по първите секунди.
Как се измерва INP?
INP се вижда в няколко инструмента:
- PageSpeed Insights
- Chrome DevTools
- Chrome UX Report (CrUX)
- инструменти за Real User Monitoring (RUM)
- други инструменти, които използват данните на Web Vitals
PageSpeed Insights е особено полезен, защото показва реални данни от Chrome User Experience Report, когато има такива за страницата.
За подробен анализ RUM решенията казват кои взаимодействия правят INP лош и при какви условия.
Резултатите за INP: добро, нуждае се от подобрение и слабо
Google оценява INP в три категории:
| INP резултат | Оценка |
|---|---|
| 200 ms или по-малко | Добро |
| Над 200 ms до 500 ms | Нуждае се от подобрение |
| Над 500 ms | Слабо |
До 200 милисекунди страницата е отзивчива. Между 200 и 500 има място за подобрение. Над 500 е слабо: потребителите усещат забавянията.
Core Web Vitals се оценяват по реални данни, на 75-ия персентил от зарежданията, отделно за мобилни и десктоп устройства. Един лабораторен тест не показва как реалните хора усещат сайта.
Защо INP е важен за потребителското изживяване
INP е преди всичко метрика за изживяването. Отзивчивият сайт реагира веднага и предвидимо. Бавният кара хората да се съмняват дали са натиснали, дори когато накрая всичко работи.
Най-важно е при силно интерактивните сайтове:
- онлайн магазини;
- системи за онлайн резервации;
- уеб приложения;
- финансови платформи;
- SaaS продукти;
- сложни форми;
- сайтове с филтри, инструменти за търсене и динамични интерфейси.
По-добър INP значи по-гладко изживяване, а оттам и по-добра ангажираност и конверсии.
Влияе ли INP на SEO?
Тук трябва точност. INP е една от Core Web Vitals метриките, които са част от сигналите на Google за изживяване на страницата. Но добър INP не гарантира по-високи позиции.
SEO зависи от много фактори: релевантност, качество на съдържанието, линкове, техническа достъпност, изживяване и други сигнали.
Практическият извод: подобрявайте INP заради удобството и изживяването. SEO ползата е бонус в рамките на цялата стратегия.
INP срещу First Input Delay (FID)
И двете мерят отзивчивост, но по различен начин.
First Input Delay измерваше само забавянето, преди браузърът да започне да обработва първото взаимодействие.
INP наблюдава взаимодействията през целия престой и мери колко бързо страницата реагира с визуално обновяване. Затова е много по-пълна мярка за реалната отзивчивост.
Пример: потребител влиза в онлайн магазин, кликва менюто веднага след зареждане и сайтът реагира бързо. FID казва, че първото взаимодействие е било бързо. И толкова.
Но какво, ако после потребителят:
- приложи филтър за продукти;
- отвори продуктова галерия;
- промени количество;
- добави артикул в кошницата;
- отвори формата за поръчка;
и всичко това е бавно?
FID не вижда нищо от това. INP е направена точно за него.
Как да подобрите INP резултата си
Няма една универсална оптимизация. Първо намерете кои взаимодействия са бавни и защо.
Google препоръчва да тръгнете от реалните данни, после да възпроизведете проблемните взаимодействия в Chrome DevTools и чак тогава да оптимизирате конкретната част.
1. Разбийте дългите JavaScript задачи
Дългите JavaScript задачи блокират основната нишка на браузъра. Докато тя е заета, взаимодействията чакат.
Разбийте големите задачи на по-малки части, за да може браузърът да обработи входа по-рано.
Забавянето на входа пада, интерфейсът става осезаемо по-отзивчив.
2. Намалете излишния JavaScript
Съвременните сайтове товарят JavaScript за всичко: анимации, тракинг, менюта, филтри, динамично съдържание.
Не всичко е нужно.
Махнете неизползваните скриптове, орежете кода от трети страни и не прехвърляйте излишна обработка на клиента. По-малко работа за браузъра.
Особено важно при сложни сайтове и e-commerce платформи.
3. Оптимизирайте обработчиците на събития
При клик, докосване или друго взаимодействие обработчиците на събития може да изпълняват цяла серия операции.
Ако тя е дълга, взаимодействието е бавно.
Прегледайте кода зад важните взаимодействия: излишни изчисления, прекомерна манипулация на DOM, други скъпи операции.
Колкото по-малко работа преди визуалната обратна връзка, толкова по-добре.
4. Намалете забавянето на входа
INP включва и времето, което браузърът чака, преди изобщо да започне да обработва взаимодействието.
Честата причина е заета основна нишка с други JavaScript задачи.
По-малко дълги задачи и по-малко излишен JavaScript значи по-бърза реакция.
5. Намалете големите обновявания при рендиране
След обработката браузърът трябва да рендира и покаже резултата.
Големите или сложни обновявания удължават това време.
Взаимодействие, което преизгражда голяма част от страницата, е много по-бавно от такова, което обновява един малък елемент.
Google съветва да избягвате големите обновявания при рендиране и ненужно сложните оформления.
6. Поддържайте DOM управляем
Голям или сложен Document Object Model (DOM) значи повече работа при всяко рендиране на промени.
Личи си най-вече когато взаимодействията обновяват големи части от страницата.
По-малко излишни DOM елементи и по-проста структура значи по-малко рендиране и по-добра отзивчивост.
7. Обърнете внимание на рендирането от страна на клиента
Сайтове, които генерират много HTML с JavaScript в браузъра, плащат допълнително за обработка и рендиране.
Само по себе си това не е проблем. Но големи обеми HTML в отговор на взаимодействие забавят следващия кадър.
Ако сайтът ви разчита силно на рендиране от страна на клиента, гледайте тук при слаб INP.
8. Тествайте взаимодействията, които имат значение
Не оптимизирайте по един резултат от PageSpeed Insights. Мислете за действията, които са важни за потребителите ви. За онлайн магазин:
- отваряне на навигационното меню;
- използване на продуктови филтри;
- промяна на количествата;
- добавяне на продукти в кошницата;
- отваряне на продуктова галерия;
- прилагане на кодове за отстъпка;
- преминаване през процеса на поръчка.
Тествайте ги и търсете забавяния. Целта не е по-добро число, а сайт, който се усеща по-бърз.
Как да диагностицирате проблеми с INP
Добрата оптимизация тръгва от реалните данни. При достатъчно трафик за Chrome UX Report PageSpeed Insights показва Core Web Vitals от реални потребители.
За подробности Real User Monitoring дава контекст:
- кое взаимодействие е причинило слабия INP;
- дали се е случило по време на или след зареждането на страницата;
- какъв вид взаимодействие е било;
- коя страница е засегната;
- какво устройство или среда е използвал потребителят.
Щом знаете проблемното взаимодействие, възпроизведете го в Chrome DevTools. Там виждате какво става в основната нишка и кой JavaScript или рендиране бави.
Реални данни плюс лабораторен тест е много по-добре от оптимизация на сляпо.
INP е повече от скорост на зареждане
INP променя начина, по който мислим за производителността.
Една страница може да има:
- бързо зареждане;
- добър LCP;
- добър CLS;
и пак да дразни, ако интерактивните ѝ елементи са бавни.
Затова работата по производителността не спира при зареждането. Бързият сайт е отзивчив и когато го ползвате.
В заключение
Interaction to Next Paint дава по-широка картина за отзивчивостта от метриката, която замени.
Не само първото взаимодействие, а целият престой. Затова е особено полезна за съвременните, силно интерактивни сайтове.
Не гледайте на INP като на поредното число за подобряване. Гледайте на нея като на начин да разберете как реалните хора усещат сайта ви.
Тръгнете от реалните данни, намерете проблемните взаимодействия, възпроизведете ги в контролирана среда и оптимизирайте JavaScript кода и рендирането под тях.
Сайт, който реагира бързо, е по-лесен, по-надежден и по-професионален. Това е смисълът на добрата уеб производителност.
