Запропонувати правку

Покращити цю статтю

Допрацюйте відповідь до «Core Web Vitals». Ваші зміни проходять модерацію перед публікацією.

Потрібне підтвердження

Контент

Що ви змінюєте

Заголовок (UA)

Коротка відповідь (UA)

Показується над повною відповіддю для швидкого нагадування.

Відповідь (UA)

**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 |

Markdown · перетягуйте зображення · ⌘B / ⌘I шорткати959 слів

Для рев’юера

Примітка для модератора (необов’язково)

Бачить лише модератор. Прискорює рев’ю.