Core Web Vitals у 2026: що означають LCP, INP і CLS та як їх покращити

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

Саме тому поняття «швидкий сайт» складніше за одну цифру.

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

У 2026 році основними Core Web Vitals залишаються:

• LCP — Largest Contentful Paint;
• INP — Interaction to Next Paint;
• CLS — Cumulative Layout Shift.

Ці метрики корисні і для технічного SEO, і для розробки, але важливо правильно їх інтерпретувати.

Core Web Vitals — це не оцінка якості всього сайту і не формула продажів. Це три вимірювані сигнали про конкретні аспекти реального користувацького досвіду.

Що таке Core Web Vitals

Core Web Vitals — набір метрик, які Google використовує для оцінки ключових аспектів взаємодії користувача зі сторінкою.

Кожна метрика відповідає за окрему частину досвіду:

• LCP — завантаження;
• INP — швидкість реакції;
• CLS — візуальну стабільність.

Важливо, що Core Web Vitals орієнтовані не лише на лабораторний тест.

Google може використовувати дані реальних користувачів Chrome — так звані field data.

Тому ситуація, коли локальний тест розробника показує чудовий результат, а Search Console повідомляє про проблему, цілком можлива.

Які значення Core Web Vitals вважаються хорошими

Актуальні рекомендовані пороги виглядають так:

Метрика Добре Потрібне покращення Погано LCP до 2,5 с понад 2,5 до 4 с понад 4 с INP до 200 мс понад 200 до 500 мс понад 500 мс CLS до 0,1 понад 0,1 до 0,25 понад 0,25

При цьому Google орієнтується не на найкраще або найгірше одиничне відвідування.

Для оцінки Core Web Vitals використовується 75-й перцентиль: умовно кажучи, не менше 75% відвідувань повинні вкладатися в рекомендований поріг.

Mobile та desktop при цьому варто аналізувати окремо.

LCP: наскільки швидко користувач бачить основний контент

Largest Contentful Paint вимірює час, за який відображається найбільший релевантний елемент у видимій області сторінки.

Це може бути:

• велике зображення;
• hero-банер;
• постер відео;
• великий текстовий блок;
• інший значний елемент першого екрана.

LCP намагається відповісти на практичне питання: коли користувач побачив основний зміст сторінки?

Хорошим орієнтиром вважається LCP до 2,5 секунди.

Що найчастіше погіршує LCP

Занадто велике hero-зображення

Одна з найпоширеніших причин — велика фотографія або банер на першому екрані.

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

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

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

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

Ресурси, що блокують рендеринг

CSS, JavaScript або шрифти можуть затримувати момент, коли браузер здатний намалювати сторінку.

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

Неправильний пріоритет завантаження

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

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

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

Типовий план оптимізації може включати:

• зменшення розміру основного зображення;
• використання відповідного формату;
• правильні responsive images;
• покращення серверної відповіді;
• кешування;
• скорочення render-blocking ресурсів;
• раннє завантаження критичного LCP-ресурсу;
• спрощення першого екрана там, де він перевантажений.

Але оптимізувати потрібно причину, а не саму назву метрики.

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

INP: наскільки швидко сайт реагує на користувача

Interaction to Next Paint оцінює чутливість інтерфейсу до взаємодії.

Вона враховує такі дії, як:

• клік мишею;
• тап на сенсорному екрані;
• взаємодія з клавіатури.

INP показує, скільки часу проходить від дії користувача до моменту, коли браузер може показати наступний візуальний результат.

Хорошим значенням вважається INP до 200 мілісекунд.

У 2024 році INP замінив попередню метрику FID як один із Core Web Vitals.

Чому сайт може мати поганий INP

Важкий JavaScript

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

На потужному ноутбуці така затримка може бути майже непомітною.

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

Складні обробники подій

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

Сторонні скрипти

Чати, аналітика, рекламні системи, A/B-тести та інші сторонні сервіси також використовують ресурси браузера.

Один невеликий сервіс може майже не впливати на сторінку. Десять одночасних інтеграцій — уже інша ситуація.

Надмірний ререндеринг

У складних JavaScript-додатках поганий INP може виникати через зайві оновлення великої кількості компонентів.

Проблема тоді знаходиться не в самому фреймворку, а в конкретній архітектурі та реалізації.

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

Залежно від причини можуть допомогти:

• розбиття великих JavaScript-задач;
• скорочення непотрібного коду;
• оптимізація обробників подій;
• зменшення кількості дорогих DOM-операцій;
• перегляд сторонніх скриптів;
• відкладене завантаження некритичної логіки;
• оптимізація компонентів та ререндерингу;
• тестування на реальних мобільних пристроях.

Особливо важливо не оцінювати інтерактивність тільки за тим, наскільки швидко відкривається сторінка.

Сайт може мати хороший LCP і водночас поганий INP.

CLS: наскільки стабільним залишається макет

Cumulative Layout Shift оцінює несподівані зміщення видимих елементів сторінки.

Класична ситуація: користувач збирається натиснути кнопку, але зверху раптом з’являється банер, контент зміщується — і натискання потрапляє на інший елемент.

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

Для CLS хорошим вважається значення до 0,1.

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

Що найчастіше погіршує CLS

Зображення без зарезервованого місця

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

Реклама та динамічні банери

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

Шрифти

Заміна системного шрифту на вебшрифт після завантаження іноді змінює ширину та висоту тексту.

Результатом можуть бути помітні зміщення.

Контент, який додається над уже видимою областю

Cookie-банери, повідомлення, промо-блоки та інші елементи потрібно реалізовувати так, щоб вони не пересували вже видимий контент без необхідності.

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

Типові рішення:

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

Чому 75-й перцентиль важливіший за один ідеальний тест

Core Web Vitals призначені для оцінки реального досвіду широкої аудиторії.

У різних людей різні:

• пристрої;
• процесори;
• мережі;
• браузерні умови;
• географічне розташування;
• стан кешу.

Тому результат одного тесту на швидкому MacBook через офісний Wi-Fi не описує досвід усіх клієнтів.

Google використовує 75-й перцентиль, щоб оцінювати достатньо велику частину реальних відвідувань.

Якщо 75-й перцентиль LCP становить 2,3 секунди, це означає, що приблизно 75% виміряних відвідувань мали значення 2,3 секунди або краще.

Чому дані Search Console не змінюються одразу після виправлення

Це важливий момент після оптимізації.

Core Web Vitals у Search Console базуються на польових даних реальних користувачів, а не тільки на сьогоднішньому тесті.

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

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

Саме тому під час розробки корисні лабораторні інструменти, а для оцінки реального довгострокового результату — польові дані.

Чому в Search Console сторінки об’єднані в групи

Google Search Console може об’єднувати схожі URL у групи.

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

Це корисно, тому що часто не потрібно виправляти сто сторінок вручну.

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

Тому при роботі з Core Web Vitals важливо шукати не тільки проблемну URL, а й спільну архітектурну причину.

Core Web Vitals і PageSpeed Insights — у чому різниця

PageSpeed Insights — це інструмент.

Core Web Vitals — це метрики.

PageSpeed Insights може показувати як дані реальних користувачів, так і лабораторний аналіз Lighthouse.

Це дві різні частини звіту.

Лабораторний тест зручний для діагностики тут і зараз.

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

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

Core Web Vitals і SEO

Google рекомендує досягати хороших Core Web Vitals і використовує ці показники у своїх системах ранжування.

Але тут важливо не перебільшувати їхню роль.

Хороші LCP, INP і CLS не гарантують перші позиції.

Сторінка повинна насамперед відповідати пошуковому наміру та містити релевантну корисну інформацію.

Тому немає сенсу видаляти важливий контент лише для того, щоб виграти ще декілька технічних балів.

Правильний підхід — поєднувати хороший контент із хорошим користувацьким досвідом.

Core Web Vitals і конверсія

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

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

Але не існує універсальної формули:

«LCP покращився на одну секунду = продажі автоматично виросли на певний відсоток».

Результат залежить від аудиторії, типу сайту, джерела трафіку, продукту, UX та багатьох інших факторів.

Тому після технічної оптимізації потрібно перевіряти і бізнес-метрики: заявки, покупки, проходження форм та інші цільові дії.

Чи можна мати хороші Core Web Vitals на WordPress або конструкторі

Так.

Технологія сама по собі не визначає результат.

WordPress, Webflow, Wix, custom development або інший стек можуть показувати як хороші, так і погані Core Web Vitals залежно від конкретної реалізації.

На результат впливають:

• тема;
• плагіни;
• контент;
• зображення;
• сторонні сервіси;
• анімації;
• хостинг;
• архітектура;
• якість розробки.

Індивідуальна розробка може дати більше контролю над продуктивністю, але поганий custom-код також може створити повільний сайт.

Тому платформу краще оцінювати за реальними метриками та обмеженнями конкретного проєкту.

Як правильно перевіряти Core Web Vitals

Для повноцінної оцінки краще використовувати декілька джерел.

PageSpeed Insights

Допомагає побачити польові дані, якщо вони доступні, та отримати лабораторну діагностику сторінки.

Google Search Console

Корисна для моніторингу груп URL і системних проблем із Core Web Vitals.

Chrome DevTools і Lighthouse

Зручні під час розробки та пошуку конкретної технічної причини.

Реальні пристрої

Не варто недооцінювати просте ручне тестування.

Іноді затримку кнопки або стрибок макета легше відчути на звичайному смартфоні, ніж побачити в таблиці метрик.

У якому порядку виправляти Core Web Vitals

Не обов’язково оптимізувати всі показники одночасно.

Практичний порядок може бути таким:

1. Визначити, яка метрика реально не проходить поріг.
2. Знайти проблемні типи сторінок.
3. Визначити конкретний елемент або сценарій.
4. Знайти системну технічну причину.
5. Внести зміни.
6. Перевірити результат у лабораторних умовах.
7. Переконатися, що нічого не зламалося.
8. Дочекатися оновлення польових даних.

Цей підхід набагато ефективніший, ніж хаотично встановлювати черговий «плагін для швидкості» після кожного червоного попередження.

Коли Core Web Vitals дійсно потребують уваги

Оптимізація має високий пріоритет, якщо:

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

Якщо всі три показники знаходяться в хорошому діапазоні, витрачати великий бюджет лише для покращення LCP з 2,1 до 1,9 секунди може бути менш пріоритетно, ніж виправити слабкий контент або форму заявки.

Підхід TimeKairos

У TimeKairos ми розглядаємо Core Web Vitals як частину технічної якості сайту, а не як три магічні цифри, від яких напряму залежать продажі.

Спочатку потрібно зрозуміти, яка метрика створює проблему та для яких користувачів.

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

І лише потім оптимізувати.

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

Висновок

Core Web Vitals у 2026 році — це LCP, INP і CLS.

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

Хороші орієнтири: LCP до 2,5 секунди, INP до 200 мілісекунд і CLS до 0,1.

Але самі цифри не повинні ставати кінцевою метою.

Core Web Vitals корисні тоді, коли допомагають знайти реальну проблему користувача — а не тоді, коли сайт оптимізують тільки заради зеленого звіту.