Core Web Vitals у 2026: що реально впливає на конверсію та як це виправити

01 Коротко: що важливо знати

• Core Web Vitals (CWV) — три метрики реального досвіду користувача: завантаження (LCP), відгук на дії (INP) і візуальна стабільність (CLS).
• Пороги «добре»: LCP до 2,5 с, INP до 200 мс, CLS до 0,1. Оцінюють за 75-м перцентилем реальних візитів, окремо для мобільних і десктопів.
• INP замінив FID у березні 2024 року. Якщо ваш аудит досі згадує FID, він застарів.
• Бал Lighthouse ≠ CWV. Lighthouse — лабораторний тест. Google оцінює польові дані (CrUX), тобто те, що бачать реальні люди.
• Для SEO CWV — один із сигналів, не головний. Релевантність і якість контенту сильніші. Зате для конверсії швидкість працює напряму.

02 Що таке Core Web Vitals

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

Сторінка «проходить» CWV, коли усі три метрики в зеленій зоні для 75% реальних візитів. Мобільні й десктопні дані рахуються окремо, і саме мобільні зазвичай підводять.

Чим INP відрізняється від FID

FID вимірював лише затримку першої взаємодії. INP дивиться на всі взаємодії за візит і бере одну з найповільніших. Тому сайти, які «проходили» FID, часто провалюють INP: меню, фільтри каталогу, кошик і форми вимагають виконання важкого JavaScript знову і знову.

03 Чи впливають Core Web Vitals на SEO у 2026

Так, але реалістично.

• Google використовує досвід сторінки (page experience) як один із сигналів ранжування. Він працює як «тайбрейкер»: за однакової релевантності виграють швидші сторінки.
• Швидкість не компенсує слабкий контент. Сторінка з ідеальними метриками, але без відповіді на запит, не потрапить у топ.
• Сильніший непрямий ефект: повільна сторінка → користувач повертається в пошук → погані поведінкові сигнали й менше заявок.
• На конкурентних запитах, де в топі кілька однаково релевантних сайтів, CWV нерідко стає тією дрібницею, що вирішує.

Висновок для бізнесу. Не оптимізуйте заради «зеленого значка». Оптимізуйте заради користувача: SEO-ефект і зростання конверсії прийдуть разом.

04 Як швидкість впливає на конверсію

Зв'язок між швидкістю й грошима підтверджують великі дослідження. Наприклад, спільне дослідження Google та Deloitte «Milliseconds Make Millions» на даних десятків брендів показало, що покращення швидкості мобільного сайту навіть на соті частки секунди пов'язане з ростом конверсії в ритейлі та подорожах.

Як це виглядає на практиці:

1. Мобільний трафік. Людина з телефона на нестабільному 4G не чекатиме. Якщо hero-блок з'являється через 5 секунд, частина відвідувачів піде до конкурента.
2. Форми й оформлення замовлення. Поганий INP означає, що кнопка «Замовити» реагує із запізненням, користувач натискає двічі, отримує дубль або просто йде.
3. Платний трафік. Кожна гривня реклами, що веде на повільну сторінку, окупається гірше. Швидкість знижує вартість заявки.
4. Довіра. Стрибки макета (CLS), через які ви тапаєте не ту кнопку, руйнують відчуття надійності.

05 LCP: як пришвидшити завантаження головного контенту

LCP складається з чотирьох частин. Знайдіть, яка з них «з'їдає» час, і лікуйте саме її.

Що робити

1. Не вантажте hero-зображення ліниво. Це найпоширеніша помилка. Для LCP-елемента ніколи не використовуйте loading="lazy", а, навпаки, підвищуйте пріоритет:

<img
  src="/img/hero-1200.avif"
  srcset="/img/hero-640.avif 640w, /img/hero-1200.avif 1200w, /img/hero-1920.avif 1920w"
  sizes="100vw"
  width="1920" height="1080"
  fetchpriority="high"
  alt="Опис зображення">

2. Сучасні формати й правильні розміри. AVIF або WebP зазвичай легші за JPEG на 25–50% за порівнянної якості. Віддавайте мобільному екрану мобільний файл через srcset та sizes.

3. Прибрати блокування рендерингу. Критичний CSS для першого екрана вставте інлайном, решту підвантажуйте асинхронно. Скрипти додавайте з defer.

4. Прискорити сервер. Цільовий TTFB на кеші: до 600–800 мс на мобільному. Допомагають повний кеш сторінок, CDN, актуальна версія PHP з OPcache, оптимізація запитів до БД.

5. Шрифти. Підключайте лише потрібні накреслення, у форматі WOFF2, з font-display: swap і preload для головного шрифту:

<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>

6. Preconnect до критичних доменів (CDN, шрифти) — економить час на DNS і TLS:

<link rel="preconnect" href="https://cdn.example.com" crossorigin>

7. Відрендерений HTML. Якщо головний контент малюється клієнтським JavaScript, LCP неминуче буде пізнім. Для контентних сторінок обирайте SSR, SSG або стрімінг HTML.

06 INP: як зробити сайт чутливим до кліків

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

Звідки береться поганий INP

• Багато сторонніх скриптів: чати, пікселі, теплові карти, A/B-інструменти.
• Важкі фреймворкові обробники подій, які перемальовують великі частини сторінки.
• Тяжкі обчислення в обробнику кліку (фільтрація каталогу, валідація, розрахунок ціни).
• Забагато DOM-елементів (тисячі вузлів на сторінці).

Що робити

1. Розбивайте довгі завдання. Віддайте керування браузеру між частинами роботи:

async function processItems(items) {
  for (const item of items) {
    handle(item);
    // віддаємо потік, щоб браузер міг відповісти на введення
    if ('scheduler' in window && 'yield' in scheduler) {
      await scheduler.yield();
    } else {
      await new Promise((r) => setTimeout(r, 0));
    }
  }
}

2. Відкладайте сторонні віджети до взаємодії. Чат, пікселі та A/B-інструменти не повинні вантажитися на старті. Підвантажуйте їх після першого скролу, кліку або через requestIdleCallback:

let loaded = false;
function loadChat() {
  if (loaded) return;
  loaded = true;
  const s = document.createElement('script');
  s.src = 'https://widget.example.com/chat.js';
  s.async = true;
  document.head.appendChild(s);
}
['scroll', 'pointerdown', 'keydown'].forEach((e) =>
  window.addEventListener(e, loadChat, { once: true, passive: true })
);

3. Миттєвий візуальний відгук. Після кліку першим кроком показуйте стан завантаження (спінер, «натиснуто»), а важку роботу робіть пізніше. INP вимірює час до наступного кадру, а не до завершення операції.

4. Зменшіть DOM. Віртуалізуйте довгі списки, не рендерьте приховані блоки, спрощуйте вкладеність.

5. Аудит скриптів. Видаліть невикористані бібліотеки й теги. Кожен тег у GTM має чітке бізнес-обґрунтування.

07 CLS: як прибрати стрибки макета

CLS виникає, коли елементи з'являються або змінюють розмір після початкового рендерингу й зсувають решту сторінки.

Виправлення, що закривають більшість випадків:

1. Завжди вказуйте розміри зображень і відео: атрибути width і height або CSS aspect-ratio.
2. Резервуйте місце під динамічні блоки: банери, cookie-плашки, віджети, рекламу, вставки.
3. Налаштуйте шрифти: font-display: swap плюс fallback із підігнаними метриками (size-adjust, ascent-override), щоб заміна шрифту не змінювала висоту рядків.
4. Не вставляйте контент над уже показаним. Нові блоки додавайте нижче або в заздалегідь зарезервоване місце.
5. Анімуйте лише transform та opacity, а не top, height, margin.

.hero-img { aspect-ratio: 16 / 9; width: 100%; height: auto; }
.cookie-banner { position: fixed; bottom: 0; left: 0; right: 0; } /* не зсуває контент */
.ad-slot { min-height: 250px; }

08 Як виміряти Core Web Vitals правильно

Є два типи даних, і їх не слід змішувати.

Практична схема:

1. У Search Console знайдіть групи URL із проблемами.
2. У PageSpeed Insights перегляньте польові дані конкретної сторінки.
3. У Chrome DevTools → Performance запишіть проблемний сценарій і знайдіть довгі завдання та LCP-елемент.
4. Після змін перевіряйте Lighthouse для швидкого зворотного зв'язку, але остаточний висновок робіть за польовими даними через 2–4 тижні.
5. Для власного моніторингу підключіть бібліотеку web-vitals та надсилайте метрики в аналітику:

import { onLCP, onINP, onCLS } from 'web-vitals';

function send(metric) {
  navigator.sendBeacon('/analytics/vitals', JSON.stringify({
    name: metric.name, value: metric.value, id: metric.id, page: location.pathname
  }));
}
onLCP(send); onINP(send); onCLS(send);

Важливо. Lighthouse не вимірює INP напряму, бо в лабораторії немає реальних взаємодій. Тому «100 балів» у Lighthouse можуть співіснувати з поганим INP у реальних користувачів.

09 Пріоритети: з чого починати

Не намагайтеся виправити все одразу. Працюйте за ефектом на бізнес.

1. Сторінки, що приносять гроші: головна, лендинги під рекламу, категорії й картки товарів, сторінки послуг, кошик та оформлення.
2. Мобільна версія. Її частка трафіку зазвичай найбільша, а метрики гірші.
3. LCP — найчастіше найшвидша перемога (зображення, шрифти, кеш).
4. INP — середня складність, потребує розробника й аудиту скриптів.
5. CLS — зазвичай найпростіше, закривається розмірами й резервуванням місця.
6. Не женіться за 100 балами. Зелена зона польових даних важливіша за ідеальний лабораторний бал.

10 Типові помилки агентств

• Звіт «до і після» лише по Lighthouse. Це лабораторія. Клієнту потрібні польові дані та бізнес-результат.
• Початок із CDN та хостингу. Це корисно, але найчастіше ключова проблема в зайвих скриптах, важких зображеннях і блокувальному CSS. Спочатку профілювання, потім інфраструктура.
• Lazy-load на всіх зображеннях, включно з hero. Погіршує LCP.
• Нескінченні плагіни оптимізації. Кілька плагінів кешування й мініфікації конфліктують і створюють нові проблеми.
• Оптимізація однієї сторінки. Google оцінює групи URL. Виправляйте шаблони, а не окремі сторінки.
• Ігнорування мобільних. Тест на швидкому ноутбуці й оптиці нічого не каже про користувача в метро.
• Одноразова оптимізація. Нові віджети, банери й скрипти знову псують метрики. Потрібен моніторинг.

11 Оптимізація за платформами

WordPress

• Легка тема або кастомна замість мультифункціональної.
• Один якісний плагін кешування, а не три.
• Вимкніть невикористані плагіни, стилі та скрипти на сторінках, де вони не потрібні.
• Конвертація зображень у WebP/AVIF, srcset із коробки; перевірте, що hero не отримує lazy-load.
• Шрифти лише локально, без підключення з зовнішніх доменів.

MODX

• Використовуйте кешування чанків і сніпетів (cacheable), вмикайте повний кеш ресурсів.
• Мініфікація та об'єднання CSS/JS за допомогою перевірених розширень або на рівні збирання.
• Генерація адаптивних зображень (pThumb або аналоги) у WebP/AVIF.
• Чистий HTML без зайвої розмітки — природна перевага для LCP.

Laravel / кастомні проєкти

• php artisan optimize, кешування конфігурації, маршрутів і подань; актуальна версія PHP з OPcache.
• Кешування запитів і відповідей (Redis), усунення N+1 через eager loading.
• Для фронтенду на Vue/Nuxt: SSR або SSG для контентних сторінок, розбиття бандлів, defineAsyncComponent для важких компонентів.
• Черги для важких задач, щоб не блокувати відповідь.

OpenCart та інтернет-магазини

• Кеш сторінок і оптимізація каталогу: фільтри та пошук часто головне джерело поганого INP.
• Обмеження кількості модулів на сторінці категорії.
• Оптимізація зображень товарів: мініатюри потрібних розмірів, WebP, width/height.
• Відкладене завантаження віджетів відгуків, чатів та лічильників.

12 Чекліст оптимізації

LCP

• LCP-елемент визначено для кожного ключового шаблону
• Hero-зображення без loading="lazy", з fetchpriority="high"
• AVIF/WebP + srcset та sizes
• Критичний CSS інлайн, решта асинхронно
• Скрипти з defer, немає блокувального JS у <head>
• Шрифти WOFF2, font-display: swap, preload головного
• Preconnect до CDN та інших критичних доменів
• TTFB у нормі, увімкнені кеш сторінок і CDN

INP

• Проведено аудит сторонніх скриптів, зайве видалено
• Чат, піксели й A/B вантажаться після взаємодії
• Довгі завдання розбито, є миттєвий візуальний відгук
• DOM без зайвих вузлів, довгі списки віртуалізовано

CLS

• У всіх зображень і відео задані розміри або aspect-ratio
• Для банерів, реклами й віджетів зарезервоване місце
• Шрифти з fallback і підігнаними метриками
• Анімації лише на transform і opacity

Вимірювання

• Підключено Search Console та перегляд CrUX
• Збираються власні дані через web-vitals
• Заплановано повторну перевірку польових даних через 2–4 тижні

13 Як міряти результат у бізнес-метриках

Технічні бали — це проміжний результат. Для клієнта важливі гроші.

Порівнюйте періоди однакової тривалості та сезонності. Зафіксуйте метрики до змін і дайте даним накопичитися після них мінімум 4 тижні.

Швидкий сайт — це частина воронки продажів, а не технічний фетиш.

14 Часті запитання

Що таке Core Web Vitals простими словами?

Це три показники, які Google використовує, щоб оцінити, наскільки зручно користуватися сторінкою: як швидко з'являється головний контент (LCP), наскільки швидко сторінка реагує на дії (INP) і чи не стрибає макет (CLS).

Які пороги Core Web Vitals у 2026 році?

LCP до 2,5 секунди, INP до 200 мілісекунд, CLS до 0,1. Оцінка рахується за 75-м перцентилем реальних візитів, окремо для мобільних і десктопних.

Чи впливає швидкість сайту на позиції в Google?

Так, як один із багатьох сигналів. Але релевантність і якість контенту важливіші. Найпомітніший ефект швидкості: менше відмов і більше конверсій, що непрямо допомагає й SEO.

Чому в PageSpeed Insights зелений бал, а Search Console показує проблеми?

Бал у PageSpeed це лабораторний тест Lighthouse, а Search Console показує польові дані реальних користувачів. Вони можуть суттєво відрізнятися, особливо за INP і на слабких мобільних пристроях. Орієнтуйтеся на польові дані.

Як швидко видно результат після оптимізації?

Лабораторні покращення видно одразу. Польові дані (CrUX) накопичуються 28 днів, тому повну картину в Search Console варто оцінювати через 3–6 тижнів.

Чи потрібно набирати 100 балів у Lighthouse?

Ні. Мета: зелена зона польових Core Web Vitals на ключових сторінках і зростання бізнес-метрик. Останні бали з 90 до 100 нерідко коштують дорого й майже не дають віддачі.

Що виправляти першим: LCP, INP чи CLS?

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

Чи впливають сторонні скрипти на Core Web Vitals?

Так, і сильно. Чати, піксели, теплові карти та A/B-інструменти найчастіше головна причина поганого INP та пізнього LCP. Відкладайте їх завантаження й видаляйте невикористані.

Чи треба переходити на headless або новий фреймворк заради CWV?

Зазвичай ні. Більшість проблем вирішується оптимізацією зображень, шрифтів, скриптів і кешу на існуючій платформі. Зміна архітектури виправдана, коли ви впираєтеся в обмеження самої платформи.

15 Підсумок

У 2026 році Core Web Vitals це не магія та не заміна якісного контенту, а практичний інструмент для двох речей: щоб сторінка не відштовхувала користувача й щоб реклама та SEO-трафік перетворювалися на заявки.

Порядок дій такий:

1. Подивіться польові дані в Search Console та PageSpeed Insights.
2. Знайдіть слабкі шаблони на сторінках, що приносять гроші.
3. Виправте LCP, потім INP і CLS, починаючи з мобільної версії.
4. Налаштуйте моніторинг і перевіряйте метрики після кожного релізу.
5. Оцінюйте результат за заявками, а не лише за балами.

Потрібен аудит швидкості вашого сайту?

Перевіримо польові дані, знайдемо реальні причини повільної роботи та складемо план виправлень за пріоритетом впливу на заявки. Без «магії» у звітах.

Замовити аудит на crope.pro