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 як конкурентну перевагу, і саме воно зазвичай і є реальним блокером.
М’які переходи: зміна, яка стосується односторінкових застосунків
У кожному SPA є давня прогалина у вимірюванні. Історично INP міряли за весь час життя сторінки, тому застосунок, у якому користувач проходить вісім екранів без повного перезавантаження, звітує одним значенням INP на всі вісім. Повільна взаємодія на шостому екрані усереднюється разом зі швидкими, і число не підказує, куди дивитися.
Chrome працював над цим через серію origin trials, і згідно з документацією Chrome про вимірювання м’яких переходів типи записів soft-navigation та interaction-contentful-paint постачаються без прапорця починаючи з Chrome 151. Практичний ефект у тому, що INP можна нарізати по кожному м’якому переходу, і SPA нарешті може віднести погану взаємодію до конкретного екрана, а не до застосунку загалом.
Якщо у вас односторінковий застосунок, чесне очікування таке: щойно ви побачите 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-задачу з зеленим показником у результаті. Виміряйте польові дані для сторінок, які беруть гроші, знайдіть дві-три повільні взаємодії, заразом полагодьте головне зображення і перевірте зміну проти контрольної групи. Коли ми робимо інтернет-магазини і посадкові сторінки, бюджет взаємодії є проєктним обмеженням із першого шаблону, а не знахідкою аудиту через пів року після запуску, бо вбудовувати чуйність у готовий фронтенд – це дорога версія цього ж проєкту.
