Core Web Vitals простими словами: LCP, INP і CLS

Core Web Vitals — це не тест на характер вашого сайту

До Core Web Vitals часто ставляться як до загадкової системи оцінювання. Сторінка отримує червоне число, хтось публікує скриншот у Slack, і команда починає сперечатися про JavaScript-фреймворки.

Це не надто корисно.

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

• Основний контент з’являється занадто довго.
• Сторінка повільно реагує, коли користувач намагається щось зробити.
• Макет стрибає, поки користувач читає або натискає.

Це і є три Core Web Vitals: LCP, INP і CLS.

Google використовує їх як частину сигналів page experience, але SEO — не найкраща причина звертати на них увагу. Краща причина в тому, що повільні, нестабільні й нечутливі сторінки марнують час користувачів. Вони також зазвичай гірше конвертують, створюють більше проблем для підтримки й швидше старіють.

Три метрики в одному реченні кожна

Перш ніж перейти до деталей, ось версія простими словами:

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

Звичні порогові значення такі:

| Metric | Good | Needs improvement | Poor | |---|---:|---:|---:| | LCP | 2.5s або швидше | 2.5s–4.0s | Понад 4.0s | | INP | 200ms або швидше | 200ms–500ms | Понад 500ms | | CLS | 0.1 або нижче | 0.1–0.25 | Понад 0.25 |

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

Якщо ви дивитеся на автоматизований звіт і не знаєте, з чого почати, корисно відділити діагностику від паніки. У нас є окремий посібник про те, як читати звіт Lighthouse без паніки, де цей процес описано докладніше.

LCP: коли сторінка здається завантаженою?

Largest Contentful Paint вимірює час рендерингу найбільшого видимого елемента контенту у viewport. На практиці це часто:

• hero-зображення,
• великий заголовок,
• зображення головної статті,
• зображення товару,
• великий блок тексту.

LCP не питає, коли завершили завантаження всі скрипти, tracking pixel і зображення нижче першого екрана. Він питає: коли головна річ, заради якої користувач прийшов, стала видимою?

Саме тому LCP людяніша метрика, ніж старомодний “page load time”. Сторінка може технічно завершити завантаження пізно, але все одно відчуватися швидкою, якщо основний контент з’являється швидко. І навпаки: сторінка може викликати load event, поки hero-секція досі порожня, розмита або заблокована затримкою рендерингу.

Поширені причини поганого LCP

Більшість проблем із поганим LCP виникає з кількох передбачуваних місць:

1. Повільна відповідь сервера

Якщо HTML-документ приходить із запізненням, усе інше теж починається із запізненням.

1. CSS або JavaScript, що блокують рендеринг

Браузер уже має контент, але ще не може його намалювати.

1. Неоптимізовані hero-зображення

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

1. Web fonts затримують рендеринг тексту

Великий заголовок може бути LCP-елементом, а завантаження шрифту може затримувати або візуально змінювати його.

1. Затримки client-side rendering

Якщо сторінці потрібен великий JavaScript-бандл, перш ніж вона може показати змістовний контент, LCP погіршується.

Як покращити LCP

Почніть із фактичного LCP-елемента. Не оптимізуйте випадкові ресурси, доки не зрозумієте, що саме вимірює браузер.

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

• Віддавайте HTML швидко: кешуйте там, де доречно, зменшуйте роботу бекенду, уникайте повільних редиректів.
• Оптимізуйте LCP-зображення: використовуйте правильні розміри, стиснення і формат.
• Не застосовуйте lazy-loading до hero-зображення над згином.
• Обережно використовуйте fetchpriority="high" для основного зображення, коли воно справді є пріоритетом.
• Інлайньте critical CSS лише тоді, коли це суттєво зменшує затримку рендерингу.
• Зменшуйте JavaScript, потрібний до першого змістовного рендерингу.
• Використовуйте font-display: swap або іншу свідому стратегію для шрифтів.

Зображення і шрифти часто винні. Для зображень компроміс — це не просто “малий файл добре”. Вибір формату, зусилля на кодування і підтримка браузерами теж важливі, тому ми підтримуємо практичне дерево рішень про те, коли AVIF перемагає WebP, а коли ні. Для сторінок із великою кількістю тексту web fonts досі залишаються одним із найпростіших виграшів у продуктивності, бо багато сайтів відправляють більше файлів шрифтів, ніж використовують.

INP: чи реагує сторінка на дотик?

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

До взаємодій належать, наприклад:

• клік по кнопці,
• натискання меню,
• вибір checkbox,
• введення тексту в поле форми,
• відкриття accordion.

INP замінив First Input Delay як Core Web Vital у 2024 році. Це була добра зміна. First Input Delay дивився лише на першу взаємодію. INP ширший: він враховує взаємодії протягом усього відвідування сторінки й повідомляє взаємодію з високою затримкою як оцінку чутливості сторінки.

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

Ви, ймовірно, користувалися такою сторінкою. Вона здається готовою. Ви натискаєте меню. Пів секунди нічого не відбувається. Ви натискаєте ще раз. Потім дві речі трапляються одночасно. Це проблема INP.

Поширені причини поганого INP

INP зазвичай є проблемою main thread. Браузер хоче відповісти, але JavaScript, робота рендерингу або розрахунок макета заважають.

Типові причини:

• великі JavaScript-бандли,
• дорогі event handlers,
• робота hydration у client-rendered apps,
• сторонні скрипти, що конкурують за main thread,
• довгі задачі після завантаження сторінки,
• складні DOM-оновлення, спричинені малими взаємодіями,
• layout thrashing, коли код багаторазово читає і записує значення макета.

Маркетингові теги, аналітика, chat widgets і consent banners — усе це може впливати. Це не означає “видаліть усе”. Це означає, що кожен скрипт на сторінці має ціну, і затримка взаємодії часто показує, де ця ціна стає видимою.

Як покращити INP

Покращення INP — це не про один магічний атрибут, а радше про зменшення конкуренції за main thread.

Корисні підходи:

• Розбивайте довгі JavaScript-задачі на менші частини.
• Відкладайте несуттєву роботу до моменту, коли сторінкою вже можна користуватися.
• Видаляйте невикористаний JavaScript, а не лише мінімізуйте його.
• Тримайте event handlers малими й передбачуваними.
• Уникайте повторного рендерингу великих частин інтерфейсу через дрібні зміни стану.
• Використовуйте CSS для простих візуальних станів, де це можливо.
• Аудитуйте сторонні скрипти й завантажуйте їх лише там, де вони потрібні.

Також подивіться на дизайн взаємодій. Кнопка, яка дає миттєвий візуальний зворотний зв’язок, може відчуватися більш чутливою, навіть якщо подальша робота триває довше. Це не заміна продуктивності, але частина хорошої інженерії інтерфейсів. Наш checklist для доступних web buttons перетинається з цим: зрозумілі стани, правильна семантика і передбачувана поведінка допомагають і користувачам, і браузерам.

CLS: чи залишається сторінка там, де очікує користувач?

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

CLS вимірюється не в секундах. Це оцінка на основі того, скільки контенту змістилося і наскільки далеко він змістився. Нижче — краще.

Ключове слово — неочікуваний. Зміни макета, спричинені дією користувача, зазвичай не рахуються так само. Якщо хтось натискає «показати більше» і контент розгортається, це очікувано. Якщо newsletter banner з’являється вгорі через три секунди й зсуває все вниз, це неочікувано.

Поширені причини поганого CLS

Провали CLS часто буденні:

• зображення без атрибутів width і height,
• реклама або embeds без зарезервованого місця,
• cookie banners, вставлені над контентом,
• web fonts, що підміняються з іншими метриками,
• пізно завантажені promotional bars,
• динамічно вставлений контент біля верху сторінки.

Виправлення зазвичай полягає в тому, щоб зарезервувати простір до появи контенту. Браузер має знати форму сторінки якомога раніше.

Як покращити CLS

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

Потім застосуйте нудні виправлення:

• Додайте явні атрибути width і height до зображень.
• Використовуйте CSS aspect-ratio для responsive media containers.
• Резервуйте фіксований або мінімальний простір для реклами, embeds і iframes.
• Уникайте вставлення банерів над наявним контентом після завантаження.
• Вибирайте fallback-шрифти з метриками, схожими на фінальний шрифт.
• Уникайте анімацій, які змінюють властивості макета на кшталт top, left, width або height; надавайте перевагу transforms.

CLS — одна з небагатьох метрик продуктивності, де дисципліна перемагає хитрість. Якщо сторінка має стабільні блоки, вона зазвичай отримує добру оцінку.

Field data і lab data корисні, але відповідають на різні запитання

Поширене джерело плутанини — різні інструменти показують різні числа. Це нормально.

Field data надходять від реальних користувачів. Вони відображають справжні пристрої, мережі, локації й умови браузера. Google’s Chrome User Experience Report — приклад field data.

Lab data надходять із контрольованого тестового середовища. Lighthouse — знайомий приклад. Вони повторювані й корисні для debugging, але це не те саме, що реальний досвід ваших користувачів.

Використовуйте field data, щоб зрозуміти, чи справді користувачі мають проблему. Використовуйте lab data, щоб відтворити й debug цю проблему.

Також пам’ятайте, що Core Web Vitals зазвичай оцінюються для окремого URL або групи URL, а не як одна абстрактна властивість вашого бренду. Ваша головна сторінка, стаття в блозі, сторінка цін і checkout можуть мати дуже різні вузькі місця.

Розумний порядок роботи

Якщо всі три метрики погані, виникає спокуса почати всюди. Не піддавайтеся.

Практичний порядок такий:

1. Спершу виправте очевидний CLS

Відсутні розміри зображень і нестабільні банери часто дають швидкі перемоги.

1. Покращіть LCP для важливих шаблонів

Зосередьтеся на сторінках, які мають значення: сторінки товарів, landing pages, статті, sign-up flows.

1. Дослідіть INP на реальних взаємодіях

Натискайте те, що користувачі справді натискають. Меню, фільтри, форми й checkout controls часто показують більше, ніж початковий trace завантаження.

1. Аудитуйте сторонні скрипти

Залишайте ті, що виправдовують свою ціну. Видаляйте або відкладайте ті, що не виправдовують.

1. Встановіть performance budget

Без бюджету покращення продуктивності деградують. Нові скрипти, зображення і дизайн-компоненти тихо скасують виконану роботу.

Важлива думка: не оптимізуйте заради badge. Оптимізуйте заради user journey. Незначне покращення оцінки на сторінці з малим трафіком може бути менш важливим, ніж трохи недосконала, але значно швидша взаємодія в checkout.

<!-- tool-cta:start -->

💡 Спробуйте це: Оскільки LCP зазвичай є проблемою із зображенням, зменште розмір основного зображення за допомогою Image Compressor як першу просту перемогу.

<!-- tool-cta:end -->

Чого Core Web Vitals вам не скажуть

Core Web Vitals корисні, але неповні.

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

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

Ставтеся до LCP, INP і CLS як до димових датчиків. Коли вони спрацьовують — розслідуйте. Коли вони мовчать — продовжуйте підтримувати будівлю.