Core Web Vitals простими словами

«PageSpeed показує 38 балів, це катастрофа?» — з таким питанням до нас приходять власники сайтів майже щотижня. Хтось отримав лист від Search Console про «погані URL», хтось побачив червоні цифри в звіті підрядника, а хтось просто помітив, що сайт на телефоні відкривається повільніше, ніж у конкурентів. За всіма цими історіями стоять три абревіатури — LCP, INP і CLS, які Google об’єднав під назвою Core Web Vitals.

У цій статті ми пояснюємо їх без зайвої термінології: що саме вимірює кожен показник, які значення вважаються нормою, звідки беруться цифри і що реально допомагає їх покращити. Усе це — з досвіду оптимізації сайтів на WordPress, інтернет-магазинів і лендингів, де ми щодня розбираємо, чому сторінка «гальмує» і як це виправити, не переписуючи сайт з нуля.

Що таке Core Web Vitals і навіщо вони бізнесу

Core Web Vitals — це набір із трьох метрик, якими Google оцінює реальний досвід людини на сторінці. Не «наскільки швидкий у вас сервер» і не «скільки важать файли», а те, що відчуває відвідувач: як швидко він бачить головний вміст, як швидко сайт реагує на його натискання і чи не стрибають елементи під пальцем.

• LCP (Largest Contentful Paint) — швидкість завантаження: через скільки секунд з’являється найбільший видимий елемент першого екрана.
• INP (Interaction to Next Paint) — чуйність: як швидко сторінка візуально відповідає на клік, дотик чи натискання клавіші.
• CLS (Cumulative Layout Shift) — візуальна стабільність: наскільки сильно зсуваються блоки під час завантаження і роботи зі сторінкою.

Навіщо це бізнесу? По-перше, швидкість — частина сигналів якості сторінки, які Google враховує в ранжуванні. Важливо розуміти масштаб: релевантний і корисний контент усе одно важить більше, і ідеальні Core Web Vitals не витягнуть у топ слабку сторінку. Але коли кілька сайтів приблизно рівні за змістом, технічна якість може стати аргументом на вашу користь. Про те, які фактори ранжування справді працюють, а які переоцінені, ми писали у статті «Результативне SEO-просування».

По-друге, і це для нас важливіше, — гроші. Повільна сторінка втрачає частину відвідувачів ще до того, як вони побачили пропозицію. Кнопка, що не реагує з першого разу, дратує. Банер, який раптово зсуває форму, призводить до випадкових кліків не туди. Кожна з цих дрібниць знижує конверсію, і її видно в аналітиці задовго до того, як вона відіб’ється на позиціях.

Три показники та їхні норми

Google ділить результати кожної метрики на три зони: «добре», «потребує покращення» і «погано». Ось межі, на які ми орієнтуємося в кожному проєкті:

Показник	Що вимірює	Добре	Потребує покращення	Погано
LCP	Поява головного елемента	до 2,5 с	2,5–4 с	понад 4 с
INP	Реакція на дії користувача	до 200 мс	200–500 мс	понад 500 мс
CLS	Стабільність макета	до 0,1	0,1–0,25	понад 0,25

Дві деталі, які часто пропускають. Перша: оцінюється не середнє значення, а 75-й процентиль. Тобто сторінка вважається «доброю», якщо щонайменше три чверті реальних відвідувань вклалися в норму. Якщо у вас швидкий офісний інтернет, а половина клієнтів заходить зі старих смартфонів через мобільну мережу, саме вони визначатимуть результат. Друга: мобільна і десктопна версії оцінюються окремо, і мобільна майже завжди гірша.

Раніше замість INP у наборі був показник FID, який міряв лише затримку першої взаємодії. INP суворіший: він враховує практично всі натискання за весь час перебування на сторінці. Тому сайти, які роками були «зеленими», після цієї заміни іноді раптом отримували попередження в Search Console, хоча нічого на них не змінювали.

Польові та лабораторні дані: чому цифри різняться

Найпоширеніша плутанина, з якою ми стикаємося: власник запускає PageSpeed Insights і бачить дві різні оцінки, а потім ще й третю в Search Console. Насправді це різні типи даних.

• Польові дані (field data) — це вимірювання реальних відвідувачів у браузері Chrome за останні 28 днів, зі звіту Chrome UX Report. Саме їх Google використовує для оцінки сторінок. У PageSpeed Insights це верхній блок звіту, над балом продуктивності.
• Лабораторні дані (lab data) — одноразовий тест Lighthouse на емульованому пристрої з повільним процесором і сповільненою мережею. Звідси той самий «бал продуктивності» від 0 до 100. Він зручний для діагностики, але сам по собі в ранжуванні не враховується.

Тому сайт може мати 45 балів у лабораторному тесті і водночас «зелені» польові показники — бо реальні відвідувачі користуються швидшими пристроями, ніж емулятор. Буває й навпаки. Ми завжди дивимося спершу на польові дані, а лабораторні використовуємо як рентген: вони показують, які саме файли й скрипти гальмують.

Ще один нюанс: INP у лабораторному тесті виміряти неможливо, бо там ніхто не клікає. Lighthouse показує замість нього TBT (Total Blocking Time) — загальний час, протягом якого головний потік браузера був зайнятий. Високий TBT майже завжди означає проблеми з INP у реальних людей.

Де дивитися показники:

1. Search Console → «Основні веб-показники». Групує сторінки сайту за типами й показує, які групи «погані». Для невеликих сайтів даних може бути недостатньо — тоді звіт порожній.
2. PageSpeed Insights. Польові дані для конкретної адреси або всього домену плюс лабораторний аналіз із рекомендаціями.
3. Chrome DevTools, вкладка Performance. Показує LCP, INP і CLS наживо, поки ви самі користуєтеся сторінкою, і підсвічує елементи, які зсуваються.
4. Власний збір даних. Бібліотека web-vitals передає показники кожного відвідування в Google Analytics 4 чи іншу систему. Це дає повну картину навіть для сторінок з невеликим трафіком.

LCP: як швидко з’являється головне

LCP відповідає на запитання «коли людина бачить, що сторінка завантажилася». Зазвичай найбільший елемент першого екрана — це банер на головній, фото товару в картці, обкладинка статті або великий заголовок. Показник зупиняється, коли цей елемент повністю відмальовано.

Перше, що ми робимо, — з’ясовуємо, який саме елемент є LCP на кожному типі сторінок. PageSpeed Insights показує його в розділі діагностики, DevTools — у вкладці Performance. Іноді відповідь несподівана: на мобільному це може бути не головне фото, а вікно згоди на cookie або абзац тексту, бо фото на вузькому екрані стає меншим. Від цього залежить увесь подальший план робіт.

Щоб зрозуміти, що саме гальмує, ми розкладаємо LCP на чотири етапи:

1. Відповідь сервера (TTFB) — скільки часу минає до першого байта HTML. Повільний хостинг, відсутність кешування, важкі запити до бази даних.
2. Затримка перед завантаженням ресурсу — браузер довго не знає, що головне зображення потрібне. Наприклад, воно підставляється через JavaScript або задане як фон у CSS.
3. Завантаження ресурсу — саме зображення важить забагато або йде з повільного сервера.
4. Затримка відмальовки — файл уже завантажено, але сторінка не показує його, бо чекає на стилі, шрифти чи скрипти.

Цей розклад одразу підказує, де копати. Якщо половину часу займає відповідь сервера, стискати фото марно. Якщо сервер відповідає швидко, але зображення стоїть у черзі за десятком скриптів, допоможе не новий хостинг, а зміна пріоритетів.

Що ми робимо найчастіше:

• Прискорюємо сервер. Повносторінкове кешування, актуальна версія PHP, об’єктний кеш для WordPress, CDN для статики. Якщо після цього TTFB стабільно перевищує 600–800 мс, говоримо про зміну тарифу або хостингу.
• Робимо LCP-зображення пріоритетним. Звичайний тег img у HTML замість фону через CSS, атрибут fetchpriority="high" і жодного лінивого завантаження для першого екрана. Помилка, яку ми бачимо постійно: плагін «прискорення» вішає loading="lazy" на всі зображення, включно з головним банером, і LCP від цього погіршується.
• Зменшуємо вагу. Формати WebP або AVIF, адаптивні розміри через srcset, щоб телефон не завантажував картинку для 4K-монітора.
• Прибираємо блокування. Критичні стилі першого екрана вбудовуємо в сторінку, решту CSS і скрипти завантажуємо відкладено, шрифти підключаємо з font-display: swap і попереднім завантаженням.
• Спрощуємо перший екран. Слайдер із п’яти важких банерів, відеофон і анімоване інтро — найчастіші вбивці LCP. Один статичний банер із чітким заголовком зазвичай і швидший, і краще конвертує.

INP: як швидко сайт реагує на дії

INP — найменш інтуїтивний показник, тож пояснимо на прикладі. Людина натискає «Додати в кошик». Між дотиком і моментом, коли на екрані щось змінилося — з’явилася цифра на іконці кошика, кнопка стала активною, відкрилося вікно, — минає певний час. INP фіксує найгірші з таких затримок за весь візит. Якщо цей час перевищує 200 мс, людина відчуває, що сайт «тупить», і часто натискає повторно.

Причина майже завжди одна: головний потік браузера зайнятий виконанням JavaScript і не може вчасно обробити натискання. Браузер — як касир з однією чергою: поки він пробиває величезне замовлення, наступний покупець чекає, навіть якщо в нього одна пляшка води.

Звідки на сайті береться стільки JavaScript:

• сторонні скрипти: онлайн-чати, віджети зворотного дзвінка, пікселі рекламних систем, карти, вбудовані відео, тег-менеджери з десятками тегів;
• важкі теми й конструктори сторінок, які завантажують увесь свій код на кожну сторінку;
• фільтри в каталогах, що перебудовують увесь список товарів при кожному кліку;
• величезна кількість елементів на сторінці: мегаменю на кілька сотень пунктів, приховані блоки, повні каталоги в HTML.

Що допомагає:

1. Інвентаризація сторонніх скриптів. Ми складаємо список усього, що підключено, і з’ясовуємо, хто й навіщо це додав. Типова знахідка — пікселі рекламних кабінетів, якими вже давно ніхто не користується, і два чати одночасно.
2. Відкладене завантаження. Чат, карту чи відео можна підвантажувати лише тоді, коли людина до них дійшла або натиснула на заглушку.
3. Розбиття довгих задач. Код, який виконується одним шматком довше 50 мс, розробник ділить на частини, щоб браузер між ними встигав реагувати на дії людини.
4. Миттєвий візуальний відгук. Спершу показуємо, що натискання прийнято (кнопка змінила стан, з’явився індикатор), а важку роботу робимо після цього.
5. Менше DOM-елементів. Чим менше вузлів на сторінці, тим швидше браузер перераховує її після кожної дії.

CLS: щоб сторінка не стрибала

Усі хоч раз хотіли натиснути на посилання, а в останню мить текст з’їжджав униз, бо над ним довантажився банер. Саме це і вимірює CLS — сумарну величину неочікуваних зсувів макета. На відміну від інших показників, це не час, а безрозмірне число: чим більший блок зсунувся і чим далі, тим вище значення.

Зсуви одразу після дії користувача, наприклад розкриття акордеона по кліку, не рахуються — вони очікувані. Рахуються ті, що відбуваються «самі».

Найчастіші причини і рішення:

Причина	Що робимо
Зображення й відео без розмірів	Прописуємо width і height або CSS aspect-ratio, щоб браузер заздалегідь резервував місце
Рекламні блоки, банери, віджети	Резервуємо під них контейнер фіксованої висоти, навіть поки вони порожні
Банер cookie чи акції вгорі сторінки	Показуємо поверх контенту або внизу екрана, а не вставляємо над ним
Веб-шрифти	Попереднє завантаження і підбір резервного шрифту близьких розмірів, щоб текст не «перестрибував»
Контент, що довантажується скриптом	Скелетон потрібної висоти замість порожнього місця
Анімації	Анімуємо через transform, а не через зміну розмірів і відступів

CLS — зазвичай найпростіший для виправлення показник. Часто вистачає кількох рядків CSS у шаблоні, і проблема зникає на всіх сторінках одразу.

Як утримати результат

Прискорити сайт один раз — половина справи. Набагато складніше не дати йому знову обрости зайвим кодом. Тому після оптимізації ми домовляємося з клієнтом про кілька простих правил:

• Кожен новий сервіс — через перевірку. Перш ніж додати чат, квіз чи новий піксель, варто подивитися, скільки коду він тягне і чи можна завантажувати його відкладено.
• Зображення — за стандартом. Контент-менеджер завантажує фото потрібного розміру і формату, а не оригінал з фотоапарата на десяток мегабайтів.
• Оновлення — на тестовій копії. Нова версія теми чи плагіна може повернути вимкнені скрипти або змінити верстку першого екрана.
• Моніторинг — щомісяця. Звіт Search Console і дані з аналітики показують погіршення раніше, ніж його помітять клієнти.

Окремо стежимо за сторінками, які приносять гроші: формою заявки, кошиком, оформленням замовлення. Саме там повільна реакція на натискання коштує найдорожче, а перевіряють їх найрідше, бо в лабораторному тесті ці сторінки часто взагалі не аналізують.

Як це виглядає на практиці

Типова ситуація: сайт компанії послуг на WordPress, куплена тема з конструктором сторінок, двадцять із гаком плагінів. Search Console позначає більшість мобільних сторінок як «погані» за LCP і INP. Власник уже пробував плагін кешування, але бал у PageSpeed майже не змінився.

Під час аналізу ми бачимо типовий набір: на головній — слайдер із великими зображеннями, де перший слайд завантажується ліниво; сервер відповідає понад секунду, бо кеш не працює для мобільних; на кожній сторінці завантажуються скрипти форм, галереї та карти, хоча вони є лише на двох сторінках; два чати і кілька старих пікселів.

Наша послідовність у таких випадках: налаштовуємо кешування і перевіряємо, що воно справді віддає готові сторінки; замінюємо слайдер на статичний банер з пріоритетним завантаженням; конвертуємо зображення у WebP із правильними розмірами; відключаємо скрипти плагінів там, де вони не потрібні; прибираємо зайвий чат і пікселі, а решту віджетів завантажуємо відкладено; задаємо розміри для зображень і резервуємо місце під банер cookie. Потім чекаємо — польові дані оновлюються поступово, протягом приблизно 28 днів, тому миттєвого «позеленіння» в Search Console не буде. Конкретний результат залежить від сайту, але таких змін зазвичай вистачає, щоб більшість сторінок перейшли в зелену зону без редизайну.

Помилки, які ми бачимо найчастіше

1. Гонитва за 100 балами. Лабораторний бал — інструмент діагностики, а не мета. Ми бачили сайти, які довели його до 98, вимкнувши аналітику й форми заявок.
2. П’ять плагінів оптимізації одночасно. Вони конфліктують між собою, ламають верстку і часто погіршують результат.
3. Тестування лише з офісного комп’ютера. Реальна аудиторія — це смартфони середнього класу і нестабільний мобільний інтернет. Про оцінку сайту за мобільною версією — у статті «Як досягти успіху в mobile-first index».
4. Оптимізація лише головної. Трафік і заявки часто приходять на картки товарів, категорії та статті, а вони працюють на інших шаблонах.
5. Нові віджети без перевірки. Сайт прискорили, а через пів року маркетолог додав три нові сервіси — і все повернулося.
6. Очікування миттєвого результату. Польові дані накопичуються тижнями, тож оцінювати зміни за один день некоректно.

Короткий чекліст

• Перевірте звіт «Основні веб-показники» в Search Console окремо для мобільних і десктопу.
• Визначте головні шаблони сторінок: головна, категорія, картка, стаття, лендинг.
• Для кожного з’ясуйте, який елемент є LCP, і переконайтеся, що він не завантажується ліниво.
• Перевірте TTFB: якщо він стабільно вищий за 600–800 мс, почніть із сервера і кешування.
• Складіть список сторонніх скриптів і приберіть ті, якими ніхто не користується.
• Задайте розміри всім зображенням, відео і рекламним блокам.
• Налаштуйте збір реальних показників в аналітику, щоб бачити ефект змін.
• Повторно перевірте дані через чотири тижні.

Часті запитання

Чи впаде сайт у пошуку, якщо Core Web Vitals «погані»?

Автоматичного падіння не буде. Ці показники — лише один із багатьох сигналів, і зміст сторінки важить більше. Але в конкурентних нішах, де сайти близькі за якістю контенту, повільна сторінка програє. А втрату конверсії ви отримуєте незалежно від позицій.

Чому PageSpeed показує низький бал, а Search Console — що все добре?

Бал PageSpeed — це лабораторний тест на емульованому слабкому телефоні. Search Console показує польові дані реальних відвідувачів. Для оцінки Google важливіші саме польові, а лабораторні допомагають знайти, що конкретно виправляти.

Чи можна виправити все одним плагіном?

Частково. Плагін кешування й оптимізації зображень закриває базові речі і часто суттєво покращує LCP. Але INP і CLS здебільшого залежать від теми, конструктора і сторонніх скриптів, а це вже ручна робота з кодом і налаштуваннями.

Чи потрібен для цього редизайн або новий сайт?

Зазвичай ні. Більшість проблем вирішується в межах наявного сайту. Перебудову ми радимо лише тоді, коли тема чи конструктор фізично не дозволяють прибрати зайвий код. Якщо ж ви плануєте новий проєкт, наприклад магазин, закладати швидкість варто з першого дня — так ми робимо в межах розробки інтернет-магазинів. Про інші технічні точки росту магазинів — у статті «П’ять порад для просування магазину».

Підсумок

Core Web Vitals — це три прості запитання до вашого сайту: чи швидко людина бачить головне, чи швидко сайт реагує на її дії і чи не стрибає сторінка. LCP найчастіше впирається в сервер і важкий перший екран, INP — у JavaScript і сторонні віджети, CLS — у елементи без заданих розмірів. Відповіді на всі три знаходяться в польових даних, а лабораторні тести підказують, що саме виправляти.

Почніть із діагностики шаблонів, а не з пошуку «чарівного» плагіна. Швидкість — не разова акція: кожен новий віджет чи банер варто перевіряти, щоб не повернутися до вихідної точки.

Якщо хочете, щоб ми розібралися, що гальмує саме ваш сайт, — напишіть нам. Ми проводимо аудит і робимо оптимізацію швидкості сайту під ключ, а за потреби поєднуємо її з просуванням сайту, щоб технічна якість працювала на позиції й заявки.