Core Web Vitals для власника магазину: що це і як перевірити самому.

Core Web Vitals — це три метрики Google, які показують, наскільки швидко інтернет-магазин завантажується, відгукується на дії та чи не «стрибає» під час читання: LCP, INP і CLS. Власнику магазину не потрібно вміти їх рахувати. Достатньо знати хороші значення, вміти за 15 хвилин перевірити сайт безкоштовними інструментами і розуміти, про що просити розробника.

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

Що таке Core Web Vitals і чому це важливо для магазину

Google вимірює «досвід сторінки» трьома показниками. Це не абстрактні оцінки, а відображення реальних відчуттів покупця: «довго нічого не з'являється», «кнопка не реагує», «я хотів натиснути одне, а натиснув інше».

Це порогові значення, які публікує Google (перевірено в жовтні 2026). Оцінка вважається за 75-м перцентилем: тобто три чверті відвідувачів мають отримувати «добрий» результат.

Навіщо це вам як власнику:

• Гроші. Повільна сторінка каталогу або картки товару втрачає покупців до того, як вони побачили асортимент. Точні цифри залежать від ніші, тому ми не обіцяємо «+20% конверсії», але напрямок очевидний.
• SEO. Core Web Vitals входять до сигналів «досвіду сторінки». Вони не замінюють корисний контент, але за рівної якості швидший сайт має перевагу.
• Реклама. Якщо трафік платний, повільна посадкова сторінка робить кожен клік дорожчим.
• Мобільні користувачі. Більша частина покупців відкриває магазин з телефона, часто через нестабільний мобільний інтернет.

Як перевірити Core Web Vitals самому за 15 хвилин

Вам знадобиться браузер і безкоштовні інструменти Google. Єдине правило: перевіряйте не лише головну, а й типові шаблони — каталог, картку товару, кошик.

Крок 1. PageSpeed Insights

Відкрийте сервіс PageSpeed Insights, вставте адресу сторінки й оберіть вкладку «Мобільні». Ви побачите два блоки.

1. Дані з реальних користувачів (field data) — вгорі. Це показники відвідувачів за останні 28 днів зі звіту CrUX. Саме вони важливі для Google. Якщо трафіку мало, цього блоку може не бути.
2. Діагностика (lab data) — внизу. Це симуляція завантаження на слабкому пристрої. Вона показує причини проблем, але не є «офіційною» оцінкою.

Не гоніться лише за загальним балом Lighthouse. Дивіться на LCP, INP (у lab-режимі замість нього показується TBT) і CLS окремо, а також на список порад «Можливості» й «Діагностика».

Крок 2. Звіт у Google Search Console

Якщо сайт підключений до Search Console, відкрийте розділ «Основні веб-показники». Там сторінки згруповані за статусом: хороші, потребують покращення, погані. Групуються вони за типовими шаблонами, тож видно, що «усі картки товарів повільні», а не лише одна сторінка.

Крок 3. Перевірка на реальному телефоні

Відкрийте магазин зі свого смартфона через мобільну мережу, не через домашній Wi-Fi. Дайте собі п'ять запитань:

• Через скільки секунд я бачу головне фото товару?
• Чи не зсувається сторінка, коли підвантажуються банери та рекомендації?
• Чи реагує кнопка «Купити» одразу, чи є затримка?
• Чи відкривається фільтр у каталозі без «зависання»?
• Чи не перекриває контент cookie-банер або чат?

Цей простий тест знаходить половину проблем без жодного інструмента.

Крок 4. Chrome DevTools (для просунутих)

У Chrome натисніть F12, відкрийте вкладку Performance або Lighthouse і запустіть аудит у режимі мобільного пристрою із сповільненням мережі. На вкладці Performance видно, які скрипти блокують основний потік. Якщо ви не розробник, можна просто зробити знімок і передати його підряднику як аргумент у розмові.

LCP: чому головний елемент з'являється повільно

У магазинах LCP — це майже завжди велика фотографія: банер на головній, фото товару на картці або перше зображення в каталозі. Причини повільності типові.

Важкі зображення

Фото на 2–3 МБ у форматі JPEG на мобільному завантажуються секундами. Що зробити:

• віддавати сучасні формати (WebP, AVIF);
• генерувати кілька розмірів і підставляти відповідний екрану через srcset;
• стискати без помітної втрати якості;
• задавати width і height, щоб браузер зарезервував місце.

Зображення, яке «лінується» не тоді, коли треба

Атрибут loading="lazy" корисний для картинок нижче першого екрана. Але якщо його поставити на головне фото, браузер відкладе його завантаження. Для LCP-елемента потрібно навпаки:

<img src="/img/hero.avif" width="1200" height="600"
     fetchpriority="high" alt="Нова колекція">

Повільна відповідь сервера

Якщо сервер генерує сторінку по 1,5 секунди, жодні оптимізації картинок цього не виправлять. Для Laravel-магазинів причина часто в N+1 запитах до бази й відсутності кешу: про це ми писали в статті про технічний аудит коду. Якщо сторінки можна віддавати зі статичного кешу чи prerender, виграш буває найбільшим.

Блокуючі шрифти, стилі та скрипти

Шрифти з зовнішнього CDN, багато CSS-файлів і скриптів у <head> затримують перший показ. Рішення: розмістити шрифти на власному домені, підключати лише потрібні накреслення й мови, відкладати непотрібні скрипти.

INP: чому магазин «тупить» після кліку

INP — найновіша метрика, яка замінила FID. Вона вимірює затримку між дією користувача і оновленням екрана протягом усього візиту, а не лише першого кліку.

Що її погіршує:

• Надлишок JavaScript. Бібліотеки для слайдерів, віджети, чати, пікселі, A/B-тести: кожен додає навантаження на основний потік.
• Сторонні скрипти аналітики та реклами. Тег-менеджер із десятком тегів може сповільнити сторінку більше, ніж увесь код магазину.
• Важкі обробники подій. Наприклад, фільтр, який на кожен клік перерисовує весь список із тисяч елементів.
• Гідратація великих сторінок у SPA-фреймворках, коли сторінка виглядає готовою, але ще не реагує.

Практичні кроки:

1. Складіть список усіх сторонніх скриптів і для кожного запитайте: «Хто цим користується і яке рішення на основі цього приймає?» Те, чим ніхто не користується, видаліть.
2. Завантажуйте аналітику та маркетингові пікселі після згоди користувача й з відкладенням. Це ще й вимога конфіденційності.
3. Розбивайте довгі завдання: прокрутка, фільтри та кошик мають відповідати першими.
4. Для великих каталогів використовуйте пагінацію або віртуалізацію списків.

CLS: чому контент «стрибає»

Зміщення макета дратує і шкодить конверсії: людина збирається натиснути «Додати в кошик», а блок рекомендацій з'являється й зсуває кнопку.

Типові винуватці:

• Зображення без розмірів. Браузер не знає висоти й підганяє її після завантаження.
• Банери, cookie-панелі та промо-смуги, які з'являються зверху й виштовхують контент.
• Шрифти, що підміняються після завантаження і змінюють розміри тексту.
• Динамічні блоки: відгуки, «разом з цим купують», віджети доставки без зарезервованого місця.
• Вбудовування (iframe) без розмірів: відео, карти, віджети оплати.

Найпростіше правило: для будь-якого елемента, що завантажується пізніше, зарезервуйте місце заздалегідь. Це робиться задаванням розмірів чи aspect-ratio:

.product-card__image { aspect-ratio: 4 / 5; width: 100%; height: auto; }
.promo-bar { min-height: 40px; }

Для cookie-банера краще робити фіксовану панель знизу, яка не штовхає контент.

Що виправляти першим: порядок дій

Не варто одразу переписувати сайт. Дійте за принципом «найбільший ефект — найменша робота».

1. Зображення. Формати, розміри, srcset, правильне lazy-завантаження. Часто це дає найбільший приріст LCP.
2. Сторонні скрипти. Аудит і видалення зайвого, відкладене завантаження решти.
3. Резервування місця під банери, зображення та віджети. Зазвичай виправляє CLS за кілька годин.
4. Шрифти. Самостійний хостинг, мінімум накреслень, коректне font-display.
5. Кешування й швидкість сервера. Кеш сторінок, оптимізація запитів до бази, CDN.
6. Архітектура. Якщо базові речі виправлені, а показники слабкі, час дивитися на платформу: кількість JavaScript, спосіб рендерингу.

Після кожної зміни перевіряйте результат у PageSpeed Insights. Field-дані оновлюються з затримкою до 28 днів, тому не панікуйте, якщо Search Console не показує покращення наступного ж дня: орієнтуйтеся на lab-вимірювання, а реальний ефект побачите пізніше.

Не знаєте, що саме гальмує ваш магазин? Ми проведемо експрес-перевірку швидкості та мобільної версії й покажемо 10–15 ключових проблем у PDF за 48 годин. Це безкоштовно, детальніше на сторінці QA-аудиту інтернет-магазину.

Які цілі ставити розробникам

Коли ви замовляєте новий сайт чи оптимізацію, прописуйте вимірювані цілі, а не загальне «щоб швидко». Наші внутрішні вимоги для сайтів, які ми будуємо:

• Lighthouse на мобільному: Performance 95+ на ключових сторінках, SEO та Best Practices — 100;
• LCP до 2,5 с, INP до 200 мс, CLS до 0,1 за польовими даними (75-й перцентиль);
• мінімум JavaScript на головній сторінці, шрифти з власного домену, зображення в сучасних форматах;
• сторонні скрипти лише після згоди користувача.

Ці цифри — цілі, а не гарантії для будь-якого проєкту: на показники впливають хостинг, кількість інтеграцій і контент, який додаєте ви. Але домовитися про метод вимірювання й порогові значення можна до початку роботи. Це один із 12 пунктів, які ми радимо перевіряти, обираючи підрядника на розробку сайту.

Швидкість і дизайн: що вирішується ще до коду

Багато проблем із метриками закладаються на етапі макета. Слайдер із шести великих зображень на першому екрані, відео-фон, три шрифти з десятком накреслень, анімації при прокрутці: усе це гарантовано б'є по LCP та INP. Дизайн, який враховує продуктивність, — це UI/UX дизайн, де кожен блок має «ціну» в мілісекундах і обґрунтування.

Практичні правила для дизайнера та замовника:

• на першому екрані одне головне зображення чи заголовок, а не карусель;
• обмежена кількість шрифтів і накреслень;
• місце під динамічні блоки (відгуки, рекомендації) заплановане в макеті;
• анімація там, де вона допомагає зрозуміти інтерфейс, а не просто прикрашає.

Типові помилки власників магазинів

• Орієнтуватися лише на бал Lighthouse на комп'ютері. Мобільні результати зазвичай гірші й важливіші.
• Перевіряти тільки головну. Картка товару та каталог часто повільніші.
• Додавати плагіни без перевірки наслідків. Кожен віджет має ціну в мілісекундах.
• Вимірювати один раз. Метрики псуються поступово: нова акція, новий банер, новий піксель.
• Вважати швидкість «технічною справою». Це частина бізнес-результату, тому вона має бути в чек-листі приймання сайту.

Для регулярного контролю достатньо раз на місяць пройтися за кроками 1–3 і зафіксувати цифри в таблиці. Якщо проєкт підтримується окремо, швидкість і регрес варто включити в пакет підтримки сайту.

Підсумок

Core Web Vitals — це не про «бали в Google», а про те, чи комфортно покупцеві користуватися вашим магазином. Три метрики, три прості питання: швидко з'являється? швидко відгукується? не стрибає? Перевірити це можна безкоштовно за чверть години, а більшість проблем виправляється зображеннями, сторонніми скриптами та резервуванням місця.

Хочете магазин, який швидко відкривається на телефонах? Ми будуємо сайти з цілями за Core Web Vitals із самого початку. Залиште бриф — оцінимо проєкт за 1 робочий день.