Core Web Vitals це набір метрик, якими Google вимірює якість взаємодії користувача зі сторінкою: як швидко з’являється основний контент, наскільки миттєво сайт реагує на кліки й чи не «стрибає» верстка під час завантаження. Для власника бізнесу це виглядає простіше: швидкість завантаження сайту прямо впливає на те, скільки людей дочекаються сторінки, а не повернуться в пошук по наступний результат. У цьому матеріалі SEO-команда Voice розбирає, що саме вимірюють LCP, CLS та INP, як їх перевірити, які причини найчастіше гальмують сайт і як прискорити сайт без переписування проєкту з нуля.
Що таке Core Web Vitals простими словами (LCP, CLS, INP)
Google звів десятки технічних параметрів до трьох показників, які описують три різні болі користувача.
LCP (Largest Contentful Paint) час до появи найбільшого видимого елемента в межах екрана: банера, головного зображення товару, великого заголовка. Це не «повне завантаження сторінки», а момент, коли людина бачить, що сторінка справді відкрилася. LCP складається з чотирьох частин: час до першого байта від сервера, завантаження ресурсу, затримка перед його рендерингом і сам рендеринг. Саме така розкладка допомагає зрозуміти, кого «лікувати» хостинг, картинки чи шаблон.
CLS (Cumulative Layout Shift) сумарне зміщення макета. Класична ситуація: користувач тягнеться до кнопки «Купити», у цей момент догружається банер, і палець потрапляє в рекламу. CLS вимірюється не в секундах, а в умовних одиницях: наскільки великий елемент і як далеко він зсунувся.
INP (Interaction to Next Paint) реакція інтерфейсу на дії. Метрика фіксує затримку між кліком (тапом, натисканням клавіші) і моментом, коли браузер намалював візуальну відповідь. INP з 2024 року замінив попередню метрику FID і оцінює всі взаємодії протягом сесії, а не лише першу. Це набагато жорсткіший показник: він показує, чи не «підвисає» сайт від перевантаженого JavaScript.
Важлива деталь: Google оцінює не середнє значення, а 75-й перцентиль реальних візитів за останні 28 днів, окремо для мобільних і десктопів. Тобто три чверті ваших користувачів мають отримати результат у межах норми красива цифра «у мене на ноутбуці все літає» тут не аргумент.
Таблиця 1. Нормативи Core Web Vitals
| Показник | Норма (Good) | Потребує покращення | Критично (Poor) |
| LCP | до 2,5 с | 2,5–4,0 с | понад 4,0 с |
| INP | до 200 мс | 200–500 мс | понад 500 мс |
| CLS | до 0,1 | 0,1–0,25 | понад 0,25 |
| TTFB (допоміжна) | до 0,8 с | 0,8–1,8 с | понад 1,8 с |
| FCP (допоміжна) | до 1,8 с | 1,8–3,0 с | понад 3,0 с |
TTFB і FCP не входять до Core Web Vitals, але без них неможливо зрозуміти, чому LCP поганий: вони показують, на якому етапі втрачається час.
Чи справді швидкість впливає на позиції: що каже Google
Тут варто розділити маркетингові міфи й офіційну позицію. Google прямо зазначає, що єдиного «сигналу швидкості» не існує: ранжувальні системи враховують набір сигналів, пов’язаних із загальним досвідом сторінки. Так само в документації сказано, що хороші показники у звіті Search Console чи сторонніх сервісах не гарантують топ, а гонитва за «зеленою сотнею» виключно заради SEO не найкраще використання часу.
Що це означає на практиці?
По-перше, релевантність контенту залишається головною. Швидка сторінка з поверхневим текстом не обійде глибокий матеріал, який справді відповідає на запит.
По-друге, Core Web Vitals працюють як фактор диференціації. Коли кілька сторінок приблизно однаково відповідають запиту, технічна якість стає аргументом на користь однієї з них. У конкурентних комерційних нішах, де в топі десяток схожих інтернет-магазинів, цей аргумент вирішує.
По-третє, є непрямий, але потужний ефект. Повільний сайт збільшує відсоток відмов і pogo-sticking повернення в пошук одразу після переходу. Погіршується поведінкова картина, падає конверсія, дорожчає трафік із реклами. Метрики Core Web Vitals це, по суті, оцифрований користувацький досвід, і саме через нього швидкість впливає на бізнес-результат сильніше, ніж через пряме ранжування.
Практичний висновок для технічного SEO: не потрібно ганятися за 100 балами. Потрібно вивести всі три показники в «зелену» зону за польовими даними і зупинитися, перерозподіливши ресурс на контент і посилання.
Як виміряти показники (PageSpeed Insights, GSC, Lighthouse)
Перше, що потрібно засвоїти: існують два типи даних, і вони показують різне.
Польові дані (field data) реальні виміри від користувачів Chrome, зібрані в базі CrUX. Це саме те, що враховує Google. Вони доступні за 28-денний період і лише для сторінок із достатнім трафіком.
Лабораторні дані (lab data) синтетичний тест в емуляторі: фіксований пристрій, фіксована швидкість мережі. Вони потрібні для діагностики й перевірки гіпотез, але не для звітності. INP у лабораторних умовах взагалі не вимірюється, бо ніхто нічого не натискає.
Інструменти, які варто мати в роботі:
- PageSpeed Insights найшвидший старт. Вгорі польові дані по URL і по домену, нижче лабораторний аудит Lighthouse із конкретними рекомендаціями та економією в секундах. Дивитися завжди починайте з мобільної вкладки.
- Google Search Console, звіт Core Web Vitals єдине місце, де видно масштаб проблеми по всьому сайту. GSC групує схожі URL, тож ви одразу бачите: «повільні» не окремі сторінки, а весь шаблон картки товару. Це економить десятки годин.
- Lighthouse у DevTools глибша діагностика: розкладка LCP по частинах, довгі задачі в JavaScript, знімки зсувів макета.
- Performance-панель DevTools і бібліотека web-vitals для точкової роботи з INP: вона дозволяє зловити конкретний обробник події, який блокує головний потік.
- Chrome UX Report у BigQuery коли потрібно порівняти себе з конкурентами за реальними даними, а не за лабораторним тестом.
10 типових причин повільного сайту
За результатами наших аудитів картина повторюється з проєкту в проєкт:
- Незжаті зображення в оригінальному розмірі. Фото 3000 px шириною, яке виводиться в блоці 400 px, найчастіша причина поганого LCP.
- Відсутність сучасних форматів. WebP і AVIF дають 30–60% економії ваги без видимої втрати якості.
- Повільний сервер і високий TTFB. Дешевий shared-хостинг, важкі запити до бази, відсутність кешування на боці сервера.
- Купа сторонніх скриптів. Чат-віджети, аналітика, піксель, гуглові теги, A/B-тести кожен додає роботи головному потоку і псує INP.
- Блокуючі CSS і JS у head. Браузер не може почати рендеринг, доки не завантажить усе, що ви йому туди поклали.
- Роздутий шаблон і плагіни. Універсальна тема з десятком слайдерів, з яких ви використовуєте один.
- Зображення й вбудовані елементи без заданих розмірів. Прямий шлях до поганого CLS: контент стрибає, коли догружається банер чи iframe.
- Шрифти без font-display і без preload. Або невидимий текст, або різкий перескок після підміни шрифту.
- Відсутність кешування в браузері та CDN. Повторні візити коштують стільки ж, скільки перші.
- Важкий JavaScript-фреймворк там, де потрібен звичайний HTML. Особливо болісно на сторінках категорій і карток товару.
Що робити: чекліст оптимізації Core Web Vitals
Зображення. Стисніть і переведіть у WebP/AVIF. Задайте атрибути width і height або aspect-ratio для кожного зображення. Увімкніть lazy-loading для всього, що нижче першого екрана, і обов’язково вимкніть його для LCP-елемента, додавши йому fetchpriority=”high”. Це найдешевша дія з найбільшим ефектом.
Сервер і кеш. Перевірте TTFB якщо він понад 0,8 с, оптимізація фронтенду не врятує. Увімкніть серверне кешування сторінок, стиснення Brotli, HTTP/2 або HTTP/3, підключіть CDN, якщо аудиторія розподілена географічно. Налаштуйте Cache-Control для статики на тривалий термін.
JavaScript і CSS. Проведіть ревізію сторонніх скриптів: усе, що не критичне, з атрибутом defer або async, аналітику через менеджер тегів із відкладеним запуском. Приберіть невикористаний CSS, розбийте бандли на частини, довгі задачі понад 50 мс розділіть. Саме це витягує INP.
Шрифти. Локальний хостинг замість зовнішнього запиту, font-display: swap, preload для основного накреслення, сабсетинг під кирилицю.
Стабільність макета. Зарезервуйте місце під банери, віджети та cookie-повідомлення. Ніколи не вставляйте новий контент над уже видимим окрім реакції на дію користувача.
Порядок робіт. Спочатку сторінки з найбільшим трафіком і найгіршими показниками, далі шаблони, і лише потім точкова косметика. Після кожної ітерації чекайте оновлення польових даних: CrUX працює з 28-денним вікном, тож миттєвого результату у звіті не буде.
Приклад: як прискорення сайту вплинуло на трафік
Узагальнений сценарій із нашої практики інтернет-магазин на 4 000 сторінок, тематика товари для дому.
Вихідна ситуація: LCP на мобільних 5,1 с, INP 480 мс, CLS 0,29. У Search Console 78% URL у статусі «Погано». Позиції по середньочастотних комерційних запитах 11–18 місця, при цьому контент і посилальний профіль не поступалися конкурентам із топ-5.
Що зробили за шість тижнів: конвертували каталог зображень у WebP і прибрали оригінали, додали розміри всім картинкам, перенесли чат-віджет і три маркетингові скрипти на відкладене завантаження після взаємодії, увімкнули серверний кеш і Brotli, зарезервували місце під банер акцій у шапці, переписали ініціалізацію фільтрів у каталозі, розділивши довгі задачі.
Результат через два місяці після впровадження: LCP 2,2 с, INP 170 мс, CLS 0,04, частка «зелених» URL 91%. Органічний трафік на категорії зріс приблизно на чверть, конверсія в кошик на 12%, середня позиція по цільовому кластеру піднялася до 5–8 місць.
Чесна ремарка: частина приросту це не ранжування, а поведінка. Люди просто перестали закривати сторінку, не дочекавшись каталогу. Але саме комбінація цих двох ефектів робить performance сайту одним із найбільш недооцінених напрямів у SEO.
Висновки
Core Web Vitals не чарівна кнопка й не гарантія топу. Це базова гігієна, без якої решта зусиль працює гірше: ви платите за трафік, який не доходить до контенту.
Що варто запам’ятати:
- Три метрики, три різні болі: LCP швидкість появи контенту, INP реакція інтерфейсу, CLS стабільність макета.
- Google оцінює 75-й перцентиль реальних візитів за 28 днів, окремо для мобільних. Орієнтуйтеся на польові дані, а не на бали Lighthouse.
- Мета «зелена» зона за трьома показниками, а не 100 балів. Далі ресурс ефективніше вкладати в контент.
- Найбільший ефект дають прості речі: зображення, кеш, ревізія сторонніх скриптів.
- Швидкість впливає на бізнес двома шляхами через ранжування і, сильніше, через поведінку користувачів.
Якщо ви не знаєте, з чого почати, або оптимізація вже проводилася, а показники стоять на місці, почніть із діагностики. Технічний performance-аудит сайту від Voice покаже, які саме шаблони гальмують сайт, скільки секунд можна відіграти на кожному з етапів і в якому порядку це робити, щоб отримати результат за мінімального бюджету розробки. Залиште заявку і ми підготуємо звіт із пріоритезованим планом робіт.
