Core Web Vitals 2026: чому INP погіршується і що робити з сайтом

У серпні 2026 року лише 55,6 % сайтів у світі проходили всі три метрики Core Web Vitals. Показник INP, який відповідає за швидкість реакції на дії користувача, знижується вже кілька місяців поспіль: з 87,2 % сайтів із «хорошим» INP у березні до 85,3 % у серпні. У релізі Chrome UX Report Google визнає, що остаточної причини цього падіння поки не має.

Для власника бізнесу це не привід панікувати. Але це гарний привід перевірити, як поводиться ваш сайт на телефоні, і виправити те, що справді впливає на відвідувачів.

55,6 %

сайтів проходять усі три метрики

серпень 2026

85,3 %

сайтів із «хорошим» INP

у березні було 87,2 %

48 %

мобільних сайтів проходять Core Web Vitals

у 2024 році — 44 %

Джерела: Chrome UX Report (серпень 2026), HTTP Archive Web Almanac 2025

Три метрики й пороги, які варто пам’ятати

Core Web Vitals — це три вимірювання користувацького досвіду. Google оцінює їх за 75-м перцентилем реальних відвідувань, окремо для мобільних і десктопів. Сторінка «проходить», якщо всі три показники у зеленій зоні.

Метрика	Що вимірює	«Добре»
LCP (Largest Contentful Paint)	Як швидко з’являється головний елемент сторінки	до 2,5 с
INP (Interaction to Next Paint)	Як швидко сайт реагує на клік, дотик, введення	до 200 мс
CLS (Cumulative Layout Shift)	Чи «стрибає» верстка під час завантаження	до 0,1

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

Що показують дані

Є два незалежні джерела, і вони говорять про одне й те саме з різних боків.

Chrome UX Report (CrUX), серпень 2026. Серед понад 18 мільйонів сайтів «хороший» LCP має 68,1 %, CLS — 81,5 %, INP — 85,3 %. Усі три разом проходять 55,6 %. INP — єдина метрика, яка помітно знижується з початку року.

Web Almanac 2025 від HTTP Archive. Мобільний показник проходження склав 48 % (у 2024-му — 44 %), десктопний — 56 %. Найслабша ланка на мобільних — LCP:

Частка мобільних сайтів із «хорошим» значенням метрики, 2025

2025 2024 (де є дані)

LCP 62 %
INP 77 %

74 %
CLS 81 %
Усі три метрики разом 48 %

44 %

Джерело: HTTP Archive Web Almanac 2025, розділ Performance

Є й практично важлива деталь: головні сторінки гірші за внутрішні — 45 % проти 56 % на мобільних. А на головну нерідко потрапляють саме з реклами та за пошуком назви компанії.

Два джерела не суперечать одне одному: Almanac бере дані за 2025 рік, а CrUX показує поточний щомісячний зріз. Чисельно вони відрізняються через різні вибірки та методику, тому порівнювати їх «цифра в цифру» не варто.

Чи це впливає на позиції в Google

Чесна відповідь: частково і не напряму. Google не обіцяє, що хороші показники піднімуть сайт у видачі. Він «наполегливо рекомендує» добре проходити Core Web Vitals і розглядає їх як частину набору сигналів про зручність сторінки, а не як окремий важіль впливу.

Тому думати про швидкість варто насамперед як про зручність для людини. Повільний сайт гірше конвертує навіть тоді, коли позиції в нього непогані.

LCP: майже завжди це картинка

За даними Web Almanac, на мобільних сторінках найбільшим елементом є зображення у 76 % випадків (на десктопі — 85 %). Формат цих картинок — здебільшого старі JPG і PNG, а сучасного WebP небагато:

Формати зображень, що стають LCP-елементом (мобільні)

JPG 57 %
PNG 26 %
WebP 11 %

Джерело: HTTP Archive Web Almanac 2025

Звідси практичний порядок дій. Він збігається з рекомендаціями web.dev:

Не завантажуйте головне зображення ліниво. Атрибут loading="lazy" на першому екрані відкладає запит і погіршує LCP.
Дайте браузеру пріоритет. Для одного-двох головних зображень додайте fetchpriority="high". Якщо позначити так десять картинок, ефекту не буде.
Робіть картинку видимою в HTML. Якщо її підставляє JavaScript або вона лише у CSS, браузер дізнається про неї пізно.
Стискайте й підбирайте розмір. WebP або AVIF у розмірі, який справді показується, а не оригінал із камери на 5000 пікселів.
Подивіться, з чого складається LCP. Від цього залежить, куди вкладати зусилля.

З чого складається LCP у добре налаштованої сторінки (орієнтир, не жорстка норма)

Відповідь сервера (TTFB) ≈ 40 %
Завантаження ресурсу ≈ 40 %
Затримка до початку завантаження до 10 %
Затримка перед відмальовуванням до 10 %

Джерело: web.dev, Optimize Largest Contentful Paint

INP: чому він падає і що з цим робити

INP складається з трьох частин, і кожну можна прискорити окремо:

Із чого складається одна взаємодія

1

Затримка введення

від дії користувача до початку обробки
2

Обробка

виконання обробників подій
3

Відмальовування

поява наступного кадру з результатом

Джерело: web.dev, Optimize Interaction to Next Paint

Типові причини поганого INP, за web.dev:

довгі задачі в головному потоці, найчастіше через розбір і виконання скриптів під час завантаження;
«важкі» обробники подій, які роблять більше, ніж потрібно до наступного кадру;
примусові перерахунки верстки;
велика кількість елементів DOM;
відмальовування великого обсягу HTML на стороні клієнта через JavaScript.

Що з цим робити на практиці:

Розбивайте довгі задачі. Віддавайте управління браузеру між частинами роботи, навіть простим setTimeout. У web.dev про це сказано прямо: краще віддавати управління без розбору, ніж не віддавати зовсім.
Залишайте в обробнику кліку лише те, що змінює картинку на екрані. Решту відкладайте.
Зменшуйте DOM. Складну сторінку з тисячами елементів оновлювати завжди дорожче.
Виносьте важкі обчислення у веб-воркери.
Використовуйте content-visibility, щоб браузер не відмальовував те, що поза екраном.

І окрема порада від нас, а не з документації: переглянте, які сторонні скрипти ви підключили. Віджети чатів, піксели, лічильники, збирачі аналітики — кожен додає роботу головному потоку. Прибрати зайве часто дешевше, ніж оптимізувати власний код.

CLS: найдешевше виправлення

За Web Almanac, більшість сторінок не вказує розміри зображень. Вказати width і height або співвідношення сторін — один з найпростіших способів прибрати «стрибки» верстки. Так само на більшості сторінок немає підказок для завантаження шрифтів (preload, preconnect), хоча вони допомагають і LCP.

Як перевірити свій сайт за 10 хвилин

Відкрийте PageSpeed Insights і вставте адресу головної та однієї-двох внутрішніх сторінок.
Дивіться на блок з даними реальних користувачів (CrUX за останні 28 днів). Саме вони вирішують, чи проходить сторінка Core Web Vitals. Лабораторний тест Lighthouse корисний для пошуку причин, але не є оцінкою.
Перемкніть вкладку на мобільні — вони гірші.
Якщо даних реальних користувачів немає, PageSpeed Insights покаже дані по всьому сайту. Якщо й їх немає, трафіку поки недостатньо для оцінки, дивіться лабораторні результати.
Запишіть три значення (LCP, INP, CLS) і повторіть перевірку через місяць.

Що робити далі

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

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

Автор: Сергій Філатьєв — засновник авторської студії Veb-Dev.