Core Web Vitals і Page Experience
Core Web Vitals — набір метрик, що вимірюють реальний користувацький досвід щодо завантаження, інтерактивності та візуальної стабільності сторінки. Google наполегливо радить домагатися добрих значень для успіху в пошуку. Часто пишуть «з 2021 року — офіційний фактор ранжування»; документація формулює точніше й обережніше, і від цієї точності залежить, скільки зусиль варто вкладати. Нижче — пороги, джерела даних, прийоми поліпшення та те, що Google прямо каже про значення page experience для ранжування.
Основа — сторінки Google про Core Web Vitals і page experience, а також посібники web.dev щодо метрик.
Три метрики й пороги
| Метрика | Що вимірює | Орієнтир Google |
|---|---|---|
| LCP Largest Contentful Paint | швидкість завантаження | у перші 2,5 секунди після початку завантаження |
| INP Interaction to Next Paint | чутливість до дій | менше 200 мілісекунд |
| CLS Cumulative Layout Shift | візуальна стабільність | менше 0,1 |
Документація радить прагнути цих значень. Як їх оцінювати, пояснює web.dev: щоб значення були досягнуті для більшості користувачів, треба вимірювати 75-й процентиль завантажень сторінки окремо для мобільних і настільних пристроїв, а сторінка проходить оцінку, якщо вклалася в цілі за всіма трьома метриками. Метрики змінюються: INP став стабільною метрикою у 2024 році й замінив FID. Тому FID у сучасному списку немає.
Що Google каже про ранжування
Тут найбільше хибних уявлень. Зі сторінки про page experience:
- Єдиного сигналу page experience немає: основні системи ранжування дивляться на різні сигнали, що відповідають загальному досвіду на сторінці;
- Core Web Vitals використовуються системами ранжування, але добрі значення у звітах не гарантують верхніх позицій, а ганятися за ідеальним результатом заради SEO — не найкраща витрата часу;
- Інші аспекти page experience, окрім Core Web Vitals, напряму не допомагають піднятися в результатах, хоча роблять сайт приємнішим і узгоджуються з тим, що системи прагнуть винагороджувати;
- Google завжди прагне показати найрелевантніший контент, навіть якщо досвід на сторінці посередній. Але для багатьох запитів корисного контенту багато, і тоді добрий досвід може сприяти успіху.
Тому «HTTPS — обовʼязковий для ранжування» й «адаптивність як сигнал ранжування» — не те, що написано в документації. У ній це питання самооцінки: добрі Core Web Vitals, безпечна передача, зручне відображення на мобільних, відсутність надмірної реклами та навʼязливих інтерстиціалів, чітке відрізнення основного контенту від решти. Системи оцінюють сторінки здебільшого по кожній сторінці окремо, але є й сайтові оцінки.
Дані: польові й лабораторні
Core Web Vitals — передусім польові метрики. Польові дані збирає Chrome User Experience Report; він живить PageSpeed Insights, Chrome DevTools і звіт Core Web Vitals у Search Console. Лабораторні вимірювання потрібні під час розробки: вони найкраще підходять, щоб перевіряти функції до випуску й ловити регресії. Вони не замінюють польових даних, бо умови тестування відрізняються від реальних користувачів. Наш аналізатор сторінки показує лабораторні LCP і CLS та, якщо вони є, польові LCP, INP і CLS для сторінки й для всього сайту з PageSpeed Insights.
Як поліпшувати
- LCP. Ніколи не відкладайте завантаження зображення LCP (lazy loading): це завжди створює непотрібну затримку й погіршує LCP. Пріоритет задається підказкою fetchpriority. Нерідко «lazy loading» радять як прийом прискорення LCP, і для головного зображення це хибно. Про зображення — урок про SEO зображень;
- CLS. Завжди вказуйте атрибути ширини й висоти в зображень і відео або резервуйте місце через CSS aspect-ratio;
- INP. Одна з частих причин — довгі задачі JavaScript. Допомагає поступатися головним потоком: розбивати довгі задачі й віддавати керування одразу після обробника події, що змінює інтерфейс. Докладніше — в посібнику web.dev з оптимізації INP; про скрипти — в уроці про JavaScript і SEO.
Чого в документації немає
- «Офіційного фактора ранжування з 2021 року»: Google каже, що Core Web Vitals використовуються системами ранжування поряд з іншими аспектами досвіду;
- HTTPS і адаптивності як прямих «сигналів ранжування»;
- «lazy loading» як способу прискорити LCP;
- цифр на кшталт «bounce rate знизився на 18%» як наслідків оптимізації: це дані одного сайту.
Як перевірити сайт
- Відкрийте звіт Core Web Vitals у Search Console й знайдіть групи сторінок із поганими значеннями.
- Для важливих сторінок отримайте звіт в аналізаторі сторінки: польові дані й лабораторні вузькі місця.
- Оцінюйте мобільні й настільні значення окремо, як радить web.dev.
- Знайдіть шаблони, що повторюються на багатьох сторінках: виправлення шаблону поліпшує всі його сторінки. Список сторінок — краулер.
- Після змін зачекайте на накопичення польових даних: вони рахуються за реальними користувачами, а не одразу.
Чек-лист
- LCP у перші 2,5 секунди, INP менше 200 мс, CLS менше 0,1 на 75-му процентилі.
- Головне зображення не відкладається, у картинок і відео задані розміри.
- Довгі задачі JavaScript розбито.
- Дивлюся польові дані, а не лише лабораторні.
- Мобільні й настільні дані оцінюються окремо.
- Page experience оцінюється цілком, а не за однією метрикою.
Помилки
- Вважати Core Web Vitals єдиним фактором і ганятися за ідеальним балом заради SEO.
- Відкладати завантаження головного зображення.
- Оцінювати лише лабораторні дані.
- Не вказувати розміри зображень.
- Оптимізувати FID, а не INP.
Що далі
Останній урок модуля — переїзд сайту: як зберегти результати за зміни адрес. Дані для розширених результатів — в уроці про структуровані дані.