Зміст статті (13)
- Три метрики на простому прикладі
- Як Google рахує: польові дані проти лабораторних
- Чи впливають Core Web Vitals на позиції в Google
- Як перевірити свій сайт за 15 хвилин
- Що найчастіше ламає метрики на українських сайтах
- Як покращити LCP
- Як покращити INP
- Як покращити CLS
- Що реально на різних платформах
- Скільки коштує оптимізація в Україні
- Типові помилки
- Чеклист: Core Web Vitals за 10 пунктів
- Висновок
Core Web Vitals — це три метрики Google, які показують, наскільки зручно реальним людям користуватися сайтом: як швидко зʼявляється головний контент (LCP, норма — до 2,5 с), як швидко сторінка реагує на натискання (INP, до 200 мс) і чи не «стрибає» макет під час завантаження (CLS, до 0,1). Google оцінює їх за даними справжніх відвідувачів Chrome за останні 28 днів: сторінка проходить перевірку, якщо щонайменше 75% візитів укладаються в норму. Найчастіше показники псують важкі зображення першого екрана, шрифти та сторонні скрипти — чати, пікселі, віджети.
Нижче — пояснення без жаргону, таблиці з порогами, типові проблеми українських сайтів, план виправлення і чеклист, за яким можна перевірити свій сайт або роботу підрядника.
Три метрики на простому прикладі
Уявіть, що відвідувач заходить у кафе. LCP — скільки він чекає, поки принесуть меню. INP — як швидко офіціант реагує, коли його кличуть. CLS — чи не відсувають стілець саме в ту мить, коли людина сідає.
| Метрика | Що вимірює | Добре | Потребує покращення | Погано |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Час до появи найбільшого елемента першого екрана: банера, фото, заголовка | ≤ 2,5 с | 2,5–4 с | > 4 с |
| INP (Interaction to Next Paint) | Затримка між дією (тап, клік, введення) і видимою реакцією сторінки | ≤ 200 мс | 200–500 мс | > 500 мс |
| CLS (Cumulative Layout Shift) | Сумарні неочікувані зсуви елементів під час перегляду | ≤ 0,1 | 0,1–0,25 | > 0,25 |
LCP: коли сторінка «зʼявилась»
LCP фіксує момент, коли відмалювався найбільший видимий блок першого екрана. На лендінгу це зазвичай фонове фото або банер, у блозі — заголовок чи обкладинка, у магазині — фото товару. Людині байдуже, що меню і футер завантажились раніше: доки немає головного, сторінка для неї «порожня».
INP: чи реагує сайт на дії
З березня 2024 року INP замінив стару метрику FID. Різниця принципова: FID враховував лише першу взаємодію і лише затримку до початку її обробки, а INP дивиться на всі кліки й тапи за візит і бере один із найгірших. Тому сайт, який швидко відкривається, але «підвисає», коли людина розгортає меню, фільтр чи калькулятор, тепер провалює перевірку.
CLS: чи стоїть макет на місці
Класична ситуація: ви тягнетеся до кнопки «Подзвонити», а згори довантажується банер — і палець влучає в рекламу. CLS рахує саме такі зсуви. Кілька помітних «стрибків» за візит — і показник уже червоний, навіть якщо сайт відкривається швидко.
Як Google рахує: польові дані проти лабораторних
Саме тут найчастіше плутаються власники сайтів. У PageSpeed Insights є два різні блоки:
- Дані реальних користувачів — звіт Chrome UX Report (CrUX). Саме його враховує Google: справжні пристрої, справжній мобільний інтернет, вікно за 28 днів, оцінка за 75-м перцентилем окремо для мобільних і компʼютерів.
- Діагностика (Lighthouse) — лабораторний тест із балом від 0 до 100. Це симуляція одного завантаження на умовному смартфоні середнього рівня з повільним зʼєднанням.
Звідси парадокси. Сайт може мати 95 балів у Lighthouse і провалювати Core Web Vitals, бо реальні відвідувачі сидять на старих Android і клацають по важкому фільтру. І навпаки: бал 60, а польові дані зелені, бо аудиторія — офісні працівники з потужними ноутбуками.
У поточних версіях Lighthouse загальний бал складається з пʼяти метрик: Total Blocking Time — 30%, LCP — 25%, CLS — 25%, First Contentful Paint і Speed Index — по 10%. INP у лабораторії виміряти неможливо, бо немає реальних кліків; його найближчий лабораторний замінник — TBT.
Якщо польових даних немає. Невеликим сайтам часто бракує трафіку з Chrome, і PageSpeed Insights пише «Недостатньо даних». Тоді орієнтуйтеся на лабораторний тест і живі метрики в Chrome DevTools, а коли трафік зросте — на звіт у Search Console.
Чи впливають Core Web Vitals на позиції в Google
Впливають, але не так, як обіцяють продавці «оптимізації за один день». Core Web Vitals входять до сигналів зручності сторінки (page experience), які використовують системи ранжування. Проте Google прямо зазначає: чудова зручність не переважить релевантний і корисний контент. Повільна, але найкраща відповідь на запит усе одно буде вище за швидку порожню сторінку.
Де швидкість справді вирішує:
- Рівна конкуренція. Коли кілька сайтів однаково добре відповідають на запит — скажімо, десяток стоматологій в одному місті, — дрібні сигнали на кшталт швидкості можуть переважити.
- Конверсія. Тут ефект прямий і вимірюваний. Дослідження Deloitte «Milliseconds Make Millions» на замовлення Google (2020) показало: прискорення мобільного сайту на 0,1 с корелювало зі зростанням конверсії в роздрібній торгівлі на 8,4%.
- Реклама. Досвід користувача на посадковій сторінці впливає на показник якості в Google Ads, а отже — на ціну кліку.
- Мобільний трафік. В Україні більшість відвідувачів комерційних сайтів приходять зі смартфонів, часто через мобільний інтернет. Саме цей сценарій і перевіряє Google.
Як перевірити свій сайт за 15 хвилин
- Відкрийте PageSpeed Insights і перевірте головну та одну ключову сторінку — послуги, категорії або товару. Спершу дивіться на верхній блок із польовими даними для мобільних пристроїв.
- У Google Search Console відкрийте звіт «Core Web Vitals». Він групує схожі URL — наприклад, усі картки товарів — і показує, яка метрика підводить цілу групу.
- У Chrome DevTools → Performance увімкніть сповільнення процесора (4× або 6×) і мережі (Slow 4G), перезавантажте сторінку, потім поклацайте меню, фільтри, форму. Живі метрики покажуть LCP, INP і CLS саме для ваших дій.
- Відкрийте сайт на реальному недорогому смартфоні через мобільний інтернет. Якщо білий екран тримається довше двох секунд — клієнти бачать те саме.
Корисний мінімум для власника: раз на місяць зазирати у звіт Search Console, а після кожної зміни на сайті (новий віджет, банер, оновлення теми) проганяти PageSpeed Insights.
Що найчастіше ламає метрики на українських сайтах
| Проблема | Яку метрику псує | Як виправити |
|---|---|---|
| Слайдер на першому екрані з 3–6 фото по 1–3 МБ | LCP | Одне статичне зображення у WebP або AVIF до 150–200 КБ, решту слайдів — пізніше |
| Ліниве завантаження стоїть і на банері першого екрана | LCP | Банер вантажити одразу й з високим пріоритетом; lazy — лише нижче першого екрана |
| Дешевий хостинг, відповідь сервера 1–2 с | LCP | Кешування сторінок, CDN, сервер ближче до аудиторії; ціль — TTFB до 0,8 с |
| Чат, віджет зворотного дзвінка, пікселі Meta і TikTok, 10–20 тегів у GTM | INP, LCP | Відкладене завантаження після першої взаємодії, аудит і чистка тегів |
| 4–6 накреслень шрифту з кирилицею | LCP, CLS | 2–3 накреслення, локальне розміщення, лише потрібні символи |
| Cookie-банер або поп-ап, що зсуває вміст | CLS | Банер поверх контенту, а не над ним; поп-апи — не раніше ніж через 10–15 с |
| Зображення і відео без заданих розмірів | CLS | Ширина й висота або aspect-ratio, резерв місця під банери |
| Вбудоване відео YouTube на першому екрані | LCP, INP | «Фасад»: картинка-превʼю, плеєр вантажиться після кліку |
| Візуальний конструктор із десятками плагінів | Усі три | Відмова від зайвого, легша тема або перехід на швидшу платформу |
Як покращити LCP
LCP корисно розкласти на чотири складники — так одразу видно, де губиться час.
- Відповідь сервера (TTFB). Ціль — до 0,8 с. Допомагають кешування, CDN, нормальний хостинг замість тарифу за 50 грн на місяць і менше запитів до бази на кожне відкриття сторінки.
- Затримка перед завантаженням головного ресурсу. Браузер має дізнатися про фото першого екрана якомога раніше. Тому зображення повинно стояти прямо в HTML (а не підставлятися скриптом чи CSS-фоном), з атрибутом fetchpriority="high" і без lazy-loading.
- Час завантаження ресурсу. Формат AVIF чи WebP, розмір під екран (не віддавайте смартфону картинку шириною 2 560 пікселів), стиснення. Для більшості банерів вистачає 100–200 КБ.
- Затримка відмальовування. Блокувальні CSS і JavaScript у head, шрифти, що ще не завантажились, анімації появи, які ховають заголовок на 1–2 секунди. Критичні стилі варто вбудувати, решту — відкласти.
Орієнтир, яким користуються інженери: приблизно 40% часу LCP — на відповідь сервера, ще близько 40% — на завантаження самого зображення, а обидві затримки разом — не більше 20%.
Як покращити INP
INP погіршують «довгі завдання» (long tasks) — фрагменти JavaScript, що займають основний потік браузера довше 50 мс. Поки вони виконуються, сторінка не реагує на дотики.
- Сторонні скрипти — головний підозрюваний. Проведіть інвентаризацію: що реально використовується? Нерідко на сайті одночасно живуть два лічильники, старий піксель і чат, у якому ніхто не відповідає.
- Відкладайте некритичне. Чат, віджети соцмереж, карти, відео можна підвантажувати після першої взаємодії або коли блок потрапляє в зону видимості.
- Розбивайте важкі обробники. Фільтр каталогу, калькулятор, пошук: спершу миттєво показати реакцію (підсвітити кнопку, показати індикатор), а важкі обчислення виконати наступним кроком.
- Зменшуйте DOM. Корисний орієнтир — до 1 400 елементів на сторінці: саме з цієї межі Lighthouse традиційно вважає DOM надмірним. Мегаменю на 300 пунктів, приховані дублікати мобільної й десктопної версій, десятки прихованих поп-апів сповільнюють кожну взаємодію.
- Обережно з анімаціями. Анімуйте transform і opacity, а не розміри та позиції елементів.
Як покращити CLS
- Задавайте розміри всім зображенням, відео, iframe і рекламним блокам або резервуйте під них місце через aspect-ratio.
- Нічого не вставляйте над уже показаним контентом. Банери акцій, плашки на кшталт «Працюємо під час тривоги», cookie-повідомлення мають або займати зарезервоване місце, або зʼявлятися поверх сторінки.
- Підберіть запасний системний шрифт, близький за метриками до фірмового, і використайте size-adjust — тоді текст не «перестрибує» після завантаження шрифту.
- Показуйте скелетони замість порожнечі: якщо блок відгуків чи товарів довантажується, нехай на його місці стоїть заглушка того самого розміру.
Що реально на різних платформах
| Платформа | Що можна зробити самостійно | Типові обмеження |
|---|---|---|
| Конструктори (Tilda, Wix тощо) | Стиснути зображення, прибрати зайві блоки й віджети, зменшити кількість шрифтів | Код платформи змінити не можна; частина скриптів вантажиться завжди |
| WordPress | Легка тема, кешування, оптимізація зображень, аудит плагінів | Важкі візуальні конструктори та 30+ плагінів часто не дають вийти в зелену зону без переробки |
| SaaS-платформи для магазинів | Оптимізація фото, обережність із додатками й віджетами | Шаблон і швидкість сервера контролює платформа |
| Індивідуальна розробка | Повний контроль: рендеринг на сервері, оптимізація зображень, розбиття коду | Результат залежить від дисципліни розробника, тож фіксуйте показник у договорі |
Якщо сайт зроблено на конструкторі чи перевантаженому WordPress і показники червоні на всіх шаблонах, часом дешевше переробити сайт, ніж місяцями латати старий. Ширше про тему — у статті про швидкість сайту.
Скільки коштує оптимізація в Україні
Орієнтовні ринкові ціни станом на 2026 рік:
| Робота | Діапазон | Коли доречно |
|---|---|---|
| Аудит швидкості з переліком завдань | 2 000–6 000 грн | Перед будь-якими правками, щоб зрозуміти, що саме ламає метрики |
| «Швидкі перемоги» на WordPress: зображення, кешування, шрифти, відкладені скрипти | 5 000–15 000 грн | Сайт загалом нормальний, але перевантажений |
| Глибока оптимізація фронтенду і сервера | 15 000–50 000 грн | Магазин або каталог із великим трафіком |
| Редизайн чи перенесення на іншу платформу | 60–100% вартості нового сайту | Коли проблема в самій платформі або темі |
Технічний SEO-аудит, що включає Core Web Vitals, у нас коштує 4 900 ₴. Для нових сайтів ми фіксуємо в договорі PageSpeed 90+ на мобільних — або доопрацьовуємо безкоштовно. Редизайн рахуємо як 70% вартості нового пакета, з перенесенням контенту і 301-редиректами.
Типові помилки
- Гнатися за 100 балами Lighthouse. Бал — це діагностика, а не мета. Вирішують польові дані реальних відвідувачів.
- Перевіряти тільки головну. Пошуковий трафік здебільшого приходить на сторінки послуг, категорій і статей — тестуйте шаблони, а не одну сторінку.
- Тестувати на офісному Wi-Fi і новому iPhone. Ваші клієнти — на мобільному інтернеті та смартфонах за 5–8 тисяч гривень.
- Чекати змін у Search Console наступного дня. Дані збираються за 28 днів, тож результат правок проявляється поступово, протягом місяця.
- Ставити кілька плагінів кешування одночасно. Вони конфліктують, і сайт може стати повільнішим або взагалі зламатися.
- Видаляти аналітику заради зеленого балу. Без неї ви не порахуєте заявки. Правильний шлях — відкладене завантаження і чистка непотрібних тегів.
- Оптимізувати один раз. Новий віджет, банер акції чи плагін можуть за день звести роботу нанівець. Швидкість — це процес, а не разовий проєкт.
Чеклист: Core Web Vitals за 10 пунктів
- Польові дані в PageSpeed Insights зелені на мобільних за всіма трьома метриками
- У Search Console немає груп URL зі статусом «Погано»
- Зображення першого екрана — WebP або AVIF, до 200 КБ, без lazy-loading, з високим пріоритетом
- Відповідь сервера (TTFB) — до 0,8 с
- Не більше 2–3 накреслень шрифтів, розміщених локально
- Чати, пікселі й віджети вантажаться відкладено; у GTM — лише потрібні теги
- Усі зображення, відео й iframe мають задані розміри
- Cookie-банер і поп-апи не зсувають вміст
- Меню, фільтри й форми реагують миттєво навіть із 4× сповільненням процесора
- Після кожної суттєвої зміни сайту — повторна перевірка
Висновок
Core Web Vitals — не магія і не «секретний фактор SEO», а три цілком конкретні питання: чи швидко людина бачить головне, чи реагує сайт на її дії і чи не стрибає сторінка. Здебільшого їх вирішує десяток рутинних дій із зображеннями, шрифтами та сторонніми скриптами, і ефект помітний не так у позиціях, як у заявках.
Почніть з онлайн-аудиту сайту — він покаже, які метрики червоні і чому. Якщо платформа вже не витягує, подивіться, як ми робимо редизайн з гарантією PageSpeed 90+ на мобільних, а щоб показники не просідали після запуску, є підтримка сайту з регулярним моніторингом. Як мобільна версія впливає на продажі, ми розібрали окремо — у статті про мобільну версію сайту.
Редакція Tvorum
Пишемо про те, з чим працюємо щодня: сайти, SEO, реклама й конверсія. Простою мовою, з цифрами та прикладами — щоб ви могли застосувати це у своєму бізнесі.
