Core Web Vitals 2026: чек-лист, який ми проганяємо на кожному проєкті

Core Web Vitals — це три метрики, якими Google вимірює реальний досвід користувача: швидкість завантаження, чутливість до дій і візуальну стабільність сторінки. Ми у Heleum проганяємо цей чек-лист на кожному проєкті ще до того, як братися за тексти й посилання, бо повільний сайт зливає бюджет на трафік, який не конвертується. Нижче — порядок, за яким ми діагностуємо й чинимо ці метрики, з реальними порогами та прикладами з наших магазинів. Без міфів на кшталт «2 секунди або смерть»: пояснюємо, де поріг справді критичний, а де достатньо «прийнятно».

Що таке Core Web Vitals і навіщо вони бізнесу

Core Web Vitals — це підмножина ширшого набору сигналів page experience, які Google відбирає за одним принципом: вони відображають те, що користувач реально відчуває на сторінці. Не абстрактний «бал швидкості», а конкретні моменти болю — довге очікування контенту, затримка після кліку, скачок верстки під пальцем. Для бізнесу це прямо конвертується у відсоток відмов і недоотримані заявки, тому ми ставимося до цих метрик не як до галочки для SEO, а як до частини юзабіліті.

Три метрики простими словами

LCP (Largest Contentful Paint) міряє, за скільки промальовується найбільший видимий елемент — зазвичай головне зображення чи заголовок. INP (Interaction to Next Paint) міряє чутливість: скільки минає від дії користувача до видимої реакції інтерфейсу. CLS (Cumulative Layout Shift) міряє візуальну стабільність — наскільки сильно елементи стрибають, поки сторінка дозавантажується. Разом вони описують три різні відчуття: «як довго я чекав», «чи відгукнулося на мій клік» і «чи не поїхало все під рукою».

Чому Google зробив їх частиною ранжування

Будемо чесні: Core Web Vitals — це не чарівна кнопка для топу. Це сигнал-тайбрейкер. Коли дві сторінки близькі за релевантністю й авторитетом, швидша й стабільніша отримує перевагу. Якщо контент слабкий, ідеальний LCP його не врятує. Тому ми ніколи не продаємо «оптимізацію швидкості» як окреме чудо — вона працює в парі з контентом і структурою в межах SEO-просування, а не замість них.

Орієнтири, на які ми рівняємось

Пороги Google задає не для лабораторного ідеалу, а для 75-го перцентиля реальних візитів за останні 28 днів. Тобто метрика вважається «доброю», лише якщо три чверті ваших користувачів бачать добрий результат — на своїх телефонах і своєму інтернеті, а не на потужному ноутбуці розробника. Ось значення, за якими ми оцінюємо стан сторінки:

Важливий нюанс, який рятує бюджет: ціль — це «добре», а не «нуль». Якщо LCP вашого сайту 2,3 секунди, гнатися за 1,1 секунди коштом тижнів роботи інженерів немає сенсу — виграш у позиціях буде непомітним. А от перетягнути показник із «погано» в «добре» зазвичай дає відчутний ефект і для користувача, і для відмов.

Як ми витягуємо LCP

LCP майже завжди впирається в одне з трьох: повільна відповідь сервера, важке головне зображення або ресурси, що блокують промальовування. Починаємо з часу до першого байта: дешевий хостинг і відсутність кешування дають 600–900 мс ще до того, як браузер щось намалював. Далі беремося за головне зображення — стискаємо, віддаємо в сучасному форматі, задаємо розміри й підвантажуємо його з пріоритетом, а все, що нижче згину, навпаки відкладаємо. Окремо виносимо рендер-блокувальні стилі та шрифти. На одному з наших магазинів така зв’язка — кеш, стиснення картинок і preload банера — зняла LCP з 4,1 до 2,2 секунди без жодного переписування шаблону. Ці роботи ми ведемо в межах оптимізації швидкості.

Як ми тримаємо INP у нормі

У березні 2024 року INP офіційно замінив стару метрику FID — і це не косметика, а серйозніша планка. FID міряв лише затримку першої взаємодії, а INP дивиться на чутливість упродовж усього візиту: кожен клік, тап і ввід. Головний винуватець поганого INP — важкий JavaScript, який надовго блокує основний потік. Ми шукаємо «довгі задачі», розбиваємо їх на менші шматки, прибираємо зайві сторонні скрипти (чати, віджети, аналітику, що тягне сотні кілобайт) і відкладаємо те, без чого перший екран обходиться. Правильно зібраний фронтенд тут вирішує більше за будь-який плагін — тому код ми пишемо з прицілом на це з самого початку, а не латаємо потім, як описано в матеріалі про технічну якість коду.

Звідки береться зсув макета

CLS дратує користувача найсильніше: ви тягнетеся до кнопки, а під пальцем усе стрибає, і ви тиснете не туди. Причини майже завжди однакові — зображення й відео без заданих розмірів, банери та віджети, що вантажаться із затримкою й розсувають контент, веб-шрифти, через які текст перемальовується, і блоки, які JavaScript додає над уже видимим контентом. Лікування технічно нудне, але дієве: задавати ширину й висоту медіа, заздалегідь резервувати місце під рекламу й динамічні вставки, акуратно під’єднувати шрифти. У більшості випадків довести CLS до «добре» — це кілька годин акуратної роботи, а не переробка сайту.

Лабораторні й польові дані — чому вони розходяться

Найчастіше плутанина в тому, що PageSpeed Insights показує два блоки. Згори — польові дані (реальні візити, той самий 75-й перцентиль за 28 днів), за якими Google і судить сторінку. Знизу — лабораторний тест Lighthouse: один синтетичний прогін на емульованому пристрої. Вони майже ніколи не збігаються, і це нормально: лабораторія корисна для діагностики «що саме гальмує», а рішення про стан сторінки ухвалюють польові дані. Динаміку по сайту зручно бачити у звіті Core Web Vitals у Search Console — як його читати разом із аналітикою, ми розбирали в матеріалі про звіти GA4 і Search Console. Якщо нової сторінки ще немає в полі, орієнтуйтеся на лабораторію, але не приймайте її за вирок.

Чим ми міряємо

Для діагностики беремо PageSpeed Insights, який показує польові й лабораторні дані поруч, і панель Performance у Chrome DevTools, щоб бачити, які саме скрипти блокують основний потік. Для динаміки по сайту — звіт Core Web Vitals у Search Console: він групує сторінки за типами й одразу показує, що сповзло в «погано». А для постійного контролю на бойовому трафіку підключаємо збір реальних метрик через бібліотеку web-vitals — так ми ловимо просідання ще до того, як його побачить Google, і не чекаємо, поки воно осяде в полі за 28 днів.

Помилки, які ми бачимо найчастіше

На аудитах одні й ті самі промахи повторюються з проєкту в проєкт. Ось ті, що коштують найдорожче:

1. Оптимізують лабораторний бал замість польового: ганяють Lighthouse до 100, поки реальні користувачі на мобільному бачать «погано».
2. Виправляють головну, а гроші приносять картки товару й категорії — і саме вони лишаються повільними.
3. Вішають на сайт п’ять сторонніх скриптів і дивуються поганому INP, хоча половина з них узагалі не потрібна.
4. Забувають про мобільні: міряють на десктопі з кабельним інтернетом, а Google судить за 4G на середньому телефоні.
5. Ганяються за ідеальними цифрами там, де метрика вже «добра», замість витягти сторінки із зони «погано».
6. Роблять разову оптимізацію перед запуском і більше не моніторять — за півроку нові банери й плагіни тихо все псують.

Як ми вбудовуємо Core Web Vitals у роботу над сайтом

Окрема «оптимізація швидкості» раз на рік працює погано. Ми вбудовуємо Core Web Vitals у процес: на старті — технічний аудит із заміром усіх трьох метрик на ключових типах сторінок, далі — пріоритезація за принципом «спочатку витягуємо те, що в зоні погано і приносить трафік». Якщо проблема в самій основі сайту, чинимо її в межах розробки, а не латаємо плагінами. І головне — лишаємо моніторинг, щоб наступний редизайн чи маркетинговий скрипт не відкотив усе назад непомітно.

Висновок

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

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

Михайло Уманенко

Project Manager · співзасновник heleum.studio

Співзасновник і Project Manager heleum.studio. 8+ років керує SEO- та веб-проєктами: відповідає за стратегію, строки й результат, особисто веде ключових клієнтів.