Взаимодействие със следващото боядисване (INP)

„Взаимодействие до следващо рисуване“ измерва колко бързо страницата реагира визуално на потребителския вход, отчитайки стойност, представителна за най-лошите латентности при взаимодействие, наблюдавани по време на посещение. Тя замени „Забавяне при първо въвеждане“ като метрика за бърза реакция на Core Web Vitals през март 2024 г. и промяната беше значителна: докато по-старата мярка улавяше само забавянето преди започване на обработката при първото взаимодействие, тази измерва пълната продължителност от въвеждането през обработката до следващия кадър, който се рисува, във всички взаимодействия в сесията.

Тази разлика е от значение, защото по-ранният показател е бил в полза на много сайтове. Една страница може да регистрира отлично забавяне при първо въвеждане, като същевременно остава бавна през цялото време, защото измерването игнорира колко време е необходимо на обработчика на събития да се изпълни и колко време е необходимо на браузъра да изобрази резултата, както и защото е разглеждало само едно взаимодействие. Сайтовете, които са изглеждали адаптивни при стария показател, често не са такива при новия, особено приложенията с една страница и всеки интерфейс с тежка клиентска логика.

Отчетената стойност е извлечена от най-дългите наблюдавани взаимодействия, с отклонение за отклонения на страници с много взаимодействия, а публикуваният от Google праг третира 200 милисекунди или по-малко като добри на седемдесет и петия персентил от реалните потребителски изживявания. Тъй като обхваща целия път от въвеждането до рисуването, лошите резултати могат да възникнат от няколко точки: дълги задачи в основната нишка, блокиращи браузъра да обработва събитието, обработчици на събития, извършващи прекомерна работа синхронно, „трешинг“ на оформлението, причинен от стилове на четене и писане по преплетен начин, и скъпо рендиране след промени в състоянието.

Диагнозата обикновено сочи към изпълнението на JavaScript, а не към мрежовите условия, което отличава тази метрика от мерките за зареждане. Често срещани причини включват големи монолитни пакети, изпълняващи се в основната нишка, скриптове на трети страни, изпълняващи произволна работа по време на взаимодействие, повторни рендери на рамката, които докосват много по-голяма част от дървото, отколкото изисква промяната, и обработчици, извършващи синхронни изчисления, които биха могли да бъдат отложени или преместени извън основната нишка. Дългите задачи са основният механизъм в повечето случаи, тъй като браузърът не може да реагира на вход, докато задачата се изпълнява.

Корекциите следват диагнозата. Разделянето на дълги задачи на по-малки части с изрично предаване позволява на браузъра да обработва входните данни между тях. Отлагането на несъществена работа до визуалната актуализация, така че потребителят да види отговор веднага, адресира най-често срещания модел. Намаляването на количеството изпратен JavaScript, одитирането на скриптове на трети страни за разходи за главния поток, виртуализирането на дълги списъци и преместването на тежки изчисления към worker - всяко от тях адресира специфични причини. Осигуряването на незабавна визуална обратна връзка за бавни операции не подобрява измерената стойност, но променя начина, по който се възприема забавянето.

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

Тъй като метриката се определя от кода на приложението, а не от доставката на активи, подобряването ѝ обикновено изисква инженерна работа, а не конфигурация. На практика тя се намира на границата между уеб изпълнение намлява разработване на продуктии това е особено важно за интерактивните интерфейси за търговия и резервации, където неотзивчивото филтриране, конфигурация и взаимодействия с количката водят до изоставяне, което се появява в анализите като обикновено отпадане без очевидна причина.