Core Web Vitals: LCP, INP, CLS

Core Web Vitals — це три показники реального досвіду користувача на сторінці, які визначає Google: LCP (швидкість появи головного вмісту), INP (швидкість реакції на дії) і CLS (стрибки елементів під час завантаження). Хороші значення: LCP до 2,5 секунди, INP до 200 мілісекунд, CLS до 0,1.

Простими словами

• LCP (Largest Contentful Paint) — за який час з'являється найбільший елемент екрана. У картці товару це зазвичай головне фото. Орієнтир Google: до 2,5 с від початку завантаження.
• INP (Interaction to Next Paint) — як швидко сторінка реагує на клік чи дотик: додати в кошик, обрати розмір, відкрити фільтр. Орієнтир: до 200 мс.
• CLS (Cumulative Layout Shift) — чи не «стрибає» сторінка, поки вантажиться. Класична біда: кнопка «Купити» зсувається в момент натискання, бо вище підвантажився банер. Орієнтир: до 0,1.

Джерело порогів: Google, Core Web Vitals і web.dev. Сторінка вважається хорошою, якщо всі три показники укладаються в норму для 75-го перцентиля завантажень окремо для мобільних і десктопів (web.dev). Тобто норму має виконувати не середній, а три з чотирьох реальних візитів.

INP став стабільним показником у 2024 році й замінив FID. Сторінка web.dev із цими порогами востаннє оновлювалась 31 жовтня 2024 року; стабільні показники, за її словами, змінюють не частіше разу на рік.

Як міряють: польові і лабораторні дані

Головними є польові дані — вимірювання на справжніх пристроях відвідувачів: звіт Core Web Vitals у Search Console, PageSpeed Insights, Chrome User Experience Report. Лабораторні (Lighthouse) корисні, щоб знайти причину й перевірити виправлення, але їх не замінюють; INP у лабораторії неможливо виміряти, бо немає дій користувача, Lighthouse використовує замінник TBT (web.dev).

Для українського магазину це означає: подивіться звіт у Search Console саме для мобільних, бо більша частина трафіку іде зі смартфонів (див. Мобільний UX).

Як справи в мережі загалом

За Web Almanac 2025 від HTTP Archive (дані CrUX за липень 2025): всі три показники в нормі мали 48% мобільних і 56% десктопних сайтів (у 2024 на мобільних було 44%). Окремо на мобільних: LCP у нормі в 62%, INP у 77%, CLS у 81% сайтів. Найслабше місце — LCP. Головне фото було LCP-елементом на 76% мобільних сторінок. На 16–17% сторінок головне фото вантажиться відкладено (lazy loading), хоча це уповільнює його появу; `fetchpriority="high"` стояв лише на 17% мобільних і 16% десктопних таких зображень (Web Almanac 2025).

Практичний висновок для магазину: перше фото товару не слід вантажити відкладено; решту фото нижче першого екрана можна.

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

Google пише: Core Web Vitals використовуються системами ранжування, і Google радить прагнути до хороших значень. Водночас хороші оцінки не гарантують високих позицій; релевантність важливіша («Google завжди прагне показати найрелевантніший вміст, навіть якщо досвід сторінки не найкращий»); гнатися за ідеальним результатом лише заради SEO може не варто (Google, page experience). Сильніше швидкість допомагає, коли багато однаково корисних сторінок конкурують за один запит (там само).

Чи впливає на продажі

Тут доказів менше, ніж обіцяють в агентствах. Найвідоміший приклад на web.dev: Rakuten 24. На одній сторінці за місяць A/B-тест показав приріст виручки на відвідувача на 53,37% і конверсії на 33,13%, коли її оптимізували за Core Web Vitals. Обмеження самого кейсу: одна сторінка, один місяць, пишуть власні розробники, немає абсолютних значень і статистичної значущості; у кейсі не вказано дати публікації (web.dev, Rakuten 24). Це приклад того, що швидкість може впливати на продажі, а не гарантована цифра. Українських досліджень з відкритими цифрами немає.

Практичне правило: міряйте на своєму магазині. Візьміть сторінки з поганими показниками, виправте, і порівняйте конверсію на A/B-тесті (A/B-тест). Те, що Rakuten змінив у кейсі, корисно як перелік ідей: прибрав блокуючі рендер скрипти, стиснув і підібрав розміри зображень, відклав завантаження того, що нижче першого екрана, зарезервував місце під зображення через `aspect-ratio` і `min-height`, щоб не було зсувів.

Типові причини поганих показників у магазині

• LCP: важке головне фото без стиснення; воно завантажується відкладено; повільний сервер; блокуючі скрипти.
• INP: тяжкий JavaScript (віджети чату, аналітика, слайдери), який зайнятий, коли людина тисне на кнопку.
• CLS: зображення без заданих розмірів; банери й віджети, що підвантажуються зверху; шрифти, що міняють розміри.

Типові помилки

• Дивитися лише на оцінку в лабораторному тесті, а не на реальних користувачів.
• Гнатися за 100 балами, ігноруючи три порогові значення.
• Виправляти головну сторінку, залишаючи картки товарів і категорії. У Web Almanac 2025 саме головні сторінки були гіршими за внутрішні: у нормі 45% мобільних головних проти 56% внутрішніх сторінок.
• Очікувати стрибка позицій: Google прямо каже, що релевантність важливіша.

FAQ

Що таке Core Web Vitals? Три показники швидкості й стабільності сторінки: LCP, INP, CLS.

Які норми Core Web Vitals? LCP до 2,5 с, INP до 200 мс, CLS до 0,1 для 75% відвідувань.

Чи впливають Core Web Vitals на ранжування? Так, Google використовує їх, але вони не гарантують топ і поступаються релевантності.

Чи впливають вони на конверсію? Є окремі кейси із зростанням (Rakuten 24), але з обмеженнями. Для вашого магазину перевіряйте тестом.

Що таке INP і чим він замінив FID? INP міряє швидкість реакції на всі дії на сторінці, а не лише на першу. У 2024 році він замінив FID.

Пов'язані терміни

• Технічний аудит сайту: що це і що перевіряють
• SEO-аудит інтернет-магазину: що перевіряють і навіщо
• Мобільна версія магазину
• Конверсія інтернет-магазину: що це і як її рахувати
• Що таке A/B-тест і як його провести

Джерела

• Google Search Central, Core Web Vitals — developers.google.com/search/docs/appearance/core-web-vitals
• Google Search Central, Understanding page experience — developers.google.com/search/docs/appearance/page-experience
• web.dev, Web Vitals — web.dev/articles/vitals
• HTTP Archive, Web Almanac 2025: Performance — almanac.httparchive.org/en/2025/performance
• web.dev, Rakuten 24 case study — web.dev/case-studies/rakuten