У кошику порожньо!
З березня 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 — це не ракетна наука, але робота, яка потребує профілювання, пріоритизації і терпіння. LCP вирішується preload + WebP + TTFB. INP — це завжди JS-аудит і розбивка Long Tasks. CLS — переважно відсутні розміри і неправильний порядок завантаження ресурсів. Між метриками є зв'язки: повільний TTFB погіршує LCP, важкий JS погіршує і INP, і LCP.
Якщо CWV тягнуть ваш сайт вниз — це вирішувана задача, але вона потребує доступу до коду і розуміння пріоритетів. Команда SEO-Factory включає технічну оптимізацію в роботи з SEO-просування.
Потрібна технічна оптимізація сайту?
Проведемо аудит Core Web Vitals, визначимо пріоритетні виправлення і впровадимо їх у складі SEO-стратегії. Без шаблонних звітів — конкретні задачі для розробника та контроль результату через CrUX.
