Core Web Vitals — три метрики Google, які вимірюють швидкість завантаження, відгук на дії та візуальну стабільність сторінки. Google використовує їх як сигнал ранжування і показує результат у Search Console та PageSpeed Insights. Розберемо, яку частину метрик вирішує хостинг, а яку — тема і плагіни WordPress.
Три метрики і їхні пороги
LCP (Largest Contentful Paint) вимірює час до відображення найбільшого видимого блоку — зазвичай це головне зображення або заголовок. INP (Interaction to Next Paint) вимірює затримку між дією відвідувача (клік, тап, натискання клавіші) і оновленням екрана у відповідь; ця метрика замінила FID у березні 2024 року. CLS (Cumulative Layout Shift) рахує, наскільки сильно елементи сторінки зсуваються після першого відображення.
| Метрика | Добре | Потрібно покращити | Погано |
|---|---|---|---|
| LCP | до 2.5 c | від 2.5 до 4.0 c | більше 4.0 c |
| INP | до 200 мс | від 200 до 500 мс | більше 500 мс |
| CLS | до 0.1 | від 0.1 до 0.25 | більше 0.25 |
Google вважає сторінку такою, що пройшла Core Web Vitals, якщо щонайменше 75% візитів укладаються у порог «добре» — дані з мобільних і настільних пристроїв оцінюються окремо, і сайт може проходити на десктопі і не проходити на мобільному.
Де дивитися реальні значення
PageSpeed Insights показує два набори цифр: Lab Data — один замір у контрольованих умовах, і Field Data — агреговані дані реальних відвідувачів за 28 днів (Chrome User Experience Report). Для оцінки проходження порогу важливий саме Field Data; Lab Data потрібен для діагностики причини.
У Search Console розділ «Основні інтернет-показники» групує сторінки за реальними даними відвідувачів і показує, яка метрика провалює групу URL — це швидше, ніж перевіряти сторінки по одній.
Що виправляє хостинг: TTFB і стиснення
LCP прямо залежить від того, як швидко сервер віддає перший байт HTML (TTFB) — чим пізніше браузер отримає документ, тим пізніше почнеться завантаження головного зображення. Включене стиснення відповідей зменшує обсяг HTML, CSS і JS, які потрібно скачати до початку відображення; детальне налаштування розібране у статті про Gzip і Brotli в Nginx.
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.com/Якщо TTFB вищий за кілька сотень мілісекунд вже на порожній сторінці без плагінів, проблема не в метриках, а у перевантаженому тарифі або повільному диску — жоден плагін кешування цю частину LCP не виправить.
Кешування і CDN: коли допомагають LCP, а коли ні
Кеш сторінки і CDN прискорюють саме повторні візити та статичні файли — картинки, шрифти, CSS. Добірка прийомів з практики прискорення WordPress:
- Увімкнути кеш сторінок і переконатися, що HTML-сторінка віддається з кешу, а не генерується PHP при кожному візиті.
- Віддавати зображення у сучасних форматах і правильного розміру — велике зображення, зменшене лише CSS, все одно завантажується повною вагою і гальмує LCP.
- Додати preconnect до домену CDN і шрифтів, щоб браузер відкрив з'єднання заздалегідь, а не в момент, коли до нього дійде черга.
- Відкласти завантаження некритичного CSS і JS, які не потрібні для відображення першого екрана, але не чіпати скрипти, які формують верхній блок сторінки.
- Не кешувати сторінки з персональним змістом (кошик, особистий кабінет) цілком — це не прискорить LCP для них, а створить показ чужих даних іншому відвідувачу.
Ці прийоми розібрані детальніше у статті про прискорення WordPress; починати варто з них, а не з правки конкретної метрики вручну.
Що хостинг не може виправити
INP майже завжди залежить від кількості і ваги JavaScript, який виконується у браузері відвідувача — важкі конструктори сторінок, зайві віджети і скрипти аналітики блокують основний потік на час обробки кліку. Хостинг не виконує JS за відвідувача і не може прискорити код теми або плагіна.
CLS найчастіше псують зображення без заданих атрибутів width і height, веб-шрифти, які підмінюють текст після завантаження, і блоки реклами, які з'являються із затримкою і зсувають контент. Частину цього вирішує кеш статичних ресурсів і правильне налаштування кешуючого плагіна — наприклад, як це зроблено у статті про LiteSpeed Cache для WordPress, — але вихідну розмітку теми все одно потрібно виправляти на рівні коду.
Часті питання
Чи може хостинг гарантувати проходження Core Web Vitals?
Ні, хостинг відповідає за TTFB, стиснення відповідей і доступність кешу, але підсумкові метрики складаються з коду теми, кількості плагінів та їхнього JavaScript — на одному й тому самому сервері один сайт проходить порог, а інший з важкою темою ні.
Чому PageSpeed Insights показує хороший LCP, а Search Console — поганий?
PageSpeed Insights у режимі Lab Data робить один замір у контрольованих умовах і часто на швидкому з'єднанні, а Search Console показує Field Data за 28 днів з реальних пристроїв і мереж відвідувачів, включно з повільним мобільним інтернетом — розбіжність нормальна і означає, що потрібно дивитися саме на Field Data.
Що робити, якщо CLS хороший у Lab Data, але поганий у реальних відвідувачів?
Перевірити блоки, які підвантажуються із затримкою лише у частини відвідувачів — банери зі згодою на cookie, віджети чату, відкладена реклама — у контрольованому замірі PageSpeed Insights вони часто не встигають з'явитися і не псують показник, а у реальних відвідувачів встигають.