У кошику порожньо!
З березня 2024 року Google остаточно замінив FID на INP — і якщо ваш сайт налаштований під старі метрики, частина роботи вже не актуальна. Core Web Vitals залишаються сигналом ранжування з 2021 року, але реальний вплив відчувається не у прямому підйомі позицій, а у тому, що поганий досвід стає бар'єром для входу в топ за конкурентними запитами. Цей матеріал — не черговий перелік пунктів, а детальний технічний розбір кожної метрики з причинами, кодом і реальними кейсами.
Якщо потрібна допомога з технічною оптимізацією — команда SEO-Factory проводить аудит у складі SEO-просування сайтів. Актуальні пороги та методологію можна перевірити на офіційному ресурсі: web.dev/articles/vitals.
Зміст
Пороги показників: що вважати нормою
Google оцінює кожну метрику за даними реальних користувачів (CrUX — Chrome User Experience Report) і дивиться на 75-й перцентиль: тобто 75% відвідувань вашого сайту мають потрапляти в зелену зону. Якщо хоча б одна метрика у «жовтій» або «червоній» — сторінка не проходить оцінку Page Experience.
Важливо: якщо у вашому звіті Google Search Console немає даних CrUX (сайт новий або має малий трафік), Google не застосовує Page Experience сигнал до ваших сторінок — але PageSpeed Insights все одно покаже лабораторні дані Lighthouse.
Де перевірити Core Web Vitals
Існує два типи даних: польові (реальні користувачі, CrUX) і лабораторні (Lighthouse, симуляція). Google використовує лише польові дані для ранжування, але лабораторні допомагають відтворити і зафіксувати проблему.
| Інструмент | Тип даних | Коли використовувати |
|---|---|---|
| PageSpeed Insights | Польові + лабораторні | Швидка перевірка конкретної URL |
| Google Search Console (Core Web Vitals) | Польові | Огляд усього сайту, групування URL |
| Chrome DevTools → Performance | Лабораторні | Профілювання конкретних проблем |
| Lighthouse CI | Лабораторні | Автоматизований моніторинг у CI/CD |
| CrUX Dashboard (Looker Studio) | Польові | Аналіз динаміки за 28-денними вікнами |
| WebPageTest | Лабораторні + waterfall | Глибокий аналіз завантаження ресурсів |
Порада: починайте з GSC — він покаже, які шаблони сторінок мають проблеми (продуктові картки, статті, лендинги). PageSpeed Insights показує одну URL за раз, GSC — картину по всьому сайту.
LCP: детальний розбір
Що саме є LCP-елементом
LCP (Largest Contentful Paint) вимірює момент, коли у viewport стає видимим найбільший за площею контентний елемент. Браузер кандидує на роль LCP наступні типи елементів:
- Зображення —
<img>, елемент всередині<picture>, або зображення як CSSbackground-image(лише за певних умов) - Відео-постер — атрибут
posterелемента<video> - Текстові блоки —
<h1>,<p>,<div>з великою кількістю тексту, якщо вони є найбільшими елементами у viewport - SVG, що містить
<image>— нечасто, але враховується
На практиці для більшості комерційних сайтів LCP-елемент — це hero-зображення у верхній частині сторінки. Для блогів — найчастіше перший <h1> або велика ілюстрація статті. Ідентифікувати точний елемент можна через Chrome DevTools: вкладка Performance → після запису сесії знайдіть подію LCP у треку Timings. PageSpeed Insights також підсвічує елемент скриншотом.
LCP > 4 секунди — це не просто погана метрика. Це означає, що користувач чотири секунди дивиться на незавантажену сторінку. За даними Google, 53% мобільних користувачів покидають сайт, якщо завантаження займає більше 3 секунд. Сайт може ранжуватися, але конверсії падають задовго до того, як SEO-метрика стає червоною.
Топ-5 причин поганого LCP та їх виправлення
1. LCP-зображення не має preload у <head>
Браузер не знає про важливість LCP-зображення до того, як розпарсить HTML і знайде тег <img>. Це може займати сотні мілісекунд. Рішення — явний preload:
<link rel="preload" as="image"
href="/hero.webp"
fetchpriority="high">Для адаптивних зображень використовуйте imagesrcset і imagesizes на тому ж тезі preload. Атрибут fetchpriority="high" (підтримується з Chrome 102) додатково піднімає пріоритет у черзі завантаження.
2. Render-blocking ресурси блокують перший рендер
CSS і синхронний JavaScript у <head> блокують парсер. Сторінка не рендериться, поки вони не завантажені і не виконані. Виправлення:
- Критичний CSS (above-the-fold стилі) — інлайнуйте безпосередньо у
<head> - Некритичний CSS — відкладайте через
<link rel="preload" as="style" onload="this.rel='stylesheet'"> - JavaScript — використовуйте
deferабоtype="module"; синхронний JS у<head>— найбільший ворог LCP
3. Помилковий lazy loading на LCP-елементі
Атрибут loading="lazy" каже браузеру зачекати з завантаженням зображення, поки воно не наблизиться до viewport. Якщо цей атрибут присутній на hero-зображенні — це пряма причина поганого LCP, яку легко пропустити в шаблонах CMS. Перевірка: відкрийте PageSpeed Insights і подивіться попередження "Defer offscreen images" — якщо LCP-елемент там є, це баг.
4. Великий TTFB (Time to First Byte)
Якщо сервер повільно відповідає, LCP не може бути хорошим за визначенням — браузер не отримає HTML, щоб розпочати завантаження ресурсів. TTFB > 800 мс — критичне значення. Причини: повільний хостинг, відсутність кешування, важкі серверні запити до БД. Рішення: CDN (Cloudflare, Fastly), Redis-кешування, HTTP/2 або HTTP/3, SSR замість клієнтського рендерингу для важливих сторінок.
5. Неоптимізований формат і розмір зображення
Зображення в JPEG/PNG розміром 1–3 МБ — системна проблема. WebP дає 25–34% економії відносно JPEG при тій самій якості. AVIF — ще на 20% ефективніший, але підтримується не всіма браузерами. Правильна реалізація:
<picture>
<source srcset="/hero.avif" type="image/avif">
<source srcset="/hero.webp" type="image/webp">
<img src="/hero.jpg" alt="Hero" width="1200" height="600"
fetchpriority="high">
</picture>Атрибути width і height обов'язкові — вони дозволяють браузеру зарезервувати місце до завантаження зображення (що також покращує CLS).
Окремий кейс — шрифти і LCP: якщо LCP-елемент є текстовим (наприклад, великий H1), використання
font-display: optional гарантує, що браузер не буде чекати завантаження нестандартного шрифту. Якщо шрифт не кешований — відобразиться системний, і LCP не постраждає.INP: детальний розбір
INP vs FID: в чому принципова різниця
FID (First Input Delay) вимірював лише затримку першої взаємодії на сторінці — зазвичай кліку одразу після завантаження, коли браузер найбільш завантажений. INP (Interaction to Next Paint) — принципово інша метрика: вона відстежує всі взаємодії впродовж сесії (кліки, натискання клавіш, тапи на тачскрині) і фіксує найгіршу. Тобто FID міг бути зеленим на сайті, де після завантаження все нормально, але при скролінгу і клікові на фільтри — лагує. INP таке вже не пропустить.
Технічно INP вимірює interaction latency — час від початку взаємодії до наступного кадру (paint), який відображає візуальний відгук. Ця затримка складається з трьох компонентів: input delay (час від події до початку обробки), processing time (час виконання event handler), presentation delay (час від завершення JS до наступного кадру).
Long Tasks і їх роль у поганому INP
Головний потік браузера (main thread) виконує все: парсинг HTML, виконання JS, layout, paint. JavaScript є однопотоковим — і якщо якийсь скрипт займає головний потік на > 50 мс, це вважається Long Task. Під час Long Task браузер не може обробляти вхідні події користувача. Результат: користувач клікнув, браузер «не відповів» ще 200–800 мс — і це фіксується як поганий INP.
Як профілювати INP у Chrome DevTools
Відкрийте сторінку → Chrome DevTools → вкладка Performance → натисніть Record → виконайте взаємодію (клік на кнопку, відкриття дропдауна, сабміт форми) → зупиніть запис. На треку Main шукайте помаранчеві блоки з червоним куточком — це Long Tasks. Клікнувши на блок, ви побачите стек викликів: який саме скрипт і функція спричинили затримку.
Ще зручніший спосіб — вкладка Performance Insights у DevTools (або Lighthouse з включеним аудитом INP). Вона одразу виводить топ взаємодій з найбільшою затримкою і декомпозує: скільки займає input delay, processing, presentation.
На одному з e-commerce проектів (~80 000 відвідувачів/міс) INP був 680 мс через популярний jQuery-плагін слайдера, який виконував повний rerender при кожному кліку. Після міграції на CSS-анімацію INP впав до 140 мс. Позиції по транзакційних запитах виросли на 8–12% впродовж двох місяців.
Конкретні оптимізації INP
Debouncing event handlers: якщо обробник події запускається на кожен символ введення або кожен піксель скролу — це гарантований Long Task. Використовуйте debounce (затримка запуску до закінчення серії подій) або throttle (обмеження частоти виклику):
// Debounce: виконати через 300мс після останньої події
function debounce(fn, delay) {
let timer;
return (...args) => {
clearTimeout(timer);
timer = setTimeout(() => fn(...args), delay);
};
}
input.addEventListener('input', debounce(handleSearch, 300));Web Workers для важких обчислень: якщо сторінка виконує сортування великих масивів, обробку зображень або парсинг даних — виносьте це у Web Worker. Worker виконується в окремому потоці і не блокує головний:
// main.js
const worker = new Worker('heavy-task.js');
worker.postMessage({ data: largeArray });
worker.onmessage = (e) => renderResult(e.data);scheduler.yield() для розбивки Long Tasks: замість виконання великого callback одним блоком, розбивайте його на частини з явними точками поступки контролю браузеру:
async function processLargeList(items) {
for (let i = 0; i < items.length; i++) {
processItem(items[i]);
// Кожні 50 елементів — поступаємося контролем
if (i % 50 === 0) await scheduler.yield();
}
}Defer третіх сторін: Google Analytics, Facebook Pixel, Hotjar, LiveChat — кожен з цих скриптів може додати 50–200 мс до INP. Завантажуйте їх після події load або через requestIdleCallback:
window.addEventListener('load', () => {
requestIdleCallback(() => loadAnalytics());
});Порада: INP дуже залежить від пристрою. Тестуйте на реальному Android-смартфоні середнього класу (Moto G Power, Samsung A-серія), а не лише у DevTools з емуляцією. Поганий INP на desktop часто непомітний, але критичний для мобільної аудиторії. Аудиторія мобільних користувачів в Україні перевищує 60% на більшості ніш.
CLS: детальний розбір
Що викликає зміщення макету
CLS (Cumulative Layout Shift) — це сума балів за всі несподівані зсуви елементів сторінки впродовж її завантаження і використання. Кожен зсув оцінюється формулою: Impact Fraction × Distance Fraction.
Impact Fraction — частка viewport, яку займає зміщений елемент (і простір, де він був до зміщення). Distance Fraction — на яку частку висоти viewport він змістився. Наприклад: банер займає 50% висоти viewport і зміщується на 25% вниз → 0.5 × 0.25 = 0.125 за один зсув. Якщо таких зсувів кілька, вони накопичуються (з урахуванням 5-секундних вікон сесії).
Найчастіші причини CLS:
| Причина | Типовий прояв | Виправлення |
|---|---|---|
| Зображення без розмірів | Контент стрибає вниз при завантаженні картинки | Явні width і height, CSS aspect-ratio |
| Банери реклами без резервування | Банер з'являється над текстом і штовхає контент | min-height на контейнері до завантаження |
| FOUT/FOIT (завантаження шрифтів) | Текст перемальовується, рядки зміщуються | font-display: optional або swap |
| Динамічно вставлений контент | Cookie-баннер, попап, sticky-хедер з'являються з затримкою | Render до завантаження або фіксований внизу |
| CSS-анімації через top/left/margin | Елементи рухаються і впливають на сусідів | Замінити на transform: translate() |
Виправлення CLS: конкретні техніки
Explicit dimensions і CSS aspect-ratio: замість того, щоб браузер дізнавався розміри зображення після його завантаження, вкажіть їх заздалегідь. Сучасний спосіб — CSS aspect-ratio:
/* Резервування місця для зображення 16:9 */
.hero-image {
aspect-ratio: 16 / 9;
width: 100%;
object-fit: cover;
}
/* Або через HTML-атрибути (браузер сам обчислить) */
<img src="hero.webp" width="1200" height="675" alt="Hero">Font-display: optional vs swap: optional — суворіший варіант: якщо шрифт не завантажений за 100 мс — браузер використовує системний і більше не намагається замінити його. Зсув неможливий за визначенням. swap — м'якший: браузер спочатку показує системний шрифт, потім замінює. Зсув можливий, але мінімальний при правильному font size adjustment.
Контейнери для банерів: перед завантаженням рекламного коду зарезервуйте місце з правильною висотою. Google рекомендує використовувати стандартні розміри IAB (300×250, 728×90, 320×50 тощо) як мінімальні висоти контейнерів.
Порада щодо анімацій: анімації через
transform і opacity виконуються на GPU і не впливають на layout. Анімації через top, left, width, height, margin — завжди викликають reflow і можуть погіршити CLS. Перевіряйте через Chrome DevTools → Rendering → Layout Shift Regions (показує прямокутники зсуву в реальному часі).Інструменти вимірювання: Lighthouse vs CrUX
Польові дані vs лабораторні: чому вони різняться
Одна з найпоширеніших причин плутанини: Lighthouse показує LCP 1.8 с (зелений), а в GSC сторінка в статусі «Погано». Це нормально — і ось чому.
Lighthouse (лабораторні дані): запускається на ізольованій машині з симульованим 4G-з'єднанням і Moto G4 в якості CPU throttling. Одна симуляція, ваш кеш очищений, жодних сторонніх скриптів від попередніх сесій. Ідеальні умови.
CrUX (польові дані): агрегат реальних відвідувань від реальних користувачів за останні 28 днів. Включає старі пристрої, повільний 3G, кешовані та некешовані сторінки, сторонні розширення браузера. Якщо 30% вашої аудиторії — на повільних Android-телефонах — CrUX це покаже, а Lighthouse — ні.
| Параметр | Lighthouse | CrUX (GSC / PSI) |
|---|---|---|
| Джерело даних | Симуляція (1 запуск) | Реальні користувачі (28 днів) |
| Стабільність | Варіюється між запусками | Стабільна агрегація |
| Вплив на ранжування | Ні | Так (Page Experience) |
| Діагностика проблем | Детальна (waterfall, скриншоти) | Обмежена |
| Мінімальний трафік | Не потрібен | ~1000 origins у CrUX |
Інтерпретація звіту GSC Core Web Vitals
GSC групує URL за шаблонами (наприклад, «всі сторінки продуктів» або «всі статті блогу») і показує статус: Good, Needs Improvement, Poor. Важливо розуміти: статус визначається за 75-м перцентилем групи. Тобто якщо хоча б 25% сторінок у групі мають Poor — вся група може отримати Poor.
При кліку на групу GSC показує конкретні URL-приклади. Це стартова точка для аналізу: відкрийте ці URL у PageSpeed Insights, щоб отримати детальний Lighthouse-звіт з конкретними рекомендаціями.
WebPageTest: waterfall-аналіз
WebPageTest (webpagetest.org) — найпотужніший безкоштовний інструмент для глибокого аналізу. Waterfall-діаграма показує послідовність завантаження кожного ресурсу: коли почалося, скільки тривало, чи заблокований ресурс іншими. Для LCP-оптимізації шукайте:
- LCP-зображення завантажується пізно (є запити перед ним, які не мають бути в критичному шляху)
- Довгий TTFB (зелена смуга першого запиту)
- CSS або JS з довгим часом блокування (червона смуга "blocked")
Порада: в WebPageTest встановіть тест з локації, близької до вашої аудиторії (наприклад, Frankfurt або Warsaw для України), і виберіть реальний пристрій замість емуляції — це дасть найточніші результати.
Вплив CWV на ранжування: реальні кейси
Що показують дослідження
Searchmetrics у дослідженні 2021 року виявив кореляцію між Core Web Vitals і позиціями — але кореляція ≠ причинно-наслідковий зв'язок. Сайти в топі часто мають кращі ресурси для технічної оптимізації взагалі. Google сам підкреслює: CWV — один із багатьох факторів ранжування, і «чудовий контент з поганими CWV все одно може ранжуватися вище, ніж поганий контент з відмінними CWV».
Google у офіційній документації прямо пише: «Page Experience signal впливає на ранжування, але якість контенту залишається більш важливим фактором». CWV — це тай-брейкер при рівних умовах, а не самостійний рушій позицій.
Різниця між Page Experience signal і CWV
Page Experience — ширший сигнал, що включає: Core Web Vitals, HTTPS, відсутність intrusive interstitials (агресивних попапів), mobile-friendliness. CWV — лише одна складова Page Experience. Технічно Google оцінює Page Experience за URL-рівнем, не за доменом.
Коли сайти з поганим CWV все одно ранжуються
На практиці сайти з Poor CWV регулярно займають топ-3 за конкурентними запитами. Причини:
- Домінуюча авторитетність домену — Wikipedia, великі медіа, урядові сайти мають тисячі зворотних посилань, що перекривають слабкі CWV
- Унікальність контенту — якщо на запит є лише 2–3 якісних результати, Google не має вибору
- Розмір вибірки CrUX — якщо сайт не має достатнього трафіку для CrUX, Page Experience сигнал не застосовується взагалі
Пріоритетність виправлень залежить від конкурентного середовища: якщо конкуренти мають хороші CWV, а ваш сайт — ні, це реальний бар'єр. Якщо всі конкуренти в жовтій зоні — виправлення дасть перевагу. Перевіряйте CWV конкурентів через PageSpeed Insights перед плануванням робіт.
З чого починати: порядок роботи
Найчастіша помилка — хапатися за все одразу. Правильний підхід: спочатку виміряти, потім визначити пріоритет, потім виправити і верифікувати результат.
Порядок пріоритизації метрик:
- Перевірте GSC — який шаблон сторінок у статусі «Погано» (Poor).
- Якщо кілька метрик у червоній зоні — починайте з LCP: він найчастіше тягне інші показники вниз і має найпряміший зв'язок із часом завантаження.
- INP виправляйте другим — він потребує профілювання JS і роботи розробника.
- CLS зазвичай виправляється швидко (розміри зображень, резерв для реклами) і часто можна зробити без залучення бекенд-розробника.
Після впровадження змін — не перевіряйте результат наступного дня. CrUX агрегує дані за 28-денне ковзне вікно. Реальні польові дані оновляться мінімум через 28 днів після деплою. Якщо зміни значні — в GSC можна запросити повторну перевірку, але результат у звіті з'явиться не раніше ніж через 28 днів.
Перевірений алгоритм для агентств і розробників: після деплою фіксуйте дату і ставте нагадування на 35 днів (28 + тиждень для повної агрегації). Не намагайтесь щодня дивитися на PSI — там мало що зміниться в перші тижні. CrUX оновлює дані щотижня, але вікно — ковзне.
Практичний чеклист: що виправляти по кожній метриці
Нижче — зведена таблиця для команди розробки або SEO-спеціаліста. Три стовпці: метрика, найпоширеніша причина, пріоритетне виправлення. Орієнтуйтеся на неї, коли потрібно швидко поставити задачі після аудиту в Google Search Console.
| Метрика | Найчастіша причина | Пріоритетне виправлення |
|---|---|---|
| LCP | Hero-зображення без preload або з loading="lazy" | Додати rel="preload" і fetchpriority="high", прибрати lazy з hero-img |
| LCP | TTFB понад 800 мс | Підключити CDN (Cloudflare), налаштувати серверне кешування, HTTP/2 |
| LCP | Зображення у форматі JPEG/PNG понад 500 КБ | Конвертувати в WebP або AVIF, вказати width і height |
| INP | Long Tasks понад 200 мс у event handlers | Debounce обробників, розбити через scheduler.yield() |
| INP | Сторонні скрипти (аналітика, чат, пікселі) | Відкласти завантаження до події load або requestIdleCallback |
| INP | Важкі обчислення в головному потоці | Винести у Web Worker |
| CLS | Зображення без явних розмірів | Додати width/height або CSS aspect-ratio |
| CLS | Рекламний банер без резервування місця | Встановити min-height на контейнер до завантаження реклами |
| CLS | Нестандартні шрифти без font-display | Додати font-display: optional або swap у CSS @font-face |
Як верифікувати результат після деплою
Відразу після впровадження змін перевіряйте лабораторні дані: PageSpeed Insights і Lighthouse CI відобразять поліпшення негайно. Це дозволяє переконатися, що оптимізація спрацювала технічно, ще до того, як CrUX накопичить нові дані. Порівнюйте TBT (Total Blocking Time) як прокси для INP у лабораторних умовах, LCP у секундах, CLS-score до і після деплою.
Реальний вплив на польові дані GSC стане помітний через 28–56 днів — залежно від того, наскільки суттєвими були зміни і якою є частка нових сесій у вікні. Зафіксуйте дату деплою і поставте нагадування на 35-й день для першої перевірки CrUX. Якщо використовуєте Lighthouse CI в CI/CD — налаштуйте автоматичне сповіщення при деградації показників: це дозволить виявити регресію в день деплою, а не через місяць, коли GSC покаже погіршення в звіті Core Web Vitals. Регулярний моніторинг через CrUX Dashboard у Looker Studio дає змогу відстежувати 28-денну динаміку по кожному шаблону сторінок окремо і швидко реагувати на нові проблеми.
Часті запитання
Що таке Core Web Vitals і чому Google їх вимірює?
Core Web Vitals — три метрики UX: LCP (швидкість завантаження головного контенту), INP (час відповіді на взаємодію), CLS (стабільність верстки). Google використовує їх як сигнал ранжування з 2021 року — сайти з поганими показниками втрачають позиції.
Який показник LCP вважається хорошим у 2025?
Хороший LCP — до 2.5 секунди. Від 2.5 до 4 секунд — потребує покращення. Понад 4 секунди — поганий показник. Ціль — щоб 75% реальних відвідувачів (за даними CrUX) мали LCP до 2.5s.
Як швидко можна покращити Core Web Vitals?
Базові виправлення (стиснення зображень, відкладений JS) дають результат за 1–2 тижні. Серйозні покращення LCP через оптимізацію сервера і критичного шляху рендерингу — за 1–2 місяці. CLS виправляється за кілька днів якщо причина — зображення без розмірів.
Чи впливають Core Web Vitals на конверсію?
Так. За даними Google, покращення LCP на 0.1s збільшує конверсію в середньому на 8%. Погані показники INP напряму пов'язані з відмовами — якщо кнопка реагує повільніше ніж 200ms, частина користувачів іде.
Потрібна технічна оптимізація сайту?
Проведемо аудит Core Web Vitals, визначимо пріоритетні виправлення і впровадимо їх у складі SEO-стратегії. Без шаблонних звітів — конкретні задачі для розробника та контроль результату через CrUX.
