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

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

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

Що таке Core Web Vitals

Це три метрики, якими Google оцінює реальний досвід користувача на сторінці. Дані збираються з браузерів Chrome відвідувачів, тому оцінюється не «лабораторний» тест, а те, що бачать ваші покупці. З березня 2024 року метрику FID замінила INP — вона суворіша і показує, наскільки «чуйний» сайт протягом усього візиту, а не лише під час першого кліку.

Порогові значення

Важливий нюанс: сторінка вважається «доброю», якщо показник укладається в норму щонайменше для 75% візитів. Тобто оцінюють не середнє значення, а досвід більшості відвідувачів, включно з тими, хто заходить зі старих смартфонів і через повільний мобільний інтернет. Дані накопичуються за останні 28 днів, тому результат виправлень видно не одразу.

Як швидкість впливає на продажі та SEO

• Конверсія. Кожна зайва секунда очікування — це частина покупців, які не дочекалися сторінки. Особливо болісно на мобільних, звідки приходить більшість трафіку магазинів.
• Реклама. Повільна посадкова сторінка погіршує показник якості в Google Ads, і той самий клік обходиться дорожче. До того ж частина оплачених переходів просто не долітає до сайту.
• Пошук. Core Web Vitals — не головний фактор ранжування: релевантність і якість контенту важать більше. Але серед схожих за якістю сторінок перевагу отримує швидша і зручніша.
• Індексація. Швидкий сервер дозволяє роботу Google обійти більше сторінок за той самий час — для каталогу з тисячами товарів це суттєво.
• Довіра. Сайт, на якому кнопки «стрибають», а кошик реагує із затримкою, виглядає ненадійним — особливо в момент оплати.

Польові та лабораторні дані: чому оцінки різняться

PageSpeed Insights показує два типи даних, і їх часто плутають.

Оцінка Lighthouse від 0 до 100 — це діагностичний інструмент, а не мета. Сайт може мати 70 балів у лабораторному тесті й при цьому всі зелені показники в реальних даних — і навпаки. Орієнтуйтеся на польові дані, а лабораторний тест використовуйте, щоб зрозуміти, що саме виправляти.

Як перевірити свій магазин

1. Відкрийте PageSpeed Insights і вставте адресу не лише головної, а й картки товару та категорії — саме там купують.
2. Дивіться блок «Дані реальних користувачів». Якщо його немає, трафіку поки замало — орієнтуйтеся на лабораторний тест.
3. Перевіряйте мобільну версію: більшість покупців приходить зі смартфонів, і саме там проблеми найпомітніші.
4. У Google Search Console розділ «Основні веб-показники» покаже, які групи сторінок мають проблеми.
5. Для діагностики окремої сторінки відкрийте Chrome DevTools, вкладку Performance: вона показує LCP, INP і CLS у реальному часі, поки ви клікаєте по сайту, і підсвічує елементи, що спричиняють проблеми.
6. Щоб бачити показники всіх відвідувачів, а не лише вибірку Chrome, налаштуйте збір метрик на сайті — наприклад, бібліотекою web-vitals із передачею даних у Google Analytics 4.

Як покращити LCP: перший екран

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

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

Як покращити INP: реакція на дії покупця

INP показує найповільнішу реакцію сторінки на дію користувача за весь візит: клік по фільтру, вибір розміру, «Додати в кошик», відкриття меню. Затримка виникає, коли головний потік браузера зайнятий виконанням JavaScript і не може одразу обробити клік.

• Сторонні скрипти — головна причина. Пікселі, чати, віджети відгуків і поп-апи виконують свій код на кожній сторінці.
• Важка гідратація: великі сторінки, на яких увесь інтерфейс «оживає» одночасно. У Nuxt допомагає лінива гідратація компонентів, які не потрібні одразу.
• Фільтри, що перераховують і перемальовують увесь каталог після кожного кліку. Краще оновлювати лише список товарів і не блокувати інтерфейс на час запиту.
• Відсутність миттєвого відгуку. Після кліку на «Додати в кошик» кнопка має одразу змінити стан, навіть якщо запит до сервера ще виконується.
• Довгі задачі. Великі обчислення варто розбивати на частини, щоб браузер встигав обробляти дії користувача між ними.

Як покращити CLS: стабільна верстка

Ситуація, знайома кожному: тягнешся пальцем до кнопки, а вона зсувається вниз, бо зверху з’явився банер. Для магазину це не лише роздратування, а й випадкові кліки не туди.

• Задавайте ширину й висоту (або aspect-ratio) для всіх зображень і відео — браузер зарезервує місце заздалегідь.
• Шрифти: використовуйте font-display: swap і підбирайте запасний шрифт, близький за метриками, щоб текст не «стрибав» після завантаження основного.
• Банер про cookies, плашки акцій і поп-апи показуйте поверх контенту або в зарезервованому місці, а не вставляйте над сторінкою.
• Ціни, наявність і кнопки, які підвантажуються окремим запитом, мають одразу займати своє місце — допоможуть заглушки-скелетони потрібного розміру.
• Рекламні та партнерські блоки розміщуйте в контейнері фіксованої висоти.

Що перевіряти на різних типах сторінок

Аудит сторонніх скриптів

У звичайному магазині за кілька років накопичуються Google Tag Manager, пікселі Meta і TikTok, аналітика поведінки, онлайн-чат, віджет зворотного дзвінка, віджет відгуків і кілька скриптів, про які вже ніхто не пам’ятає. Кожен окремо «важить небагато», але разом вони можуть забирати більшу частину часу головного потоку.

1. Складіть список усіх сторонніх скриптів: у DevTools на вкладці Network відфільтруйте запити до чужих доменів.
2. Для кожного дайте відповідь: хто ним користується і яке рішення на його основі ухвалюється? Невикористані — видаляйте.
3. Перевірте дублі: дві системи аналітики, два пікселі одного сервісу, теги, що спрацьовують двічі.
4. Відкладіть завантаження всього, що не потрібно для першого екрана: чат і віджети можна вантажити після першої взаємодії або через кілька секунд.
5. Де можливо, переносьте відстеження на сервер (серверний GTM, Conversions API) — це знімає навантаження з браузера покупця.

Зображення: практичний чекліст

Фото товарів, завантажені прямо з камери, важать мегабайти. Щоб вони не гальмували каталог:

• Формати WebP або AVIF з автоматичною конвертацією під час завантаження фото в адмінку.
• Кілька розмірів кожного фото й атрибути srcset та sizes — телефон не повинен завантажувати картинку для 4K-монітора.
• Стискання з якістю близько 75–85% — для фото товарів різниця з оригіналом непомітна.
• Ліниве завантаження для всього, що нижче першого екрана.
• CDN для зображень, щоб вони віддавалися із сервера, ближчого до покупця.
• Явні розміри для кожного зображення, щоб уникнути зсувів верстки.

Сервер, кешування і TTFB

Якщо HTML приходить повільно, жодна оптимізація фронтенду не врятує LCP. Добрим вважається час відповіді сервера до 0,8 с. Що на нього впливає:

• Рендеринг у браузері замість сервера. Якщо сторінка збирається JavaScript-ом уже в браузері, покупець спершу бачить порожній екран. Серверний рендеринг (SSR) віддає готовий HTML одразу — це і швидше для людей, і зрозуміліше для пошукових роботів.
• Відсутність кешу: кожен запит заново збирає сторінку з бази. Кешування в Redis і на рівні CDN знімає більшу частину навантаження.
• Повільні запити до бази: відсутні індекси, фільтри, що перебирають усі товари, неоптимальні вибірки.
• Хостинг: дешевий спільний хостинг під навантаженням і сервер далеко від аудиторії додають сотні мілісекунд до кожної сторінки.

Чекліст оптимізації по кроках

1. Зафіксуйте поточні показники в PageSpeed Insights і Search Console для головної, категорії, товару й кошика.
2. Визначте, яка метрика найгірша і на яких сторінках, — почніть із неї.
3. Перевірте TTFB: якщо він перевищує 0,8 с, спершу займіться сервером і кешуванням.
4. Оптимізуйте LCP-елементи: формат, розмір, пріоритет завантаження, без лінивого завантаження.
5. Проведіть аудит сторонніх скриптів і приберіть зайві.
6. Задайте розміри всім медіа та налаштуйте шрифти, щоб прибрати зсуви верстки.
7. Перевірте реакцію фільтрів, вибору варіанта і кнопки «Купити» на недорогому смартфоні.
8. Через 28 днів порівняйте польові дані з початковими.

Як не втратити швидкість після запуску

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

• Встановіть бюджет швидкості, наприклад: LCP до 2,5 с на картці товару на мобільному. Кожну нову функцію перевіряйте на відповідність йому.
• Додавання нового скрипту — це рішення, а не дрібниця. Узгоджуйте його з розробниками.
• Автоматизуйте оптимізацію фото, щоб вага банерів на сайті не залежала від уважності контент-менеджера.
• Раз на місяць переглядайте звіт «Основні веб-показники» в Search Console.

Часті запитання

Чи обов’язково отримати 100 балів у PageSpeed Insights?

Ні. Бали лабораторного тесту — це підказка для діагностики. Для пошуку та покупців важливі польові дані: щоб LCP, INP і CLS були в зеленій зоні для більшості реальних візитів.

Чому в PageSpeed Insights немає даних реальних користувачів?

Google показує польові дані лише для сторінок і сайтів, які мають достатньо трафіку з Chrome. Для нового або невеликого магазину орієнтуйтеся на лабораторний тест і збирайте метрики самостійно.

Коли покращення стануть помітні в Search Console?

Польові дані накопичуються за 28 днів, тож повна картина після виправлень з’являється приблизно через місяць. Перевірити зміни одразу можна в лабораторному тесті.

Чи можна прискорити магазин на WordPress без переїзду?

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

Що важливіше для швидкості: хостинг чи код?

Обидва. Добрий хостинг не врятує сторінку з десятком важких скриптів, а оптимізований код буде повільним на перевантаженому сервері. Почніть із вимірювання TTFB: він покаже, де проблема — на сервері чи в браузері.

Чи допоможе PWA прискорити магазин?

PWA прискорює повторні відвідування завдяки кешу, але не виправляє повільне перше завантаження. Спершу оптимізуйте сам сайт, а потім додавайте PWA-можливості. Детальніше — у статті PWA-додаток для інтернет-магазину.

Хочете, щоб ваш магазин був швидким із першого дня? Подивіться, що входить у інтернет-магазин під ключ.