Що означають LCP, INP і CLS?

Це три метрики Core Web Vitals, за якими Google оцінює досвід користувача на сторінці. Largest Contentful Paint (LCP) вимірює завантаження: за який час з'являється основний вміст. Interaction to Next Paint (INP) вимірює чуйність: як швидко сторінка реагує на клік, дотик або введення тексту. Cumulative Layout Shift (CLS) вимірює візуальну стабільність: наскільки сильно «стрибає» макет. Хороші значення: LCP не більше 2.5 секунди, INP не більше 200 мілісекунд, CLS не більше 0.1.

Три метрики коротко

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

LCP: Largest Contentful Paint

LCP — це час від початку завантаження сторінки до моменту, коли в видимій області відрендерено найбільше зображення, відео або текстовий блок. До відповідних елементів належать <img>, зображення всередині SVG, постер або перший кадр відео, фонові зображення CSS і блоковий текст. Щойно відвідувач взаємодіє зі сторінкою, браузер перестає шукати нових кандидатів. Повільний LCP зазвичай спричиняють повільна відповідь сервера, велике або пізно виявлене головне зображення, а також CSS і скрипти, що блокують рендеринг.

INP: Interaction to Next Paint

INP відстежує кліки, дотики й натискання клавіш упродовж візит��� та вимірює, скільки минає часу, поки браузер зможе відмалювати наступний кадр. Наведення курсора, прокручування й масштабування не враховуються. Повідомлене значення — це найповільніша взаємодія, а на сторінках із великою кількістю взаємодій поодинокі викиди ігноруються. У березні 2024 року INP замінив First Input Delay (FID) у складі Core Web Vitals: FID враховував лише першу взаємодію, а INP охоплює весь візит. Поганий INP зазвичай виникає через довгі завдання JavaScript, які тримають головний потік зайнятим.

CLS: Cumulative Layout Shift

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

Звідки беруться дані?

Звіт Core Web Vitals у Search Console використовує польові дані з Chrome UX Report: реальні візити в Chrome за останні 28 днів, згруповані за наборами схожих сторінок, причому кожну групу оцінюють за найгіршою метрикою. Лабораторні інструменти на кшталт Lighthouse завантажують сторінку без реального відвідувача, тому не можуть виміряти INP і використовують Total Blocking Time як замінник, про що йдеться в огляді Web Vitals на web.dev. Лабораторні показники варто використовувати для налагодження, а польові дані — як остаточний вердикт.

Чи впливають Core Web Vitals на ранжування?

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

Як допомагає AutoPSEO

Звіт Core Web Vitals в AutoPSEO зчитує історію Chrome UX Report для всього сайту або окремого URL окремо для телефонів, десктопів і планшетів та показує на графіках LCP, INP і CLS (а також first contentful paint і time to first byte) на 75-му перцентилі за приблизно шість місяців щотижневих даних, тож ви бачите, коли метрика почала погіршуватися.