Що вимірює Core Web Vitals?
Ці метрики напряму впливають на SEO-рейтинг, тому що відображають: наскільки швидко сторінка завантажується, наскільки вона чуйна, і наскільки стабільно відображається під час завантаження.
Core Web Vitals - це 3 основні метрики:
| Метрика | Що вимірює | Ідеальне значення |
|---|---|---|
| LCP (Largest Contentful Paint) | Наскільки швидко користувач бачить основний контент (найбільший елемент на екрані) | ≤ 2.5 сек |
| INP (Interaction to Next Paint) (нова метрика з 2024 року, замінює FID) | Наскільки швидко сторінка реагує на дії користувача (клік, введення, тап тощо) | ≤ 200 мс |
| CLS (Cumulative Layout Shift) | Наскільки стабільний макет - чи рухаються елементи під час завантаження | ≤ 0.1 |
Розберемо кожну детально
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).
2. INP - Interaction to Next Paint (нова ключова метрика)
Що вимірює: Скільки часу минає від дії користувача (клік, введення, тап) до моменту, коли інтерфейс візуально відреагував.
Тобто: користувач клікнув кнопку → коли з'явилась реакція (анімація, зміна тексту тощо).
Добре: ≤ 200 мс Середньо: 200-500 мс Погано: > 500 мс
Причини поганого INP:
- довгі JavaScript-задачі (>50 мс);
- синхронні обчислення в головному потоці;
- важкі рендери компонентів React/Vue;
- затримка в обробниках подій.
Як покращити:
- Ділити важкі обчислення на чанки (
setTimeout,requestIdleCallback); - Використовувати Web Workers для CPU-навантажень;
- Оптимізувати ререндери React (мемоізація,
useCallback); - Зменшити bundle (code-splitting, lazy loading).
3. 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) | Агреговані дані від реальних користувачів |
Чому це важливо
Core Web Vitals:
- входять у Google Page Experience (фактор ранжування SEO);
- напряму впливають на утримання користувачів;
- показують, наскільки сайт зручний і чуйний.
Швидкий сайт = вища конверсія, менше відмов, кращі позиції в пошуку.
Підсумок
| Метрика | Що перевіряє | Добре, якщо |
|---|---|---|
| LCP | Коли завантажується основний контент | ≤ 2.5 с |
| INP | Як швидко сайт реагує на дії | ≤ 200 мс |
| CLS | Наскільки стабільно все на екрані | ≤ 0.1 |
Коротка відповідь
Для співбесідиКоротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.