Core Web Vitals: це три показники Google, які описують досвід користувача на сторінці: як швидко з'являється основний контент (LCP), як швидко сайт відповідає на клік чи тап (INP) і наскільки макет «стрибає» під час завантаження (CLS). Пороги «добре» станом на публікацію: LCP до 2,5 секунди, INP до 200 мілісекунд, CLS до 0,1, і оцінюють їх за даними реальних відвідувачів, а не за одним тестом на комп'ютері розробника. Нижче розбираємо, що саме вимірює кожна метрика, де подивитись свої цифри, чому вони часто погані і що з цим робити.
Google запровадив набір Web Vitals у 2020 році, щоб звести розмову про швидкість завантаження сайту до кількох зрозумілих чисел. «Core», тобто основні, це ті три, які потрапляють у ранжування і в звіти Search Console.
Largest Contentful Paint вимірює час від початку переходу до моменту, коли у видимій частині екрана відмалювався найбільший елемент: банер, заголовок, фото товару. Це не «повне завантаження», а саме момент, коли людина бачить, що сторінка вже «є». Якщо LCP дорівнює 5 секундам, відвідувач ці п'ять секунд дивиться на порожній екран.
Interaction to Next Paint дивиться на всі кліки, тапи й натискання клавіш за візит і бере фактично найгірший із них (з невеликою поправкою на дуже довгі сесії). Вимірює затримку від дії до наступного оновлення екрана. INP офіційно замінив First Input Delay 12 березня 2024 року, тож якщо у старих чек-листах ще фігурує FID, їх пора оновити. Відмінність принципова: FID рахував лише першу взаємодію, INP дивиться на весь візит, тому «підвисання» фільтра в каталозі чи кошика тепер теж іде в залік.
Cumulative Layout Shift, це не час, а безрозмірний показник: сума несподіваних зсувів елементів. Класична ситуація: людина цілиться в кнопку, зверху довантажується банер, кнопка з'їжджає, клік потрапляє в рекламу. Кожен такий зсув додає балів до CLS.
Google ділить кожну метрику на три зони. Щоб сторінка «пройшла» перевірку, всі три показники мають бути в зеленій зоні на 75-му перцентилі: тобто щонайменше три чверті реальних завантажень мають вкладатися в поріг.
| Метрика | Добре | Треба покращити | Погано |
|---|---|---|---|
| LCP | до 2,5 с | від 2,5 до 4 с | понад 4 с |
| INP | до 200 мс | від 200 до 500 мс | понад 500 мс |
| CLS | до 0,1 | від 0,1 до 0,25 | понад 0,25 |
Зверніть увагу на 75-й перцентиль. Сайт може відкриватися за секунду з офісу на оптоволокні і при цьому не проходити CWV, бо чверть відвідувачів заходить зі старих Android-телефонів через мобільний інтернет. Саме тому мобільна версія майже завжди гірша за десктопну, і саме її Google дивиться в першу чергу.
Це найчастіша плутанина, з якою ми в Query стикаємось на консультаціях. Є два джерела даних, і показують вони різне.
Практичний висновок: оцінюйте себе за польовими даними, а лабораторний звіт використовуйте як список підказок. І не дивуйтесь, коли після виправлень польові цифри змінюються не одразу: вікно 28 днів, зміни «доїжджають» поступово.
PageSpeed Insights (PSI): безкоштовний інструмент Google, вводите URL і отримуєте два блоки: оцінку Core Web Vitals за польовими даними (мобільні й десктоп окремо) і лабораторний аудит з рекомендаціями. Це перше, що варто відкрити. Оцінка продуктивності від 0 до 100, яку всі люблять скріншотити, стосується лише лабораторної частини і в ранжуванні участі не бере. Гнатися за 100 балами не треба; треба, щоб польові метрики були зелені.
Звіт Core Web Vitals у Google Search Console показує картину по всьому сайту: скільки URL «добрих», скільки «потребують покращення», скільки «поганих», окремо для мобільних і десктопу. Сторінки там згруповані за шаблоном: якщо погано в одній картці товару, погано і в решті, тож виправлення шаблону закриває сотні URL одразу. Це найзручніший спосіб розставити пріоритети: дивитесь, яка група найбільша і яка метрика в ній провалена.
Для регулярного контролю є ще CrUX Dashboard у Looker Studio і розширення Web Vitals для Chrome, яке показує метрики просто під час перегляду сторінки. Розробникам зручніший Lighthouse у DevTools, там же вкладка Performance для пошуку конкретного важкого скрипта.
Причини повторюються від сайту до сайту. За нашими спостереженнями, здебільшого проблема не одна велика, а п'ять-шість середніх, які разом і дають червону зону.
| Метрика | Поріг «добре» | Типова причина | Що зробити |
|---|---|---|---|
| LCP | до 2,5 с | Важке фото в першому екрані, повільний сервер (TTFB понад 800 мс), рендер-блокуючий CSS і JS | Стиснути зображення й перевести у WebP/AVIF, головному фото задати fetchpriority="high", увімкнути кеш і CDN, винести некритичний CSS/JS з <head> |
| INP | до 200 мс | Сторонні скрипти (чати, пікселі, віджети), важкий фреймворковий JS, довгі обробники кліків | Прибрати зайві скрипти, решту завантажувати відкладено (defer, async), розбивати довгі задачі на частини, перевірити час відповіді сервера на AJAX-запити |
| CLS | до 0,1 | Зображення й відео без розмірів, банери та реклама, що вставляються зверху, підвантаження веб-шрифтів зі «стрибком» тексту | Прописати width/height усім медіа, резервувати місце під банери, шрифти віддавати з font-display: swap і preload |
Кілька уточнень по пунктах, які найчастіше виявляються «тією самою» причиною.
Зображення. Слайдер на головній з п'ятьма фото по 2 МБ кожне, це стандартна історія на сайтах, зроблених кілька років тому. Перше фото і є LCP-елементом, і важити воно має не більше 150-200 КБ. Решту слайдів можна довантажувати пізніше.
Шрифти. Три сімейства по чотири накреслення, підключені з Google Fonts, дають і затримку LCP, і стрибок CLS, коли системний шрифт підміняється на кастомний. Лишіть два накреслення, віддавайте їх зі свого сервера у форматі WOFF2.
Сторонні скрипти. Онлайн-чат, кілька рекламних пікселів, карта, віджет відгуків: кожен тягне свій JS, і саме вони найчастіше псують INP. Порахуйте, які реально використовуються. Непотрібний вимикайте; потрібний вантажте після першої взаємодії або через Tag Manager із затримкою.
Хостинг і TTFB. Time to First Byte, час до першого байта відповіді сервера, це нижня межа для LCP: якщо сервер думає 1,5 секунди, LCP менше 2,5 фізично не вийде. Дешевий shared-хостинг, відсутність кешу сторінок, важкі запити до бази, все це видно в PSI як «Скоротіть час відповіді сервера». Іноді найдешевше рішення, це просто увімкнути серверний кеш і переїхати на нормальний тариф.
Частину цього закриває стандартна технічна SEO-оптимізація, а глибші речі на кшталт переписування шаблонів чи заміни слайдера вже належать до доробки сайту руками розробника. У Query ми зазвичай робимо це в одній зв'язці: аудит показує, що саме гальмує, розробник виправляє, а польові дані підтверджують результат.
Чесна відповідь: впливають, але не так, як інколи лякають. Google підтверджує, що Core Web Vitals входять до сигналів «досвіду сторінки», однак це один із багатьох факторів, і релевантність контенту важить значно більше. Сайт з поганими метриками, але кращою відповіддю на запит, як правило, обійде швидкий сайт з порожньою сторінкою. Працює це радше як фільтр серед рівних: коли конкуренти близькі за змістом, зелена зона дає перевагу.
А от вплив на конверсію прямий і помітний без будь-якого Google. Повільна сторінка втрачає частину відвідувачів ще до першого екрана, стрибки макета призводять до помилкових кліків, а «підвисання» кнопки «Купити» на пів секунди відчувається як поламаний сайт. Тому ми радимо дивитися на CWV не як на SEO-галочку, а як на показник того, скільки грошей витікає через швидкість завантаження сайту. Докладний опис метрик і методики вимірювання є в офіційній документації Google на web.dev/vitals.
.jpg "Індексація сайту простими словами: як працює і як її перевірити")
.jpg "Ідеї для інтернет-магазину: перспективні ніші та як обрати свою")
.jpg "Електронна комерція: що таке eCommerce і як він працює")
.jpg "Просування сайту вічними посиланнями та поведінковими факторами: як поєднати")
