Core Web Vitals та INP у 2026: що досі важливо

Core Web Vitals пережили чотири роки прогнозів, що Google от-от від них відмовиться. У 2026 вони досі тут, досі вимірюються на реальних користувачах і досі варті уваги. Скажу чітко, що вони змінюють, чого не змінюють і куди варто спрямувати зусилля.

Що таке Core Web Vitals у 2026

Core Web Vitals — це три метрики, якими Google описує досвід завантаження та використання сторінки:

• LCP (Largest Contentful Paint) — час до промальовування основного контенту. "Добре" — менше 2,5 секунди.
• INP (Interaction to Next Paint) — наскільки швидко сторінка реагує на натискання, кліки та клавіші протягом усього візиту. "Добре" — менше 200 мілісекунд.
• CLS (Cumulative Layout Shift) — наскільки макет несподівано стрибає. "Добре" — менше 0,1.

Головна зміна сталася в березні 2024 року, коли INP замінив FID (First Input Delay). FID вимірював лише затримку до обробки першої взаємодії. INP же враховує повну затримку взаємодій протягом сесії й повідомляє про найгірші з них. Це значно складніше підробити і набагато ближче до того, як сторінка відчувається насправді.

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

Чесний вплив на ранжування

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

Що це означає на практиці:

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

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

Як вимірювати правильно

Найпоширеніша помилка, яку я бачу, — оптимізація лабораторних оцінок при ігноруванні польових даних. Google ранжує за польовими даними — реальними користувачами Chrome, агрегованими в Chrome UX Report (CrUX). Лабораторні інструменти відтворюють проблеми, але не визначають ранжування.

Використовуйте такий набір:

1. Search Console → звіт Core Web Vitals. Ваша відправна точка. Він групує реальні URL у "good", "needs improvement" і "poor" за даними CrUX, тож ви бачите проблеми в масштабі.
2. PageSpeed Insights. Показує і польові дані (згори), і лабораторний запуск (знизу) для однієї URL. Завжди читайте спершу польову частину.
3. Chrome DevTools + панель Performance. Для відтворення й діагностики конкретної повільної взаємодії чи зсуву макета.
4. JavaScript-бібліотека web-vitals або моніторинг реальних користувачів (RUM). Найнадійніший підхід у довгій перспективі: збирайте LCP, INP і CLS зі своїх користувачів і сегментуйте за типом сторінки, пристроєм і країною.

Практичне правило: якщо CrUX каже, що шаблон "poor", а лабораторна оцінка зелена, довіряйте CrUX і копайте в сегменти пристроїв та мереж. Реальні користувачі на середніх Android-телефонах кажуть правду.

Типові виправлення, що дають результат

Більшості сайтів не потрібна екзотична інженерія. Потрібен короткий список дисциплінованих виправлень.

Покращення LCP

• Віддавайте LCP-зображення в сучасному форматі (AVIF або WebP), правильного розміру, з fetchpriority="high".
• Приберіть блокуючі рендер CSS і JavaScript із критичного шляху; вбудовуйте лише CSS, потрібний для першого екрана.
• Використовуйте CDN і розумне кешування, щоб сервер відповідав швидко (стежте за TTFB).
• Робіть preload LCP-ресурсу й хостіть критичні шрифти локально з font-display: swap.

Покращення INP

• Розбивайте довгі JavaScript-завдання. Усе, що блокує головний потік довше за 50 мс, шкодить чутливості. Ділíть роботу й повертайте керування браузеру.
• Відкладайте або ліниво завантажуйте сторонні скрипти — теги-менеджери, чат-віджети й аналітика часто винні.
• Виносьте важкі обчислення з головного потоку у web workers, де це доречно.
• Уникайте великих синхронних обробників подій; показуйте візуальний відгук одразу, а дорогу роботу відкладайте.

Покращення CLS

• Задавайте явні width і height (або aspect-ratio) для зображень, відео та вбудовувань.
• Резервуйте місце під рекламу, банери й контент, що додається динамічно.
• Робіть preload шрифтів, щоб уникнути пізніх замін, які переверстують текст.
• Ніколи не вставляйте контент над наявним, якщо цього не ініціював користувач.

Реалістичний план на 30 днів

Ви не виправите Core Web Vitals по всьому сайту за ніч. Пріоритезуйте за трафіком і доходом.

1. Тиждень 1 — Діагностика. Витягніть звіт Search Console. Ранжуйте групи URL, що не проходять, за трафіком. Оберіть два-три шаблони (а не окремі сторінки), відповідальні за більшість поганого досвіду.
2. Тиждень 2 — Виправте головний шаблон. Зазвичай це LCP та INP на грошових сторінках: макетах товарів, категорій чи статей.
3. Тиждень 3 — Виправте другий шаблон і займіться проблемами CLS, які часто є швидкими перемогами.
4. Тиждень 4 — Перевірте за польовими даними. CrUX оновлюється в 28-денному ковзному вікні, тож покращення проявляються за тижні. Переконайтеся, що тренд рухається, і переходьте до наступного шаблону.

Налаштуйте RUM-дашборд, щоб не летіти наосліп між оновленнями CrUX.

Типові помилки, яких варто уникати

За роки аудитів я бачу, як ті самі промахи повторюються знову й знову. Ось на що звернути увагу насамперед:

• Гонитва за оцінкою 100 у Lighthouse. Ідеальний лабораторний бал не гарантує проходження на реальних користувачах. Оптимізуйте польові метрики, а не марнославний показник.
• Оптимізація домашньої сторінки, поки грошові шаблони страждають. Головна часто найшвидша, а от сторінки товарів чи статей приносять трафік і конверсії. Ідіть туди, де біль.
• Ігнорування різниці між пристроями. Сайт може проходити на десктопі й провалюватися на мобільних. Оскільки Google оцінює мобільний досвід, саме він вирішує.
• Разові виправлення без моніторингу. Новий сторонній скрипт, важке зображення чи оновлення CMS легко відкочують ваш прогрес. Без RUM ви дізнаєтеся про це занадто пізно.
• Сприйняття CLS як дрібниці. Несподівані зсуви руйнують довіру й псують конверсію навіть тоді, коли швидкість здається прийнятною.

Дисциплінований, повторюваний процес завжди перемагає героїчний ривок раз на рік.

Головний висновок

У 2026 Core Web Vitals винагороджують те саме, що й завжди: сторінки, які швидко завантажуються, миттєво реагують і не стрибають. Вимірюйте за польовими даними, спершу виправляйте найгірші шаблони й ставтеся до ефекту на ранжування як до бонуса поверх справді кращого досвіду. Саме там живе тривка цінність.