Core Web Vitals

JavaScriptJunior~4 хв читання

Core Web Vitals, це три головні метрики Google, які вимірюють реальний досвід користувача: наскільки швидко сторінка завантажується (LCP), наскільки вона відгукується на дії (INP) і наскільки стабільно відображається під час завантаження (CLS). Ці метрики входять до Google Page Experience, тому напряму впливають на SEO-рейтинг і на те, чи залишиться користувач на сайті.

Теорія

TL;DR

LCP (Largest Contentful Paint): як швидко користувач бачить основний контент. Добре: ≤ 2.5 с.
INP (Interaction to Next Paint): як швидко сторінка реагує на клік, ввід або тап. Добре: ≤ 200 мс. Це нова метрика, що з 2024 року замінила FID.
CLS (Cumulative Layout Shift): наскільки стабільний макет, чи не «стрибають» елементи під час завантаження. Добре: ≤ 0.1.
Метрики збирають двома способами: лабораторно (Lighthouse, DevTools) і з реальних користувачів (Chrome UX Report, бібліотека web-vitals).
Поганий результат майже завжди має технічну причину: важкі зображення, блокуючий JS, довгі задачі в головному потоці, елементи без зарезервованого місця.

Швидкий приклад

javascript

// Вимірюємо три Core Web Vitals на живій сторінці і надсилаємо їх у власну аналітику.
import { onLCP, onINP, onCLS } from 'web-vitals';

function report({ name, value, rating }) {
  // rating приходить як 'good', 'needs-improvement' або 'poor'
  navigator.sendBeacon('/api/vitals', JSON.stringify({ name, value, rating }));
}

onLCP(report); // добре: ≤ 2500 мс
onINP(report); // добре: ≤ 200 мс
onCLS(report); // добре: ≤ 0.1

Три метрики набору

Метрика	Що вимірює	Ідеальне значення
LCP (Largest Contentful Paint)	наскільки швидко користувач бачить основний контент (найбільший елемент на екрані)	≤ 2.5 с
INP (Interaction to Next Paint) (нова метрика з 2024 року, замінює FID)	наскільки швидко сторінка реагує на дії користувача (клік, ввід, тап тощо)	≤ 200 мс
CLS (Cumulative Layout Shift)	наскільки стабільний макет, чи рухаються елементи під час завантаження	≤ 0.1

LCP: Largest Contentful Paint

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

По суті це показник того, коли сторінка візуально «сформувалася».

Добре: ≤ 2.5 с Середньо: від 2.5 до 4 с Погано: > 4 с

Типові причини поганого LCP:

повільний сервер, великий TTFB;
блокуючі CSS і JS;
великі зображення без оптимізації;
відсутність lazy loading;
рендер уже після важких обчислень на JS.

Як покращити:

оптимізувати зображення (next/image, формат WebP, коректні розміри);
налаштувати CDN і кешування;
використовувати preload для шрифтів і критичних ресурсів;
прибрати блокуючий JS із <head> або додати йому defer.

INP: Interaction to Next Paint

Що вимірює: скільки часу минає від дії користувача (клік, ввід, тап) до моменту, коли інтерфейс візуально відреагував.

Тобто: користувач натиснув кнопку, і питання в тому, коли з'явилася реакція (анімація, зміна тексту тощо).

Добре: ≤ 200 мс Середньо: від 200 до 500 мс Погано: > 500 мс

Причини поганого INP:

довгі JavaScript-задачі (понад 50 мс);
синхронні обчислення в головному потоці;
важкий ререндер компонентів React або Vue;
затримка в обробниках подій.

Як покращити:

ділити важкі обчислення на частини (setTimeout, requestIdleCallback);
виносити навантаження на CPU у Web Workers;
оптимізувати ререндери React (мемоїзація, useCallback);
зменшувати bundle (code-splitting, lazy loading).

CLS: Cumulative Layout Shift

Що вимірює: наскільки сильно зсуваються елементи сторінки під час завантаження. Наприклад: підвантажився банер, і весь вміст «поїхав» униз.

Чим більше несподіваного руху, тим гірший UX.

Добре: ≤ 0.1 Середньо: від 0.1 до 0.25 Погано: > 0.25

Причини поганого CLS:

зображення без фіксованих розмірів;
рекламні блоки і вбудовані відео без контейнера;
динамічні шрифти без fallback;
ліниві елементи, вставлені без зарезервованого місця.

Як покращити:

завжди вказувати width і height для <img>;
використовувати aspect-ratio для відео і банерів;
резервувати місце під макет заздалегідь;
завантажувати шрифти з font-display: swap.

Де дивитися ці метрики

Інструмент	Що показує
Lighthouse / PageSpeed Insights	зведення Core Web Vitals плюс рекомендації
Chrome DevTools, вкладка Performance	панель Web Vitals під час запису профілю
Google Search Console	реальні дані по сторінках із Chrome UX Report
web-vitals.js	бібліотека для вимірювання в реальному часі просто на сайті
Chrome UX Report (CrUX)	агреговані дані від реальних користувачів

Важлива різниця: Lighthouse, це лабораторні дані (одна синтетична сесія), а CrUX і web-vitals, це польові дані від справжніх користувачів. Google для ранжування дивиться саме на польові.

Чому це важливо

Core Web Vitals:

входять до Google Page Experience, тобто є фактором ранжування;
напряму впливають на утримання користувачів;
показують, наскільки сайт зручний і чуйний до дій.

Швидкий сайт означає вищу конверсію, менше відмов і кращі позиції в пошуку.

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

Плутати INP і FID. FID вимірював лише затримку до початку обробки першої взаємодії. INP дивиться на всі взаємодії за час життя сторінки і враховує час до наступного відмальовування, тому він суворіший.
Оптимізувати лише лабораторний звіт. 100 балів у Lighthouse на потужному ноутбуці нічого не гарантує: у полі користувачі мають слабші пристрої й гіршу мережу.
Вважати CLS проблемою дизайну, а не коду. Майже кожен зсув, це відсутній width/height, шрифт без fallback або вставка вузла без зарезервованого місця.
Ганятися за загальним «балом продуктивності». Це зважена суміш метрик; ранжування спирається на самі LCP, INP і CLS.
Вважати зсув після кліку помилкою. Зсуви протягом 500 мс після взаємодії користувача не враховуються в CLS, бо їх очікують.

Підсумок

Метрика	Що перевіряє	Добре, якщо
LCP	коли завантажується основний контент	≤ 2.5 с
INP	як швидко сайт реагує на дії	≤ 200 мс
CLS	наскільки стабільно все на екрані	≤ 0.1

Коротка відповідь

Для співбесіди

Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.