Core Web Vitals: як швидкість сайту впливає на позиції і що оптимізувати першим

20 Жовтня, 2026

«Прискорити сайт» — одна з найчастіших задач, яку ставлять SEO-спеціалісту, і одна з найбільш неправильно зрозумілих. Власники бізнесу дивляться на оцінку PageSpeed Insights і хочуть 100 балів; Google дивиться на три метрики Core Web Vitals за даними реальних користувачів — і це зовсім різні речі. У цій статті: що саме вимірює Google, наскільки це впливає на позиції, і які правки дають найбільший результат за найменші гроші.

Три метрики, які має Google

Метрика	Що вимірює	Добре	Погано
LCP (Largest Contentful Paint)	Час до відображення найбільшого елемента на екрані — зазвичай головного зображення або заголовка	≤ 2,5 с	> 4,0 с
INP (Interaction to Next Paint)	Затримка між дією користувача (клік, тап) і оновленням екрана; замінила FID у 2024 році	≤ 200 мс	> 500 мс
CLS (Cumulative Layout Shift)	Наскільки «стрибає» верстка під час завантаження	≤ 0,1	> 0,25

Ключове: Google оцінює не лабораторний тест, а польові дані — CrUX (Chrome User Experience Report), зібрані з реальних користувачів Chrome за 28 днів. Сайт має пройти всі три пороги на рівні 75-го перцентиля відвідувачів. Ці дані видно у Search Console у звіті «Основні показники веб-сторінок» і в PageSpeed Insights у верхньому блоці «Дані реальних користувачів».

Наскільки це впливає на позиції

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

Конверсія. Кожні +1 с до LCP на мобільному — мінус 5–10% конверсії за даними Google і Deloitte. Це вплив на дохід, незалежно від позицій.
Краулінговий бюджет. Повільний сервер означає, що Googlebot сканує менше сторінок за сесію. Для магазинів із десятками тисяч URL це критично.
AI-агенти. Краулери ChatGPT, Perplexity, Claude мають жорсткі таймаути. Сайт, який віддає HTML за 3–5 секунд, для них частково не існує. Ми писали про це в матеріалі AI-агенти як новий тип відвідувача сайту.

Що оптимізувати першим: пріоритети за ефектом

1. LCP — найчастіша проблема, найбільший ефект

TTFB сервера. Якщо перший байт приходить за 800 мс+, ніякі фронтенд-правки не врятують. Рішення: кешування сторінок (для WordPress — WP Rocket, LiteSpeed Cache; для OpenCart — вбудований кеш + Redis), нормальний хостинг, PHP 8.3+, OPcache.
Головне зображення: формат WebP/AVIF, коректний розмір під екран, fetchpriority="high", без lazy loading для першого екрана. Це одна правка, яка часто дає мінус 1–1,5 с.
Render-blocking CSS/JS. Критичний CSS інлайном, решта — відкладено. Шрифти — font-display: swap і preload для основного.
CDN (Cloudflare, BunnyCDN) — для аудиторії з різних регіонів і захисту від пікових навантажень.

2. INP — проблема JavaScript

Найчастіші винуватці: важкі теми з десятками скриптів, чат-віджети, пікселі реклами, слайдери, калькулятори. Рішення: відкласти завантаження не критичних скриптів до першої взаємодії, прибрати невикористовувані плагіни, винести аналітику через Google Tag Manager із затримкою. На Shopify — обмежити кількість застосунків, кожен додає свій JS.

3. CLS — найпростіше виправити

Зазначити width і height у всіх зображень та iframe, зарезервувати місце під рекламні блоки й банери, не вставляти контент над уже відображеним (наприклад, куки-бар зверху сторінки), завантажувати шрифти так, щоб текст не «перестрибував».

Особливості за CMS

CMS	Типова проблема	Що робимо
WordPress / WooCommerce	Тема-конструктор (Elementor, Divi) + 30 плагінів	Кеш, оптимізація зображень, відкладений JS, аудит плагінів; іноді — зміна теми
OpenCart	Повільні SQL-запити на категоріях із фільтрами, старий PHP	Індекси БД, кеш модулів, оновлення PHP, оптимізація фільтрів
Shopify	Застосунки, що інжектять скрипти; обмежений доступ до сервера	Видалення зайвих apps, оптимізація теми, lazy loading нижче першого екрана
Horoshop	Мало контролю над кодом	Оптимізація зображень і контенту, мінімум кастомних скриптів

Чому не потрібно гнатися за 100 балами

Оцінка PageSpeed — лабораторний тест на емульованому повільному телефоні з throttling-ом мережі. Вона корисна для діагностики, але Google її не використовує. Сайт із 65 балами і «зеленими» польовими CWV ранжується краще за сайт зі 95 балами і «жовтим» INP у CrUX. Мета — пройти три пороги на реальних користувачах, а не намалювати сотку у скриншоті. Різниця в бюджеті між «зелені CWV» і «100 балів» — часто десятки годин розробки без жодного ефекту для бізнесу.

Перевірка CWV, TTFB і краулінгового навантаження — стандартна частина нашого технічного SEO-аудиту. Впровадження правок — у внутрішній оптимізації; для магазинів дивіться SEO для OpenCart та SEO для WordPress.

FAQ

Чи впливають Core Web Vitals на позиції в Google?

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

Що важливіше — оцінка PageSpeed чи Core Web Vitals?

Core Web Vitals за польовими даними (CrUX). Оцінка PageSpeed — лабораторний інструмент діагностики, який Google не використовує для ранжування.

Скільки часу потрібно, щоб Google побачив покращення?

CrUX збирає дані за 28 днів, тому статус у Search Console оновиться через 4–6 тижнів після правок.

Чому в Search Console «погано», а PageSpeed показує зелений?

PageSpeed тестує одну сторінку в лабораторних умовах, Search Console агрегує дані реальних користувачів по групах сторінок. Дивіться на польові дані і перевіряйте типові сторінки: категорії, картки товару, статті.

Чи достатньо встановити плагін кешування?

Для LCP на простих WordPress-сайтах — часто так. Для INP і CLS плагін не допоможе: потрібна робота з JS і версткою.