Core Web Vitals

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

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

Три показники Core Web Vitals

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

LCP: поява основного контенту

Largest Contentful Paint фіксує момент, коли в області перегляду відобразився найбільший релевантний текстовий або графічний елемент. Ним часто стає hero-зображення, великий заголовок чи основне фото товару.

На LCP впливають швидкість відповіді сервера, пріоритет завантаження ресурсу, блокувальні CSS і JavaScript, розмір зображення та рендеринг на клієнті. Зменшення всіх файлів без діагностики не гарантує результату: спочатку треба визначити LCP-елемент і критичний шлях його появи.

INP: чутливість до взаємодії

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

Поганий INP часто спричиняють довгі JavaScript-задачі, надмірна робота основного потоку, складний DOM, важкі сторонні скрипти та обробники, які виконують забагато дій синхронно. Користувач сприймає це як кнопку, що «не реагує», затримку меню або зависання форми.

CLS: візуальна стабільність

Cumulative Layout Shift оцінює неочікувані зміщення видимих елементів. Типовий приклад: людина збирається натиснути кнопку, але над нею пізно завантажується банер, і кнопка зміщується.

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

Польові та лабораторні дані

Польові дані походять із реальних відвідувань і відображають різні пристрої, мережі та поведінку. Саме вони лежать в основі звітів Chrome User Experience Report і Core Web Vitals у Search Console. Дані можуть бути доступні на рівні конкретного URL або групи URL і накопичуються за рухомий період.

Лабораторні дані отримують у контрольованому тесті, наприклад у Lighthouse. Вони зручні для відтворення проблем і перевірки змін, але один тест не описує всю аудиторію. Lighthouse може показати потенційні причини повільної роботи, тоді як польові дані відповідають на питання, що реально відбувається з користувачами.

Core Web Vitals і SEO

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

Для бізнесу значення часто ширше за SEO. Затримка фільтра в каталозі, стрибок кнопки оплати або повільна поява розкладу прямо впливають на завершення сценарію.

Практичний приклад

Онлайн-сервіс продажу залізничних екскурсій має добрий середній час завантаження, але користувачі скаржаться на вибір дати. Польові дані показують високий INP на мобільних пристроях. Аналіз виявляє, що календар після кожного натискання синхронно перераховує доступність усіх маршрутів. Команда переносить частину обчислень, скорочує DOM і розбиває довгу задачу. Поліпшення оцінюють не лише за INP, а й за часткою завершених бронювань.

Як організувати роботу

1. Знайти проблемні групи URL у Search Console або CrUX.
2. Перевірити репрезентативні сторінки лабораторними інструментами.
3. Визначити конкретні LCP-елементи, довгі задачі та джерела зсувів.
4. Пріоритизувати шаблони з найбільшим трафіком і бізнесовою цінністю.
5. Внести зміни й перевірити регресії на різних пристроях.
6. Відстежувати польовий результат і бізнес-метрики після накопичення даних.

Типові помилки

• вважати загальний бал Lighthouse тотожним Core Web Vitals;
• робити висновок за одним швидким ноутбуком і стабільним Wi-Fi;
• оптимізувати лише головну сторінку, ігноруючи товарні та контентні шаблони;
• дивитися на середнє замість 75-го перцентиля;
• плутати відсутність польових даних із добрим результатом;
• скорочувати функціональність без перевірки впливу на конверсію;
• обіцяти гарантоване зростання позицій після проходження порогів.

Пов’язані поняття

LCP · INP · CLS · PageSpeed Insights · Lighthouse · Chrome User Experience Report · Технічне SEO · Конверсія

Висновок

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

Джерела

web.dev: Web Vitals
web.dev: How the Core Web Vitals thresholds were defined