INP е метрика за пари, не за позиции: какво показват полевите данни от 2025 г.
Почти всеки проект за бързодействие започва с едно и също изречение в заданието: да подобрим Core Web Vitals заради SEO. Това е грешната причина да се прави тази работа и води до грешен план. Като фактор за класиране опитът на страницата е малък допълнителен сигнал сред много други и Google никога не е твърдял друго. Като фактор за приходи публикуваните доказателства са значително по-силни и значително по-рядко обсъждани.
Тук се използват два източника: главата за бързодействие в Web Almanac 2025, която стъпва върху полеви данни от Chrome UX Report за милиони източници, и три казуса, публикувани в web.dev от самите компании. И двата източника са публични, и двата се проверяват, а заедно отговарят на по-полезен въпрос от „ще ни помогне ли да се класираме“.
Къде реално е мрежата
Срезът на CrUX от юли 2025 г. в Almanac дава изходната линия. 48% от сайтовете покриват и трите Core Web Vitals на мобилни устройства и 56% на десктоп. По отделни метрики картината е далеч по-неравна, отколкото подсказва общото число: INP е оценен като добър при 97% от десктоп източниците и при 77% от мобилните.
Прочетени заедно, тези два реда водят до неудобен извод. На десктоп INP на практика е приключен въпрос. Ако екипът върти профилиране на десктоп взаимодействия като приоритетно направление, той работи по онези 3%. Междувременно общите 48% на мобилни се дърпат надолу основно от LCP, а не от INP.
Затова честната формулировка е следната. Ако целта е да покриете оценката Core Web Vitals, вашата пречка е LCP. Ако целта е да спрете да губите пари по взаимодействията, точно INP описва това преживяване. Това са два различни проекта и постоянно се бъркат един с друг.
Трите казуса и какво всъщност измерва всеки от тях
Най-силните налични доказателства за търговския ефект са контролирани тестове, публикувани от самите компании. Три заслужават четене изцяло, а един от тях редовно се цитира грешно.
| Сайт | Метрика, която се е подобрила | Бизнес резултат | Източник |
|---|---|---|---|
| Rakuten 24 | CLS с 92,72%, FID с 7,95%, FCP с 8,45%, TTFB с 18,03%. Не INP | Конверсия +33,13%, приход на посетител +53,37%, средна стойност на поръчка +15,20%, изходи по-малко с 35,12% | казус в web.dev |
| redBus | INP подобрен със 72% | Продажби с 7% повече | казус в web.dev |
| Vodafone | LCP подобрен с 31% | Продажби +8%, дял на запитванията +15%, дял на количките +11% | казус в web.dev |
Редът за Rakuten 24 се нуждае от уговорка, защото се разнася широко като резултат за INP, а не е такъв. Онзи тест беше сплит на 50 на 50 върху една целева страница в продължение на месец и подобри CLS и FID, тоест метриките на онова време. Той е отлично доказателство, че работата по Core Web Vitals се изплаща. Не е доказателство конкретно за INP и който го представя така, не е чел първоизточника.
Още две ограничения си струва да се кажат на глас, преди тези числа да стигнат до презентация. И трите са резултати на отделни компании, на конкретни страници, на конкретни пазари, публикувани от самите компании, тоест с очевиден подбор: никой не публикува оптимизация, която не е дала нищо. И разсейването е огромно, от 7% до 53%, което казва само едно: размерът на ефекта зависи изцяло от това колко зле е бил стартът. Правилната употреба на тези изследвания е потвърждение на посоката, а не прогноза за вашия ръст.
Отделно заслужава внимание инструментът, с който обикновено се започва. Лабораторното изпитание в синтетичен тест изобщо не измерва INP, защото в лабораторията няма човек, който натиска. То дава оценка на времето за отговор въз основа на блокирането на главната нишка и тази оценка може да е зелена на сайт, където реалните потребители всеки ден чакат по половин секунда да се отвори филтър. Единственият източник на истина за INP са полевите данни от реални сесии, ваши собствени или от CrUX.
Защо забавянето при взаимодействие конвертира различно от забавянето при зареждане
LCP и INP се чупят по различен начин и търговската последица не е една и съща.
Бавното зареждане се усеща преди ангажимента. Посетителят не е вложил нищо, затова си тръгва и вие го виждате като отказ. Бавното взаимодействие се усеща след ангажимента. Човекът вече е избрал размер, отворил е филтър, натиснал е „добави в количката“. Намерението вече е формирано и забавянето пада точно върху стъпката, която носи пари. Затова забавянето при взаимодействие се появява в конверсията, а не в броя сесии, и затова екипите, които гледат само трафик, никога не го виждат.
Това обяснява и формата на резултата при redBus. Тяхната поправка не беше пренаписване. Спряха да синхронизират всяко натискане на клавиш в глобалното състояние и започнаха да го правят при загуба на фокус, което намали излишните преизчертавания. Това са няколко дни работа по един компонент и дадоха 72% подобрение на INP и 7% повече продажби. Моделът се обобщава: проблемите с INP обикновено са съсредоточени в две-три взаимодействия, а не разпръснати равномерно по сайта.
Изводът за LCP, по който почти никой не действа
Тъй като именно LCP определя покритието на мобилни устройства, разбивката по елементи в Almanac е най-приложимото число в цялата глава. Изображение е LCP елементът при 85,3% от десктоп страниците и при 76,0% от мобилните, а 57% от тези изображения все още са в JPEG.
Тоест най-големият проблем с бързодействието в мрежата е едно изображение на страница, във формат, за който във всички основни браузъри от години има по-добри алтернативи. Да прехвърлите главното изображение в модерен формат, да го подадете в правилния размер за изгледа, да му вдигнете приоритета при зареждане и да не му слагате отложено зареждане е работа за един следобед, която прави за покритието повече от повечето предложения за преработка на архитектурата.
Причината това да не се случва рядко е техническа. Изображението се качва от маркетолог през административния панел в размера, който е излязъл от графичния редактор, и в процеса няма кой да отговаря за него. Това е дефект на процеса, а не на кода. Въпроса за отговорността разгледахме в материала за Core Web Vitals като конкурентно предимство и обикновено точно той е реалната пречка.
Меките навигации: промяната, която засяга едностраничните приложения
Във всяко едностранично приложение има отдавнашна дупка в измерването. Исторически INP се измерва за целия живот на страницата, така че приложение, в което потребителят минава през осем изгледа без пълно презареждане, отчита една стойност на INP за всичките осем. Бавното взаимодействие на шестия изглед се усреднява заедно с бързите и числото не подсказва къде да се гледа.
Chrome работи по това през поредица от origin trials и според документацията на Chrome за измерване на меки навигации типовете записи soft-navigation и interaction-contentful-paint се доставят без флаг от Chrome 151. Практическият ефект е, че INP може да се нарязва по отделна мека навигация и едностраничното приложение най-сетне може да отнесе лошото взаимодействие към конкретен изглед, а не към приложението като цяло.
Ако поддържате едностранично приложение, честното очакване е следното: щом видите INP както трябва, той ще изглежда по-зле, а не по-добре. Точно така изглежда откриването на проблем, който досега се е губел в усредняването, и това е добър изход.
Как да решите дали работата заслужава бюджет
Работата по бързодействие се конкурира за бюджет с функционалността и обикновено губи, защото се аргументира в милисекунди. Аргументирайте я в същите единици като останалата пътна карта.
| Въпрос | Откъде идва отговорът | Какво прави отговора положителен |
|---|---|---|
| Коя метрика реално се проваля? | Полеви данни от CrUX за вашия източник, отделно по устройства | Поправяйте това, което пада в полето, не това, което маркира лабораторен инструмент |
| Провалът на страниците, които носят пари ли е? | Данни на ниво страница: продукт, количка, плащане | Бавна рекламна страница и бавно плащане не са един и същи проблем |
| Кои взаимодействия са бавни? | Данни за атрибуция от скрипт за полеви измервания | Два-три поименни обработчика, а не обща мудност |
| Колко струва една конверсия? | Финансовият отдел, не аналитиката | Позволява поправката да се изрази в пари, не в милисекунди |
| Може ли да се тества? | Вашата платформа за експерименти | И трите публикувани казуса са направили точно това, затова им се вярва |
Последният ред тежи повече от всички останали заедно. Всяко от трите изследвания по-горе е правило контролирано сравнение. Ако пуснете подобрение на бързодействието и просто отчетете, че после приходите са се вдигнали, сте измерили сезона си, а не работата си.
Къде усилието обикновено се изплаща
- Главното изображение в шаблоните, които носят трафик. Модерен формат, правилни размери, висок приоритет при зареждане, без отложено зареждане. Най-голяма възвръщаемост на вложен час, с голяма разлика.
- Скриптовете на трети страни на интерактивните страници. Мениджърите на тагове, чат джаджите, инструментите за съгласие и топлинните карти се борят за главната нишка точно когато потребителят натиска нещо.
- Двата-трите най-тежки обработчика. Филтрите, броячите за количество, изборът на варианти и търсенето по време на писане са мястото, където на практика се губи INP.
- Слабите устройства, а не вашето. Мобилната разлика по INP живее върху хардуер, какъвто никой в екипа не притежава, затова писахме отделно за скоростта на сайта на слаби устройства.
- Анимацията, която тръгва при взаимодействие. Преход, който изглежда изискано на работна машина, може да добави стотина милисекунди към отговора на телефон от средния клас. Компромисите разгледахме в текста за това кога микроанимациите помагат и кога вредят.
Накратко
Полевите данни за 2025 г. дават 48% покритие на Core Web Vitals на мобилни и 56% на десктоп, като INP е добър при 97% от десктоп източниците и при 77% от мобилните. Десктоп INP на практика е приключен; мобилният INP е реален, но по-тесен проблем от LCP, който всъщност определя покритието на мобилни и който в 85,3% от десктоп случаите е изображение, при това в 57% от случаите все още JPEG. Публикуваните бизнес резултати са истински, но са A/B тестове на отделни компании, а не бенчмаркове: redBus подобри INP със 72% и получи 7% повече продажби, Vodafone подобри LCP с 31% и получи 8%, а широко цитираните числа на Rakuten 24 от +33,13% конверсия и +53,37% приход на посетител идват от тест върху CLS и FID, не върху INP.
Практическият извод е да спрете да поставяте тази работа като SEO задача със зелен показател за резултат. Измерете полевите данни за страниците, които вземат пари, намерете двете-трите бавни взаимодействия, оправете покрай това и главното изображение и проверете промяната срещу контролна група. Когато правим онлайн магазини и целеви страници, бюджетът за взаимодействие е проектно ограничение още от първия шаблон, а не находка от одит половин година след пускането, защото вграждането на отзивчивост в готов фронтенд е скъпата версия на същия проект.
