Core Web Vitals у 2026 — метрики, що досі окуповуються

Три роки, три ребаланси метрик

У 2022 розмова була про FID. У 2024 — про INP. До 2026 кожна команда мала переучувати, що таке «швидко», щонайменше двічі. Добра новина: фундаментальна робота майже не змінилась. Команди, які зосередились на основах — вага зображень, дисципліна JavaScript, передбачуваний рендеринг — лишались у зеленій зоні крізь усі ребаланси. Команди, які гнались за метрикою місяця, досі за нею женуться.

Ця стаття — те, що ми реально робимо в кожному проєкті, незалежно від того, яку літеру Google рекламуватиме наступною.

INP змінив розмову

Заміна First Input Delay на Interaction to Next Paint перевела фокус з однієї першої взаємодії на кожну взаємодію на сторінці. Сайти, що отримували хороший бал випадково, тепер мають отримувати його навмисно. Це здоровий зсув — він винагороджує інтерфейси, які насправді відчуваються відгукливими, а не просто швидко завантажуються.

Три звички, що тут дають реальну різницю:

• Тримайте головний потік коротким. Long tasks — єдина найбільша причина поганого INP. Розбивайте роботу на менші шматки. Плануйте несрочні апдейти через requestIdleCallback або scheduler.postTask.
• Відкладайте гідратацію, де можете. Найдешевша перемога в INP — не гідратувати компонент, з яким користувач не взаємодіяв. RSC і часткова гідратація допомагають; перегідровані SPA шкодять.
• Слідкуйте за third-party. Аналітика, чат-віджети і рекламні скрипти домінують в INP більшості сайтів. Аудитуйте їх щоквартально.

Збої INP майже завжди видимі в Performance-трасі. Якщо ваша команда останній квартал не відкривала панель Performance у DevTools — це перший проєкт, а не останній.

LCP досі ваша геройська метрика

Largest Contentful Paint корелює з конверсією краще, ніж будь-який інший сигнал, який ми трекаємо. Якщо ваш hero-image на мобільному більше 200 KB, ви платите за нього виручкою, а не балами Lighthouse.

Надійні перемоги в порядку віддачі:

1. Правильний розмір hero-зображення. Стиснути, потім конвертувати в AVIF або WebP, потім подавати адаптивні варіанти. Найбільший виграш майже завжди тут.
2. Preload для LCP-ресурсу. <link rel="preload"> для реального активу, яким браузер фарбуватиме LCP. Зупиніть гру в discovery.
3. Скоротіть critical CSS. Інлайнте лише те, що потрібно LCP-елементу. Решту відкладайте.
4. Перемістіть LCP-елемент раніше. Іноді найшвидший фікс — зробити сторінку структурно простішою, щоб браузер швидше побачив LCP-таргет.
5. Кешуйте, потім кешуйте ще. CDN із розумною edge-логікою перемагає більшість серверних оптимізацій, удвічі.

Кожна з цих — мала. Разом вони — різниця між LCP 3.5 с і 1.5 с. На сторінці з великим трафіком цей розрив — мільйони доларів на рік.

CLS — невибачливий

Cumulative Layout Shift здається легким, поки ви не виведете в прод. Тоді sticky-банер cookies, динамічний рекламний слот або пізно завантажений шрифт за ніч викидають вас із зеленої зони. Три правила, що тримаються:

• Кожне зображення має явні width і height. Без винятків.
• Кожен шрифт завантажується з font-display: optional або swap, а fallback відрегульований за розміром. Використовуйте дескриптори size-adjust у сучасних браузерах.
• Кожен динамічний блок (реклама, банери, рекомендації) має зарезервований слот. Слот може бути порожнім; його не може не існувати.

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

Що ми міряємо в день запуску

Лабораторні числа брешуть. Польові — кажуть правду. У день запуску ми хочемо бачити:

• Польовий LCP та INP з реального девайсу, не лабораторне середнє.
• 75-у перцентиль, не медіану — там клієнти йдуть.
• Long tasks під час вікна першої взаємодії.
• Total Blocking Time під час скролу, не лише при завантаженні.
• Тренд за тиждень, а не одне число.

Якщо у вас немає RUM — встановіть його до наступного деплою. Без нього ви тюните наосліп. Web-Vitals.js, базовий аналітичний ендпоінт і дашборд — це день налаштування. Це найвища важільна година, яку ваша інженерна команда витратить у цьому кварталі.

Нудні перемоги досі перемагають

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

Стисніть зображення. Відкладіть скрипт. Засабсетніть шрифт. Майже кожна розмова «сайт повільний» закінчується цим чек-листом. Зробіть його дефолтом у білді, а не штукою, яку команда має пам'ятати.

Глибша версія чек-листа:

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

Що ми не оптимізуємо

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

• Балами Lighthouse. 100 у лабі та 60 у полі — це особливість роботи Lighthouse, а не реальний клієнтський досвід. Оптимізуйте під поле.
• Одиничні покращення метрик, що шкодять іншим. Зменшення LCP лінивим завантаженням hero-зображення — не перемога. Клієнт бачить повільніший фарб і дерганий load.
• Мікро-оптимізації останньої милі в перший день. Економія 5 мс на функції, яка запускається раз, — не туди пішов бюджет. Завжди спочатку профайліть.

Каденс підтримки, який тримається

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

• Щодня: RUM-дашборди видимі в чаті команди, регресії тригерять алерт.
• Щотижня: 30-хвилинний огляд топ-регресій, прив'язаних до недавніх деплоїв.
• Щомісяця: повний аудит однієї сторінки — найповільнішої або найцінішої.
• Щокварталу: перегляд бюджету. Нові метрики, нові обмеження, нові third parties.

Команди, що тримають цей каденс, лишаються в зеленій зоні майже незалежно від складності продукту. Ті, що ставляться до продуктивності як до події запуску, тихо просочуються назад.

Метрика, яка важлива

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