WebEngine

0%
WebEngine
SEO та аналітика

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

Що вимірюють Core Web Vitals, які значення вважаються добрими і що конкретно робити, щоб їх виправити. З реальними прикладами оптимізації.

Pavlo8 хв читання

PageSpeed Insights показує 97 на десктопі й 41 на мобільному, а звіт Core Web Vitals у Search Console світиться червоним — і незрозуміло, що з цим робити першим. Розберемо три метрики без термінології: що саме кожна вимірює, які значення Google вважає добрими, що їх ламає найчастіше і в якому порядку це лагодити, щоб не витратити тиждень на пункт, який дасть 0.1 секунди.

2.5с

LCP — межа «добре»

200мс

INP — межа «добре»

0.1

CLS — межа «добре»

75%

користувачів мають вкластися в межу

Що вимірюють три метрики

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

МетрикаДобреПотребує увагиПоганоЩо відчуває людина
LCPдо 2.5 с2.5–4.0 спонад 4.0 сДовго не видно головного блоку
INPдо 200 мс200–500 мспонад 500 мсНатиснув — нічого не сталося
CLSдо 0.10.1–0.25понад 0.25Контент стрибнув, промахнувся по кнопці
Пороги оцінюються за 75-м перцентилем реальних візитів за останні 28 днів.

LCP: чому головний блок з’являється повільно

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

  • Повільна відповідь сервера. Якщо TTFB більший за 800 мс, решта оптимізацій не врятує. Причина — важкий запит до бази, відсутність кешу або хостинг, який ділить ядро на 40 сайтів.
  • Величезна картинка героя. JPEG на 2.4 МБ у слоті шириною 900 px — класика. WebP або AVIF у трьох розмірах через srcset зазвичай знімають 60–70% ваги.
  • Lazy-loading на першому екрані. Атрибут loading="lazy" на головному зображенні відкладає саме той елемент, який вимірюється. Ставте його лише нижче згину.
  • Блокуючий CSS і шрифти. Кожен зовнішній стиль у <head> затримує перший рендер. Критичний CSS інлайном, решта — асинхронно.
  • Рендер на клієнті. Якщо контент героя малює JavaScript після завантаження бандла, LCP дорівнює часу до гідратації. Серверний рендеринг вирішує це радикально.
  1. 1Виміряйте TTFB окремо. Якщо він понад 800 мс — спершу кеш і хостинг, до картинок навіть не беріться.
  2. 2Стисніть і переведіть у сучасний формат зображення першого екрана, задайте width і height.
  3. 3Додайте <link rel="preload"> для LCP-зображення та основного шрифту — це майже завжди 200–400 мс.
  4. 4Приберіть із критичного шляху все стороннє: чат, піксель, карту. Вантажте їх після взаємодії.

INP: сторінка виглядає готовою, але не реагує

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

  1. 1

    Знайдіть найповільнішу взаємодію

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

  2. 2

    Розбийте довгі задачі

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

  3. 3

    Заберіть анімації, які крутяться постійно

    Нескінченні keyframes, backdrop-filter і великі тіні на мобільних з’їдають кадри саме тоді, коли користувач скролить. Ми свідомо вимкнули їх на мобільній версії власного сайту — INP покращився помітніше, ніж від будь-якої оптимізації бандла.

  4. 4

    Відкладіть сторонні скрипти

    Чат-віджет, який вантажиться одразу, додає 150–400 мс до кожної взаємодії на слабкому телефоні. Вантажте його за таймером бездіяльності або після першого скролу.

LCP лікується грошима і CDN. INP лікується тільки тим, що хтось сідає й переписує обробник події.

CLS: контент стрибає під пальцем

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

Що резервувати завжди

  • Розміри для кожного зображення: атрибути width/height або aspect-ratio у CSS
  • Фіксована висота під банер, слайдер і рекламний блок — до того, як вони завантажилися
  • Місце під кнопку згоди на cookie: не вставляйте її над контентом
  • Однакові метрики для веб-шрифту й запасного — інакше текст «перестрибне» при заміні
  • Скелетон замість порожнечі там, де дані підвантажуються після рендера
  • Вбудовані віджети (відео, карта, відгуки) — у контейнер із заданим співвідношенням сторін
/* Резервуємо місце до завантаження медіа */
.hero-media {
  aspect-ratio: 16 / 9;
  width: 100%;
}

/* Шрифт міняється без стрибка тексту */
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
  size-adjust: 100%;
  ascent-override: 90%;
}

/* Місце під банер існує ще до його появи */
.ad-slot { min-height: 250px; }

Як міряти, щоб не обманювати себе

Головна пастка — плутати лабораторні дані з польовими. Лабораторний прогін показує, як сторінка поводиться в емуляторі на одному запуску. Польові дані показують, що реально відчули ваші користувачі. Ранжування спирається на другі.

  • Search Console, звіт Core Web Vitals — єдине джерело, за яким Google оцінює саме ваш сайт. Групує URL за шаблонами, тому виправлення одного шаблону закриває сотні сторінок.
  • PageSpeed Insights — показує обидва зрізи. Верхній блок з реальними даними важливіший за оцінку внизу; за самим числом 0–100 не женіться.
  • Вкладка Performance у DevTools із троттлінгом 4x CPU — єдиний спосіб побачити довгі задачі, які псують INP.
  • Бібліотека `web-vitals` на власному сайті — надсилає реальні значення в аналітику й дозволяє бачити ефект наступного дня, а не через місяць.
  • Реальний бюджетний телефон — п’ять хвилин на Android за $150 покажуть більше, ніж будь-який звіт. Деталі процесу — у гайді про швидкість завантаження.

І тверда позиція: Core Web Vitals — це сигнал ранжування невеликої ваги. Він майже ніколи не витягне слабкий контент у топ, але системно тягне вниз сайт, у якого решта в порядку. Тому спершу структура й контент за чеклістом SEO, а потім метрики — але не «потім колись».

Часті питання про Core Web Vitals

Наскільки сильно Core Web Vitals впливають на позиції?

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

Чому в PageSpeed 95, а в Search Console червоно?

Тому що це різні типи даних. PageSpeed за замовчуванням показує лабораторний прогін в емуляторі, а Search Console — польові дані реальних відвідувачів за 28 днів, згруповані за 75-м перцентилем. Якщо у вашої аудиторії слабкі телефони й повільний інтернет, лабораторна оцінка буде значно оптимістичнішою за правду.

Скільки часу треба, щоб звіт позеленів після виправлень?

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

Що таке INP і чим він відрізняється від FID?

INP вимірює затримку відповіді сторінки на всі взаємодії користувача за візит і бере найгіршу з них. FID враховував лише першу взаємодію й затримку до початку обробки, тому показував завищено оптимістичну картину. Через це INP значно суворіший і вимагає роботи з логікою JavaScript, а не лише зі скороченням розміру файлів.

Чи можна виправити метрики без переписування сайту?

Зазвичай так. Приблизно 70% випадків закривається без зміни архітектури: стиснення зображень, preload, відкладення сторонніх скриптів, резервування місця під банери й шрифти. Переписування потрібне тоді, коли контент першого екрана малюється на клієнті або сайт стоїть на важкому шаблоні з десятком плагінів.

Коротко

  • Три метрики — три різні відчуття: LCP про появу контенту, INP про реакцію на дію, CLS про стабільність макета.
  • Оцінюється 75-й перцентиль реальних візитів за 28 днів, тому один швидкий тест на своєму ноутбуку нічого не доводить.
  • Порядок виправлення: спершу TTFB і зображення, потім довгі задачі JavaScript, потім резервування місця.
  • INP найчастіше псують сторонні віджети й постійні анімації на мобільних, а не розмір бандла.
  • Метрики підсилюють здоровий сайт і не рятують слабкий — читайте їх разом із мобільною версією і структурою.
Поділитися
  • Core Web Vitals
  • швидкість
  • SEO

Схожі матеріали

Усі статті