Core Web Vitals – новий критерій ранжування Google і як тепер контролювати веб-продуктивність

Google оголосив, що з червня 2021 року вони почнуть розглядати “Page Experience” як частину ранжирування в пошуку. Цей фактор вимірюється набором показників, які називаються Core Web Vitals.

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

Проте, у цій статті ми зосередимось саме на Core Web Vitals.

Що таке Core Web Vitals?

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

Основні метрики:

1. Largest Contentful Paint (LCP) – показник завантаження. Має відбуватися протягом перших 2,5 секунд після старту завантаження сторінки.
2. First Input Delay (FID) – показник інтерактивності. Має бути ≤ 0,1 секунди.
3. Cumulative Layout Shift (CLS) – показник візуальної стабільності. Має бути ≤ 0,1.

Загалом, усі три значення повинні знаходитися у «зеленій зоні». Вихід за її межі може впливати на позиції сторінки в пошуку.

1. Largest Contentful Paint (LCP)

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

Найчастіше такими елементами є:

• тег <video>,
• тег <img>,
• тег <image> всередині <svg>,
• елемент із CSS-властивістю background-image,
• атрибут poster у тезі <video>.

Той факт, що LCP визначає найбільший елемент, робить його ключовим для оцінки зручності користувача. Це новіший показник, що частково замінив First Contentful Paint (FCP), оскільки краще відображає, наскільки швидко завантажується саме той контент, який користувач хоче побачити в першу чергу.

LCP вимірює продуктивність завантаження і є проксі для багатьох старих метрик (час до отримання першого байта від сервера — TTFB, час завантаження DOM, час початку рендерингу, індекс швидкості).
Він не охоплює всю інформацію, яку давали ці показники окремо, але є більш зрозумілою метрикою, що добре відображає процес завантаження сторінки.

2. First Input Delay (FID)

Цей показник вимірює час між дією користувача (наприклад, натисканням на кнопку чи посилання) та моментом, коли браузер починає її обробку. Тобто, він визначає рівень інтерактивності сторінки.

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

Особливість FID у тому, що його неможливо змоделювати. Він залежить від реальних дій користувача та того, скільки часу знадобиться для обробки.

Основні причини проблем із FID:

• блокуючі CSS-стилі та JavaScript-скрипти,
• тривалі завдання в основному потоці (часто пов’язані з JavaScript).

При аналізі FID також важливо враховувати пов’язані критерії:

• Total Blocking Time (TBT),
• Time to Interactive (TTI).

3. Cumulative Layout Shift (CLS)

CLS оцінює візуальну стабільність сторінки, тобто наскільки зміщується (“стрибає”) контент під час завантаження нових елементів.

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

Причини зсувів макета:

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

Синтетичні інструменти vs. реальні показники

Один із ключових моментів для розуміння Core Web Vitals полягає в тому, що вони базуються на реальних показниках користувачів (RUM). Google використовує анонімні дані користувачів Chrome і робить їх доступними у звіті про досвід користувача Chrome (CrUX). Ці дані застосовуються для вимірювання трьох основних метрик і формування ранжування сайту. Ви можете переглянути CrUX-дані у Google Search Console вашого ресурсу.

Важливо відрізняти RUM від синтетичних інструментів, таких як Lighthouse. Останні запускають завантаження сторінок у змодельованих умовах (мережі та пристрої), а потім надають результати тесту. Проте вони не завжди відображають те, що відчувають реальні користувачі, і що Google враховує у своїх оцінках.

Наприклад, якщо ви запускаєте Lighthouse на потужному комп’ютері та отримуєте відмінні результати, це з великою ймовірністю не відповідає досвіду реальних відвідувачів вашого сайту.

• LCP залежить від стану мережі та потужності пристрою. Більшість користувачів можуть мати слабші пристрої, ніж очікується. Водночас іноді реальний досвід на мобільних пристроях кращий за показники Lighthouse. Наразі в GitHub-репозиторії Lighthouse триває обговорення зміни мобільних налаштувань.
• FID залежить від швидкодії процесора та того, як пристрій обробляє контент: зображення, елементи верстки та, насамперед, JavaScript.
• CLS простіше виміряти синтетично, адже він менше залежить від мережі та обладнання. Але тут є нюанси:
  • CLS вимірюється протягом усього часу взаємодії зі сторінкою. Тому змодельовані дані часто показують низький CLS, тоді як реальні користувачі отримують вищий показник через зрушення при прокручуванні або взаємодії.
  • CLS може змінюватися залежно від розміру вікна браузера. Тестові інструменти використовують стандартні розміри, але у реальних користувачів вони різні.
  • Користувачі бачать різний контент: cookie-банери, рекламні блоки, динамічні елементи. Це впливає на CLS на практиці.

CLS все ще розвивається. Команда Chrome працює над усуненням «невидимих» зрушень та інших факторів, які не повинні враховуватися. Це означає, що значення CLS можуть відрізнятися залежно від версії Chrome.

Як раніше формувалися показники веб-продуктивності

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

Найпопулярнішим безкоштовним інструментом онлайн-аудиту є PageSpeed Insights. Достатньо ввести URL-адресу сайту та натиснути «Аналізувати», після чого з’являться дві вкладки (для мобільних пристроїв та десктопів) з великою кількістю інформації.

Нагорі знаходиться рейтинг продуктивності Lighthouse.

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

Зараз оцінка продуктивності Lighthouse складається з шести показників, серед яких:

• First Contentful Paint (FCP),
• Speed Index (SI),
• Largest Contentful Paint (LCP),
• Time to Interactive (TTI),
• Total Blocking Time (TBT),
• Cumulative Layout Shift (CLS).

Варто врахувати, що кожен із цих шести показників має різну вагу. Наприклад, CLS, незважаючи на його важливість, становить лише близько 5% загальної оцінки Lighthouse.

Це означає, що сайт може отримати високу «зелену» оцінку Lighthouse і при цьому не відповідати пороговим значенням Core Web Vitals. Саме тому зараз варто зосередити зусилля на трьох головних метриках: LCP, FID та CLS.

Перейдемо до блоку «Дані спостережень» і отримаємо ще одну плутанину:

У цьому блоці First Contentful Paint (FCP) відображається разом із трьома Core Web Vitals, хоча формально до них не належить. Проте FCP завжди був одним із ключових показників і, ймовірно, залишиться важливим надалі.

Далі йде блок «Імітація завантаження сторінки», де відображаються шість показників, що формують оцінку продуктивності. Якщо натиснути на перемикач у правому верхньому кутку, з’явиться розширена інформація про ці метрики.

Як бачимо, сюди входять і LCP, і CLS, позначені синьою етикеткою як частина Core Web Vitals. Крім того, PageSpeed Insights надає калькулятор, де можна побачити вплив кожного показника на загальний бал і змоделювати, як зміни в певних метриках покращать результат.

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

Хоча Google трактує ці пункти як «рекомендації», а не критичні проблеми, на них варто звертати увагу. Діагностика дозволяє визначити елемент LCP і виявити зрушення, які вплинули на оцінку CLS, що дуже корисно при оптимізації сайту під Core Web Vitals.

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

Перегляд Core Web Vitals вашого сайту

Найшвидший спосіб перевірити Core Web Vitals для окремої сторінки — ввести її URL у PageSpeed Insights. Однак, щоб побачити картину по всьому сайту, потрібно скористатися Google Search Console. Для цього необхідно мати Google-акаунт та підтвердити право власності на сайт.

Звіт Core Web Vitals у Search Console показує зведену інформацію про відповідність сайту вимогам за останні 90 днів:

В ідеалі всі сторінки мають бути позначені зеленим кольором. Помаранчевий показник свідчить, що ви наближаєтеся до норми, але лише «зелена зона» враховується як успішне проходження критеріїв.

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

Перейшовши до будь-якого зі звітів, можна побачити:

• які показники не відповідають вимогам;
• які саме URL викликають проблему;
• можливість одразу перевірити сторінку у PageSpeed Insights для швидкого аудиту.

Після внесення змін до сайту варто повторно протестувати URL у PageSpeed Insights, щоб переконатися, що синтетичні дані відповідають нормі. Потім переходьте до наступних сторінок.

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

Звіт про користувальницький досвід Chrome (CrUX)

Причина цього в тому, що Core Web Vitals ґрунтується на даних Chrome User Experience Report (CrUX), які формуються з реальних користувацьких сесій за останні 21–28 днів.

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

Зворотна сторона цього процесу — дуже повільне оновлення даних. Це створює певну проблему зворотного зв’язку: ви вже виправили помилки, але результати ще довго не відображаються у звітах.

Додаткова інформація про дані CrUX

CrUX — це інструмент Chrome. Користувачі iOS-пристроїв та інших браузерів (Safari, Firefox, Opera, Edge тощо) не впливають на дані CrUX і, відповідно, на показники Core Web Vitals вашого сайту.

Водночас більшість користувачів дійсно працюють у Chrome, тому проблеми з продуктивністю, які фіксують інструменти Google, зазвичай відображаються й в інших браузерах.

Використана версія Chrome також має значення, адже всі критерії досі перебувають у процесі розвитку (зокрема, CLS).

Особливості CrUX:

• У нього потрапляють усі сторінки сайту, навіть ті, що мають тег <meta name="robots" content="noindex">. Такі сторінки можуть бути відсутні у пошуку Google, але все одно враховуватимуться у звітах.
• CrUX базується на переглядах сторінок. Тому найпопулярніші URL найбільше впливають на загальні показники.
• Сторінки можуть з’являтися або зникати з CrUX у міру досягнення або втрати порогових значень.

Таким чином, хоча ми вже знаємо, як збираються та аналізуються дані, залишається проблема повільного оновлення: доводиться чекати 21–28 днів, щоб зрозуміти, чи були ваші зміни ефективними.

Отримання миттєвих результатів про зміни в CrUX

На ринку є комерційні RUM-продукти, які дозволяють збирати дані швидше й детальніше, ніж CrUX.

Однак безкоштовно ви можете скористатися двома зручними інструментами від Google:

• Web Vitals Chrome Extension — розширення для браузера, яке показує ключові метрики у режимі реального часу.
• web-vitals — JavaScript-бібліотека для фронтенд-розробників, що дозволяє інтегрувати збір показників безпосередньо у ваш сайт.

Розширення Web Vitals Chrome Extension

Це простий і зрозумілий інструмент. Розглянемо процес його встановлення та приклад використання:

1. Перейдіть на сторінку розширення у веб-магазині Google.
2. Натисніть кнопку «Встановити» у верхньому правому кутку.
3. Через кілька секунд розширення з’явиться у вашому браузері Chrome.

Розширення відображається у вигляді квадратної іконки, яка може змінювати колір:

• Зелений — добрі показники Core Web Vitals.
• Червоний — погані показники.
• Сірий — показники недоступні.

Натиснувши на іконку, ви отримаєте більш детальні дані щодо конкретних метрик: LCP, FID та CLS.

JavaScript-бібліотека web-vitals

Це мінімалістична бібліотека вагою лише 1 КБ, створена для фронтенд-моніторингу. Вона дозволяє відстежувати показники у режимі близькому до реального часу з дуже високою точністю.

Її переваги:

• швидке отримання даних;
• точність вимірювань;
• легка інтеграція у проєкт.

Повний опис встановлення, використання та API доступний у документації web-vitals.

Я можу далі розписати головні функції цієї бібліотеки з прикладами коду (наприклад, як отримати значення LCP, FID і CLS прямо у консолі або відправити їх у систему аналітики). Хочеш, щоб я підготував ці приклади?

Встановлення та завантаження бібліотеки за допомогою npm

Встановлення web-vitals

Встановіть бібліотеку через npm:

npm install web-vitals

Існують дві версії бібліотеки: «стандартна» та «base + polyfill». Вибір залежить від того, які можливості вам потрібні. Детальний опис відмінностей є у документації.

1. Стандартна версія

Для використання достатньо імпортувати модулі з пакета web-vitals у ваш код:

import { getLCP, getFID, getCLS } from 'web-vitals';

getCLS(console.log);
getFID(console.log);
getLCP(console.log);

У цьому прикладі результати вимірювань будуть виводитися у консоль.

2. Базова версія з поліфілом

Цей варіант підключення складається з двох кроків.

Крок 1. Імпортуйте збірку з web-vitals/base:

import { getLCP, getFID, getCLS } from 'web-vitals/base';

Крок 2. Додайте у <head> вашої сторінки код поліфіла з dist/polyfill.js, який постачається разом із бібліотекою:

<!DOCTYPE html>
<html>
<head>
  <script>
    // Код із dist/polyfill.js
  </script>
</head>
<body>
  ...
</body>
</html>

Без поліфіла «базова» збірка не працюватиме коректно.

Встановлення та завантаження бібліотеки за допомогою CDN

Автори бібліотеки рекомендують встановлювати web-vitals через npm та інтегрувати у свій код. Проте якщо ви не використовуєте npm, можна підключити її через CDN.

Приклади нижче показують варіанти завантаження як для браузерів на базі Chromium (стандартна версія), так і для інших (базова версія з поліфілом).

Завантаження стандартної версії (через <script type="module">):

<script type="module">
import { getCLS, getFID, getLCP } from 'https://unpkg.com/web-vitals?module';

getCLS(console.log);
getFID(console.log);
getLCP(console.log);
</script>

Завантаження стандартної версії (через класичний <script>):

<script>
(function() {
  var script = document.createElement('script');
  script.src = 'https://unpkg.com/web-vitals';
  script.onload = function() {
    // Усі методи доступні у глобальному об'єкті webVitals
    webVitals.getCLS(console.log);
    webVitals.getFID(console.log);
    webVitals.getLCP(console.log);
  }
  document.head.appendChild(script);
}())
</script>

Завантаження базової версії з поліфілом:

<!DOCTYPE html>
<html>
<head>
  <script>
    // Вставте код із https://unpkg.com/web-vitals/dist/polyfill.js тут
  </script>
</head>
<body>
  ...
  <!-- Завантаження UMD-версії "базового складання" -->
  <script>
  (function() {
    var script = document.createElement('script');
    script.src = 'https://unpkg.com/web-vitals';
    script.onload = function() {
      webVitals.getCLS(console.log);
      webVitals.getFID(console.log);
      webVitals.getLCP(console.log);
    }
    document.head.appendChild(script);
  }())
  </script>
</body>
</html>

Хочеш, я додам приклади, як зібрані дані Core Web Vitals можна відправляти у Google Analytics чи інші системи аналітики прямо з цих скриптів?

Використання

Кожна метрика Web Vitals реалізована як окрема функція, яка приймає колбек onReport. Цей колбек викликається кожного разу, коли значення метрики стає доступним і готовим до відправки.

У прикладі нижче вимірюються всі три основні показники, і як тільки вони готові — виводяться в консоль:

import { getCLS, getFID, getLCP } from 'web-vitals';

getCLS(console.log);
getFID(console.log);
getLCP(console.log);

Якщо значення не з’являються одразу, спробуйте перезавантажити сторінку або перемкнутися між вкладками.

Колбек може ніколи не викликатися у таких випадках:

• FID не буде отримано, якщо користувач не взаємодіяв зі сторінкою.
• FCP, FID та LCP не будуть доступні, якщо сторінка завантажувалась у фоновому режимі.

Колбек може викликатися кілька разів:

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

Отримання значення при кожній зміні

У більшості випадків колбек потрібен лише тоді, коли є фінальне значення. Проте можна отримувати результат при кожній зміні, передавши другий аргумент reportAllChanges: true.

import { getCLS } from 'web-vitals';

// Виводить значення CLS при кожному зсуві макету
getCLS(console.log, true);

Це зручно для налагодження, але у продакшені зазвичай не використовується.

Отримання лише дельти змін

Якщо ваша аналітика не дозволяє оновлювати значення метрики після відправки, можна надсилати лише дельту (різницю між новим і попереднім значенням).

import { getCLS, getFID, getLCP } from 'web-vitals';

function logDelta({ name, id, delta }) {
  console.log(`Різниця для ${name} (ID ${id}): ${delta}`);
}

getCLS(logDelta);
getFID(logDelta);
getLCP(logDelta);

Надсилання результатів до аналітики

Результати можна відправляти на будь-яку кінцеву точку. У прикладі нижче функція sendToAnalytics() використовує navigator.sendBeacon(), а якщо він недоступний — повертається до fetch():

import { getCLS, getFID, getLCP } from 'web-vitals';

function sendToAnalytics(metric) {
  const body = JSON.stringify(metric);
  const url = '/analytics';

  if (navigator.sendBeacon) {
    navigator.sendBeacon(url, body);
  } else {
    fetch(url, { body, method: 'POST', keepalive: true });
  }
}

getCLS(sendToAnalytics);
getFID(sendToAnalytics);
getLCP(sendToAnalytics);

Таким чином можна збирати й передавати показники Core Web Vitals у свою систему аналітики в реальному часі.

Надсилання результатів у Google Analytics

Щоб відстежувати Core Web Vitals у Google Analytics, варто встановити унікальне значення параметра (наприклад, id метрики) для кожного екземпляра. Це дозволить створювати власні звіти через Google Data Studio або API.

Як приклад, можна використати Web Vitals Report — безкоштовний інструмент з відкритим кодом для візуалізації метрик Web Vitals у Google Analytics.

Щоб використовувати готовий звіт або створювати власні візуалізації, потрібно надсилати дані в Google Analytics. Нижче наведено приклади для різних підходів.

Використання analytics.js

import { getCLS, getFID, getLCP } from 'web-vitals';

function sendToGoogleAnalytics({ name, delta, id }) {
  // Передбачається, що глобальна функція ga() вже підключена
  ga('send', 'event', {
    eventCategory: 'Web Vitals',
    eventAction: name,
    // id — унікальне для поточного завантаження сторінки
    eventLabel: id,
    // Значення GA мають бути цілими числами
    // Для CLS множимо на 1000 для точності
    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),
    noInteraction: true,
    transport: 'beacon'
  });
}

getCLS(sendToGoogleAnalytics);
getFID(sendToGoogleAnalytics);
getLCP(sendToGoogleAnalytics);

Використання gtag.js (Universal Analytics)

import { getCLS, getFID, getLCP } from 'web-vitals';

function sendToGoogleAnalytics({ name, delta, id }) {
  // Передбачається, що глобальна функція gtag() вже підключена
  gtag('event', name, {
    event_category: 'Web Vitals',
    event_label: id,
    // CLS множимо на 1000 для кращої точності
    value: Math.round(name === 'CLS' ? delta * 1000 : delta),
    non_interaction: true
  });
}

getCLS(sendToGoogleAnalytics);
getFID(sendToGoogleAnalytics);
getLCP(sendToGoogleAnalytics);

Таким чином можна збирати дані Core Web Vitals у GA і використовувати їх для створення власних звітів або дашбордів.

Використання gtag.js (Google Analytics 4)

Google Analytics 4 працює за новою моделлю подій, яка дозволяє використовувати довільні параметри замість фіксованих категорій, дій та міток. GA4 також підтримує нецілочисельні значення, що спрощує вимірювання Web Vitals у порівнянні з попередніми версіями.

import { getCLS, getFID, getLCP } from 'web-vitals';

function sendToGoogleAnalytics({ name, delta, value, id }) {
  // Передбачається, що глобальна функція gtag() вже підключена
  gtag('event', name, {
    // Вбудовані параметри
    value: delta, // Використовується delta, щоб значення можна було підсумовувати

    // Кастомні параметри
    metric_id: id,       // потрібен для агрегації подій
    metric_value: value, // необов’язково
    metric_delta: delta  // необов’язково
  });
}

getCLS(sendToGoogleAnalytics);
getFID(sendToGoogleAnalytics);
getLCP(sendToGoogleAnalytics);

Надсилання результатів у Google Tag Manager

Ще один зручний спосіб — використати Google Tag Manager. Для цього існує готовий шаблон тегу Core Web Vitals, який дозволяє інтегрувати збір даних у GA4.

Детальну інструкцію зі встановлення можна знайти у цьому матеріалі.

Висновок

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

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

JavaScript-бібліотека web-vitals дає можливість швидко отримувати показники й підключати їх до аналітики, що значно спрощує контроль і оптимізацію веб-продуктивності.

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