Core Web Vitals у 2026 році: актуальні метрики
Актуальні Core Web Vitals це LCP, INP і CLS. LCP вимірює швидкість завантаження, INP реакцію на взаємодії, CLS візуальну стабільність. Google описує їх як ключові користувацькі аспекти реального досвіду. [1][3]
FID більше не входить до актуального набору. INP замінив FID у березні 2024 року, а FID пізніше було видалено з CrUX. [7][14]
Порогові значення і 75-й процентиль
| Метрика | Добре | Потребує покращення | Погано | Що вимірює |
|---|---|---|---|---|
| LCP | ≤ 2.5 s | 2.5 s - 4.0 s | > 4.0 s | Завантаження головного контенту |
| INP | ≤ 200 ms | 200 ms - 500 ms | > 500 ms | Реакцію на взаємодію |
| CLS | ≤ 0.1 | 0.1 - 0.25 | > 0.25 | Візуальну стабільність |
Хороші значення: LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1. Потребують покращення 2,5-4,0 с, 200-500 мс і 0,1-0,25. Вищі значення є поганими. [3][4]
Google використовує 75-й процентиль, а не середнє. Щонайменше 75% досвідів мають досягати порогу або бути кращими. Mobile і desktop оцінюються окремо. [3][4]
Загальна оцінка проходить лише тоді, коли всі три метрики хороші. [3]
Core Web Vitals і SEO
Google підтверджує використання Core Web Vitals у системах ранжування як частини оцінювання досвіду сторінки. Хороші значення не гарантують високої позиції, бо важливими залишаються релевантність і якість контенту. [1][2]
Оптимізація покращує реальний UX і прибирає технічну слабкість, але не замінює якісний контент.
LCP: що саме вимірюється
Largest Contentful Paint вимірює час від початку навігації до рендерингу найбільшого відповідного контентного елемента у viewport. Польовий LCP може включати redirects, встановлення з'єднання і TTFB. [5]
LCP тому не є просто часом завантаження найбільшого зображення. Затримка може виникнути значно раніше. [5][6]
LCP на практиці: чотири частини
web.dev ділить LCP на TTFB, затримку початку завантаження ресурсу, тривалість завантаження і затримку рендерингу елемента. [6]
Якщо LCP-ресурс виявляється пізно, сама компресія може не допомогти. Ресурс бажано зробити доступним у початковому HTML, а LCP-зображення не слід lazy load. Допомогти можуть пріоритет або preload. [6]
Діагностуйте по черзі: TTFB, виявлення ресурсу, transfer і render delay. [6]
- Зменшуйте TTFB за допомогою cache, CDN, меншої кількості redirect і швидшого backend.
- Розміщуйте LCP-ресурс у початковому HTML, якщо можливо.
- Не використовуйте `loading="lazy"` для LCP-зображення.
- При пізньому виявленні використовуйте відповідний пріоритет або preload.
- Оптимізуйте розмір і формат лише коли transfer справді є вузьким місцем.
- Зменшуйте JavaScript або CSS, що блокує фінальний rendering.
INP: реакція протягом усієї сесії
Interaction to Next Paint спостерігає clicks, taps і клавіатуру протягом усієї сесії. Для більшості сторінок повідомляється найповільніша взаємодія. На сторінках із великою кількістю взаємодій одна найгірша взаємодія на кожні 50 ігнорується для зменшення впливу випадкових викидів. [7]
INP відрізняється від FID, бо включає input delay, processing і час до наступного paint. [7][8]
Без click, tap або клавіатури сесія може не мати INP. Scroll і hover не враховуються. [7]
INP на практиці: три джерела затримки
Повна затримка складається з input delay, processing duration і presentation delay. Поганий INP може виникати через зайнятий main thread, повільні handlers або дорогий layout і rendering. [8]
Допомагають коротші tasks, поділ роботи, менше важкого JavaScript, простіший layout, Web Workers у відповідних місцях і швидкий візуальний зворотний зв'язок. [8]
Починайте з RUM-даних, які показують повільну взаємодію, а потім відтворюйте її в DevTools. Lighthouse сам по собі не показує повний реальний INP. [8][11][12]
CLS: стабільність протягом усього життя сторінки
Cumulative Layout Shift вимірює неочікуваний рух видимих елементів. Використовується найбільше вікно сесії, де послідовні зміщення відбуваються з інтервалом менше однієї секунди, а все вікно триває не більше п'яти секунд. [9]
CLS безрозмірний і поєднує вплив та відстань зміщення. Деякі зміни, прямо пов'язані з дією користувача, можуть бути виключені. [9]
Проблеми часто з'являються вже після load через рекламу, банери, widgets або fonts. Один лабораторний load може їх не показати. [10][11]
CLS на практиці: типові причини
web.dev називає зображення без розмірів, рекламу, embeds та iframes без зарезервованого місця, динамічний контент і web fonts. [10]
Резервуйте місце до появи контенту. Використовуйте `width` і `height` або стабільний `aspect-ratio`, задавайте передбачувані розміри рекламним слотам і не вставляйте контент над текстом, який користувач уже читає. [10]
Для fonts зменшуйте відмінності метрик між fallback і фінальним font та вимірюйте реальний ефект. `font-display` сам не вирішує всі проблеми. [10]
Польові дані проти лабораторних
Core Web Vitals це насамперед польові метрики. CrUX і власний RUM показують реальних користувачів, Lighthouse допомагає контрольовано відтворювати та діагностувати проблеми. [11][12]
Lighthouse не вимірює повний природний INP і використовує, зокрема, TBT як лабораторний proxy. Лабораторний CLS також може бути нижчим, якщо зміщення виникають після взаємодій. [11][12]
Польові дані показують, чи є реальна проблема, лабораторія допомагає знайти її причину.
Який інструмент використовувати
| Інструмент | Тип даних | Найкраще використання |
|---|---|---|
| PageSpeed Insights | CrUX + Lighthouse | Швидка перевірка URL та origin |
| Search Console | CrUX, групи URL | Пошук груп сторінок із SEO-проблемами |
| Chrome DevTools | Лабораторія + контекст CrUX | Детальна діагностика LCP, INP і CLS |
| Lighthouse | Лабораторія | Автоматичні аудити та регресії CI |
| RUM / web-vitals | Власні дані користувачів | Найточніший моніторингу після випуску |
PageSpeed Insights поєднує CrUX і Lighthouse. Search Console групує схожі URL. DevTools дає live metrics і детальні traces. [12][13]
CrUX API і PageSpeed Insights використовують приблизно 28-денне ковзне вікно. Нове виправлення тому не змінює публічний p75 одразу. Власний RUM реагує швидше. [12][13]
Хороший процес використовує RUM для моніторингу, Search Console для SEO-груп, PSI для швидких перевірок і DevTools для діагностики.
CrUX у 2026 році: актуальний стан Web
| Метрика | Origins з хорошим результатом, липень 2026 |
|---|---|
| LCP | 68,3% |
| INP | 85,7% |
| CLS | 81,6% |
| Усі Core Web Vitals | 55,7% |
Останній місячний набір даних, опублікований до 4 вересня 2026 року, охоплює липень 2026 і був випущений 11 серпня. Він містить 18 059 068 origins. 68,3% мали хороший LCP, 81,6% хороший CLS, 85,7% хороший INP, а 55,7% пройшли всі Core Web Vitals. [14]
Це агреговані дані Web у CrUX, а не цілі для одного сайту. CrUX охоплює лише придатні, публічно доступні та достатньо популярні сторінки й origins. [13][14]
Відсутність даних CrUX не означає, що сторінка швидка або повільна, лише що даних недостатньо.
SPA і soft navigations: важлива зміна у 2026 році
Історично Core Web Vitals були орієнтовані на повні навігації документа. Chrome 151 у 2026 році додав нові API для вимірювання soft navigations, а документацію оновлено 2 вересня 2026 року. [15]
Chrome DevTools 152 від 25 серпня 2026 року показує Core Web Vitals для soft navigations у Live Metrics за замовчуванням за допомогою `web-vitals` 6.0.0. [16]
Це важливо для React, Angular, Vue та інших SPA. Не слід автоматично вважати, що всі публічні CrUX звіти уже однаково оцінюють soft navigations.
Production моніторингу із контекстом
Публічний p75 часто показує проблему без точної причини. Власний RUM може передавати LCP-елемент і підчастини, INP-взаємодію, route, пристрій і версію застосунку. web.dev рекомендує RUM як доповнення до CrUX. [3][8][12]
Позначайте розгортання версією та порівнюйте розподіли до і після. Середнє може приховувати регресії на повільніших пристроях.
CI захищає від очевидних лабораторних регресій, але не замінює моніторингу у production. [11][12]
Практичний план покращення
Спочатку визначте, яка метрика не проходить p75 і на яких типах сторінок. Звузьте проблему через RUM або CrUX, відтворіть у DevTools, виправте конкретну причину і спостерігайте після розгортання. [12]
Для LCP знайдіть домінуючу частину, для INP реальну повільну взаємодію, для CLS конкретні зміщення.
Потім перевірте лабораторні й польові дані. Публічний CrUX реагує із затримкою, тому RUM важливий для швидкої перевірки.
- Спочатку знайдіть проблему у польових даних.
- Розділяйте mobile і desktop.
- Для LCP аналізуйте TTFB, discovery, transfer і render delay.
- Для INP аналізуйте взаємодію та її три частини.
- Для CLS записуйте зміщення протягом усієї сесії.
- Випустіть одне вимірюване виправлення і порівняйте до та після.
- Підтримуйте RUM і сповіщення регресій.
