Core Web Vitals для початківців: що це, пороги й що можна виправити

Core Web Vitals (основні показники вебу) — це набір метрик, які описують досвід реальної людини на сторінці. Їх визначає команда Chrome, а Google Search Central включає їх до опису зручності сторінки (page experience). Метрик три, і кожна відповідає за свій аспект.

• LCP (Largest Contentful Paint) показує, за який час з'явився найбільший видимий елемент: зазвичай головне зображення, відео-постер або великий блок тексту.
• INP (Interaction to Next Paint) вимірює, як швидко сторінка відповідає візуально на кліки, дотики й натискання клавіш упродовж усього перебування на ній.
• CLS (Cumulative Layout Shift) підсумовує непередбачувані зсуви вмісту: коли кнопка раптом відсувається в момент натискання, це і є поганий CLS.

У березні 2024 року INP замінив у списку Core Web Vitals показник FID (First Input Delay). Якщо ви бачите стару статтю, де третя метрика — FID, вона застаріла. Подробиці й визначення є на web.dev та в документації Google Search Central.

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

Для кожної метрики задано три діапазони: хороший, такий, що потребує покращення, і поганий. Орієнтуйтеся на таблицю з web.dev.

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

Звідси два практичні висновки. По-перше, одиничний швидкий тест на вашому ноутбуці нічого не доводить: у відвідувачів інші пристрої, мережі й відстані до сервера. По-друге, достатньо покращити «хвіст» повільних відвідувань, щоб зсунути 75-й перцентиль, тому корисно дивитися на мобільні пристрої та слабкі мережі, а не лише на власний комп'ютер.

TTFB (час до першого байта) і FCP (перший відображений вміст) не входять до Core Web Vitals, проте допомагають шукати причину повільного LCP.

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

Польові дані збирають із реальних відвідувань користувачів Chrome. Вони потрапляють у звіт Chrome UX Report (CrUX), який показує PageSpeed Insights, а також у звіт Core Web Vitals у Google Search Console. Саме польові дані дають остаточний вердикт, бо відображають реальний досвід. Мінус: для нових або малотрафікових сторінок даних може просто не бути.

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

Практичне правило таке:

1. Вердикт за Core Web Vitals беріть з польових даних.
2. Причини шукайте в лабораторних інструментах.
3. Після виправлення чекайте, поки польові дані оновляться: звіти CrUX агрегують період у кілька тижнів, тож результат з'являється не одразу.

Якщо польових даних немає, це не помилка сайту. Це означає, що відвідувань замало для статистики.

Спершу визначте, що саме є LCP-елементом сторінки. У PageSpeed Insights і в панелі Performance в Chrome DevTools він позначений. Найчастіше це головне зображення або великий заголовок.

Далі працюйте з типовими причинами повільного LCP:

• Важке зображення. Стисніть його, віддавайте сучасний формат (WebP або AVIF) і задавайте розмір, що відповідає реальному відображенню. Атрибут srcset дозволяє мобільним пристроям завантажувати меншу версію.
• Відкладене завантаження головного зображення. Атрибут loading="lazy" потрібен для картинок нижче першого екрана. Для LCP-зображення його ставити не слід, інакше браузер почне його завантаження пізніше.
• Скрипти й стилі, що блокують відображення. Великий CSS і синхронні скрипти в head затримують перший показ. Виносьте некритичне, додавайте defer до скриптів.
• Повільна відповідь сервера. Якщо сервер довго готує HTML, жодна оптимізація зображень не допоможе. Перевірте кешування, стиснення (gzip або Brotli) і, за потреби, CDN.

Приклад розмітки, де головне зображення вантажиться одразу, а друге відкладено:

<img src="/images/hero.webp" width="1200" height="630" alt="Огляд звіту" fetchpriority="high">
<img src="/images/chart.webp" width="800" height="450" alt="Графік" loading="lazy">

Атрибут fetchpriority="high" підказує браузеру, що це зображення важливе. Він не чарівний, але для LCP-картинки є розумним вибором.

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

З чого почати:

• Знайдіть довгі завдання. У панелі Performance в Chrome DevTools вони позначені червоним. Розбийте великі обчислення на менші частини, щоб головний потік міг між ними обробляти введення.
• Перевірте сторонні скрипти. Віджети чатів, аналітика, рекламні теги й A/B-інструменти часто виконують багато роботи на головному потоці. Приберіть ті, які не приносять користі, а решту завантажуйте пізніше.
• Спростіть обробники подій. Клік не має запускати важкі обчислення синхронно. Покажіть візуальну відповідь одразу, а решту роботи відкладіть.
• Врахуйте вартість гідратації. У застосунках на сучасних фреймворках початкове «оживлення» сторінки може займати значний час. Менше JavaScript на сторінці означає швидшу реакцію.

Якщо сайт майже без скриптів, проблем з INP зазвичай немає. На сторінках з великою кількістю інтерактиву він, навпаки, часто стає найслабшою метрикою. Деталі описано на web.dev про INP.

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

• Зображення й відео без розмірів. Задавайте width і height або CSS-властивість aspect-ratio, щоб браузер зарезервував місце ще до завантаження файлу.
• Реклама, банери й вбудовані віджети. Заздалегідь визначте для них контейнер із фіксованою мінімальною висотою.
• Шрифти. Коли вебшрифт замінює запасний, текст може змінити розмір і «зсунути» сторінку. Підбирайте запасний шрифт зі схожими метриками й обирайте розумну стратегію font-display.
• Вміст, що вставляється зверху. Банери згоди, плашки з акціями й підказки, які з'являються над уже показаним текстом, штовхають його вниз. Додавайте такі елементи поверх вмісту (наприклад, закріпленою панеллю) або зарезервуйте для них місце.

Приклад CSS, що резервує місце під вбудований блок:

<div style="aspect-ratio: 16 / 9; min-height: 240px;">
  <iframe src="https://example.com/embed" width="640" height="360" title="Вбудований блок"></iframe>
</div>

Після змін перевірте сторінку на повільній мережі й вузькому екрані: саме там зсуви помітні найбільше.

Вам не потрібен десяток платних сервісів. Для старту достатньо чотирьох безкоштовних засобів.

1. PageSpeed Insights. Показує польові дані CrUX для сторінки (якщо їх достатньо) і лабораторний звіт Lighthouse з підказками. Відмінна відправна точка.
2. Звіт Core Web Vitals у Google Search Console. Групує адреси вашого сайту за статусами для мобільних і десктопних пристроїв та показує, де саме проблема.
3. Панель Performance в Chrome DevTools. Підходить для налагодження: видно довгі завдання, LCP-елемент і зсуви.
4. Бібліотека web-vitals. Невеликий JavaScript-код, який збирає LCP, INP і CLS у реальних відвідувачів вашого сайту. Корисна, коли хочете власну статистику, а не лише CrUX.

Порада щодо порядку дій: спершу відкрийте звіт у Search Console, знайдіть групу проблемних адрес, потім перевірте типову сторінку з групи в PageSpeed Insights і лише тоді занурюйтеся в DevTools. Так ви виправляєте шаблон, а не окрему сторінку, і один виправлений шаблон покращує багато адрес одразу.

Не забувайте, що Core Web Vitals — лише частина технічного стану сайту. Загальний огляд проблем, які варто перевірити, зібрано в чекліст технічного SEO. Суміжні теми: заголовки безпеки й SEO та структуровані дані JSON-LD.

Скажемо прямо: сканер SEOAudit пасивний і Core Web Vitals не вимірює. Він не запускає сторінку в браузері, не виконує JavaScript і не збирає дані реальних відвідувачів. У звіті польові дані Core Web Vitals позначені як непідтримувані (не оцінені) і ніколи не показуються як «пройдено». Сканер також не вираховує LCP, CLS чи FCP за часом відповіді сервера, бо така оцінка була б вигаданою.

Натомість він повідомляє про непрямі ознаки, які часто пов'язані з поганими показниками:

• час відповіді однієї головної сторінки (це не вимірювання Core Web Vitals);
• розмір HTML-документа;
• зображення без ширини й висоти (ризик зсуву макета, а не виміряний CLS);
• застарілі формати зображень і відсутній srcset;
• відкладене завантаження першого зображення;
• скрипти в head, що блокують відображення, і велика кількість файлів CSS та JS;
• кількість сторонніх хостів і відсутність preconnect;
• спосіб підключення вебшрифтів, оголошений у HTML;
• стиснення, HTTP/2 і заголовки кешування.

Використовуйте це як список ймовірних причин. Запустіть безкоштовний сканер, знайдіть підказки, а потім підтвердіть вплив у PageSpeed Insights і Search Console. Що саме входить у SEO-перевірку, описано на сторінці SEO-аудиту. Перевірки безпеки, які сканер виконує тим самим запитом, описані на сторінці перевірки безпеки, а готовність до ШІ-пошуку розглянуто на сторінці ШІ-видимості.