Core Web Vitals: що це, LCP, INP і CLS простими словами

Core Web Vitals — це три метрики, якими Google вимірює реальний досвід користувачів на сторінці: Largest Contentful Paint (LCP) — швидкість завантаження основного контенту, Interaction to Next Paint (INP) — швидкість реакції на дії та Cumulative Layout Shift (CLS) — візуальна стабільність. Сторінка проходить оцінку, коли щонайменше 75% реальних візитів мають «добрий» результат за всіма трьома.

У цьому посібнику пояснюємо, що саме вимірює кожна метрика, звідки беруться цифри, чому оцінка в PageSpeed Insights часто не збігається зі звітом Search Console і які виправлення справді працюють. А ще чесно відповідаємо на головне питання: наскільки Core Web Vitals впливають на позиції.

Що таке Core Web Vitals?

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

Набір змінювався один раз. У березні 2024 року INP замінив First Input Delay (FID). FID враховував лише затримку перед обробкою першої взаємодії, а INP аналізує затримки всіх взаємодій протягом візиту і показує одну з найповільніших. Якщо стаття чи сервіс досі пишуть про FID, інформація застаріла.

Які порогові значення Core Web Vitals?

Google публікує три діапазони для кожної метрики. Мета — «добре» за всіма метриками і на мобільних, і на десктопі.

Що означає «75-й перцентиль»?

Google оцінює кожну метрику на 75-му перцентилі завантажень сторінки, окремо для мобільних і десктопів. На практиці це означає: якщо 75% візитів мають LCP до 2,5 секунди, сторінка отримує «добре» за LCP. Решта 25% можуть бути повільнішими, і оцінка від цього не провалиться.

З цього випливають два висновки. По-перше, швидкий тест на офісному Wi-Fi мало що доводить: результат визначає найповільніша чверть користувачів — часто на бюджетних Android-смартфонах і мобільному інтернеті. По-друге, середні значення приховують проблеми. Сторінка із середнім LCP 1,8 секунди все одно може не пройти оцінку, якщо значна частина відвідувачів заходить через повільне зʼєднання. Тому ставте питання «чи добре на p75 на мобільних?», а не «чи швидко на моєму ноутбуці?».

Польові й лабораторні дані: чому оцінки не збігаються?

Це найчастіша причина плутанини, тож варто розібратися точно.

Польові дані (field data, RUM) збираються з реальних користувачів Chrome. Публічне джерело Google — Chrome UX Report (CrUX), який агрегує дані за останні 28 днів. Саме польові дані Google використовує для оцінки Core Web Vitals, і саме їх показує Search Console.

Лабораторні дані (lab data) — це одне змодельоване завантаження, зазвичай у Lighthouse, з фіксованим пристроєм і мережею. Вони відтворювані й зручні для налагодження, але Google оцінює не їх.

Практичне правило: польові дані показують, що виправляти, і підтверджують, що проблему усунуто; лабораторні — пояснюють, чому так відбувається, і дають змогу перевірити зміну до релізу. Оцінка Lighthouse 95 при провальних польових даних означає, що реальним користувачам гірше, ніж у симуляції, а не що Google помиляється.

Як перевірити Core Web Vitals і швидкість завантаження сайту?

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

• Google Search Console → звіт «Core Web Vitals». Групує схожі URL і показує, скільки з них мають статус «добре», «потребує покращення» чи «погано», окремо для мобільних і десктопів. Починайте звідси. Звіт спирається на дані CrUX, тож для сайтів із невеликим трафіком може зʼявлятися «недостатньо даних».
• PageSpeed Insights (pagespeed.web.dev). Верхній блок — польові дані CrUX для URL (або для всього домену, якщо трафіку на сторінку замало); нижній — лабораторний прогін Lighthouse із діагностикою.
• CrUX API, CrUX Vis і BigQuery. Для історичних трендів і порівняння з конкурентами.
• Chrome DevTools → панель Performance. Показує LCP, INP і CLS наживо під час взаємодії зі сторінкою і дає змогу записати трасування, щоб побачити, який скрипт блокує реакцію.
• JavaScript-бібліотека web-vitals. Надсилає метрики ваших відвідувачів в аналітику разом з атрибуцією (який елемент став LCP, яка взаємодія була повільною). Так ви отримуєте польові дані навіть для сторінок, яких немає в CrUX.

Робочий алгоритм: відкрийте звіт у Search Console, оберіть найгіршу групу URL на мобільних, перевірте типову сторінку в PageSpeed Insights, відтворіть проблему в DevTools і виправте її.

Чому LCP поганий і як його покращити?

LCP-елементом зазвичай є зображення (банер, фото товару) або великий текстовий блок. Google розкладає LCP на чотири складники: час до першого байта (TTFB), затримку початку завантаження ресурсу, тривалість завантаження ресурсу і затримку відмальовування елемента. Спершу зʼясуйте, яка частина найбільша, і лише потім змінюйте код.

Типові рішення:

• Зробіть LCP-зображення видимим для браузера якомога раніше. Воно має бути в початковому HTML як <img> з src, а не вставлятися JavaScript-ом чи задаватися CSS-фоном.
• Ніколи не застосовуйте lazy loading до LCP-зображення і підвищте його пріоритет:

<img src="/images/hero-1200.avif"
     srcset="/images/hero-800.avif 800w, /images/hero-1200.avif 1200w"
     sizes="100vw" width="1200" height="600"
     alt="Панель звіту SEO-аудиту"
     fetchpriority="high">

• Зменште TTFB: кешування, CDN, серверний рендеринг або статична генерація замість побудови основного контенту в браузері.
• Віддавайте легші зображення: сучасні формати (AVIF, WebP), правильні розміри через srcset, стиснення.
• Приберіть ресурси, що блокують рендеринг: вбудуйте критичний CSS, відкладіть некритичний JavaScript, уникайте ланцюжків редиректів перед завантаженням сторінки.

Чому INP поганий і як його покращити?

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

Типові рішення:

• Розбивайте довгі задачі (усе, що довше за 50 мс). Між частинами роботи віддавайте керування браузеру, щоб він встиг відреагувати на користувача:

button.addEventListener('click', async () => {
  showSpinner();              // спершу візуальний відгук
  await scheduler.yield();    // даємо браузеру відмалювати кадр (запасний варіант: setTimeout)
  runExpensiveFilter();
});

• Проведіть ревізію сторонніх скриптів: онлайн-чати, менеджери тегів, A/B-тести й рекламні скрипти — часті винуватці. Приберіть непотрібне, решту завантажуйте пізніше.
• Робіть менше роботи на кожну взаємодію: debounce для обробників введення, без перерендерингу всієї сторінки через дрібну зміну стану, помірний розмір DOM.
• Уникайте layout thrashing: читання властивостей макета (наприклад, offsetHeight) одразу після зміни стилів змушує браузер робити зайві синхронні перерахунки.

Лабораторні інструменти не клікають за вас, тому проблеми з INP підтверджуйте польовими даними або взаємодією зі сторінкою в DevTools.

Чому CLS поганий і як його покращити?

CLS зростає щоразу, коли видимий контент зсувається без дії користувача: зображення завантажується без зарезервованого місця, cookie-банер зсуває сторінку вниз або вебшрифт підміняється шрифтом з іншими метриками.

Типові рішення:

• Завжди вказуйте width і height (або CSS aspect-ratio) для зображень, відео та iframe, щоб браузер зарезервував місце.
• Резервуйте місце під рекламу, вбудовані віджети та блоки, що підвантажуються пізніше, — контейнером із фіксованою мінімальною висотою.
• Не вставляйте контент над наявним, якщо це не реакція на дію користувача. Банери показуйте поверх сторінки, а не зсуваючи макет.
• Стабілізуйте шрифти: preload ключових шрифтів, font-display і резервний шрифт з підібраними метриками (size-adjust).
• Анімуйте через transform, а не через top чи height, які викликають зсуви.
• Зберігайте сумісність зі збереженням сторінки в back/forward cache (bfcache) — тоді повернення «назад» миттєве і стабільне.

Виправлення Core Web Vitals: зведена таблиця

Наскільки Core Web Vitals впливають на SEO?

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

На практиці Core Web Vitals працюють як додатковий аргумент на користь сторінки, коли кілька результатів однаково релевантні й надійні. Перейти з «погано» в «добре» варто; а от гонитва за ідеальними 100 балами Lighthouse на сторінках, які вже проходять оцінку, рідко щось змінює в позиціях.

Сильніший аргумент — бізнесовий. Повільні сторінки, які стрибають і погано реагують, втрачають відвідувачів і конверсії незалежно від позицій. Тому Core Web Vitals є в кожному серйозному технічному SEO-аудиті — не як головний важіль ранжування, а як вимірювана частина досвіду, який бачать і користувачі, і пошуковики.

Чи впливають Core Web Vitals на AI Overviews?

Google не описує Core Web Vitals як окремий фактор для AI-функцій. AI Overviews і AI Mode спираються на сторінки, які проіндексовані й можуть показуватися в Пошуку, тож діють ті самі основи: сторінка має бути доступною для сканування, індексованою та корисною. Швидка сторінка — просто на одну причину менше, щоб користувач пішов.

З чого почати оптимізацію Core Web Vitals

1. Спершу подивіться на польові дані. Якщо Search Console і PageSpeed Insights показують «добре» на мобільних, швидкість, імовірно, не головна SEO-проблема вашого сайту.
2. Виправляйте шаблони, а не окремі URL. Search Console групує схожі сторінки: одна правка шаблону картки товару чи статті може покращити тисячі URL.
3. Починайте з «погано» на мобільних і на шаблонах із найбільшим трафіком. Саме там користувачі й дохід.
4. Запустіть перевірку і зачекайте. Після релізу натисніть «Перевірити виправлення» в Search Console і врахуйте, що CrUX оновиться протягом до 28 днів.
5. Моніторте через RUM, щоб регресії (новий скрипт, редизайн) виявлялися за кілька днів, а не місяців.

Як Core Web Vitals поєднуються з перевірками індексації, контенту й внутрішньої перелінковки, дивіться в нашому чеклисті SEO-аудиту.

Головне

• Core Web Vitals — це LCP (≤ 2,5 с), INP (≤ 200 мс) і CLS (≤ 0,1) на 75-му перцентилі даних реальних користувачів.
• INP замінив FID у березні 2024 року; лабораторні інструменти наближено оцінюють його через Total Blocking Time.
• Google оцінює польові дані (CrUX), а не бал Lighthouse. Лабораторні дані — для налагодження.
• Виправляйте за шаблонами й метриками: пріоритет LCP-зображення, менше JavaScript у головному потоці, зарезервоване місце для всього, що завантажується пізніше.
• Core Web Vitals — реальний, але помірний сигнал ранжування; релевантність і якість контенту важать більше.

Перевірте Core Web Vitals вашого сайту в контексті

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