Core Web Vitals для e-commerce: виправлення LCP, INP і CLS
Повільні сторінки товарів коштують конверсій. Ось що насправді означають LCP, INP і CLS для інтернет-магазинів, і найвпливовіші виправлення для кожної метрики.
Ви запустили PageSpeed Insights на сторінці товару. Три червоні індикатори дивляться на вас. Оцінка — 41. Сторінка повільно завантажується й на вашому тестовому телефоні, але ви не впевнені, яка з трьох метрик насправді коштує вам продажів — і яку виправляти першою.
Core Web Vitals — це три метрики завантаження та взаємодії, які Google публікує для кожного сайту. Вони впливають на ранжування на полях. На конверсію вони впливають значно більше. Для інтернет-магазину, де кожна секунда затримки знімає довіру з кнопки купівлі, самого лише впливу на конверсію достатньо, щоб виправдати їх виправлення — ще до того, як ви врахуєте SEO.
Три метрики, коротко
- LCP (Largest Contentful Paint) вимірює, скільки часу проходить, поки найбільший видимий елемент завершить завантаження — зазвичай це головне зображення товару. Добре: до 2.5 секунди. Погано: понад 4 секунди.
- INP (Interaction to Next Paint) вимірює, наскільки чуйною почувається ваша сторінка на дотики та кліки. Замінила FID у березні 2024. Добре: до 200 мс. Погано: понад 500 мс.
- CLS (Cumulative Layout Shift) вимірює, наскільки елементи стрибають при завантаженні сторінки. Добре: до 0.1. Погано: понад 0.25.
Посібник web.dev із Core Web Vitals від Google охоплює формальні визначення; решта цієї статті зосереджена на тому, що з ними робити в реальному магазині.
Чому e-commerce страждає сильніше за блоги
Допис у блозі — це текст, можливо, одне головне зображення, можливо, один ембед. Сторінка товару — це головне зображення, галерея мініатюр, віджет відгуків, карусель рекомендацій, чат-бульбашка, попап з upsell, висувний кошик, аналітика для трьох платформ, реєстратор теплових карт і фреймворк A/B-тестування. Кожен із них віддає JavaScript. Кожен з них конкурує за головний потік.
Типова вітрина Shopify у 2026 році віддає певну комбінацію з:
- Klaviyo (захоплення email, попапи)
- Privy або OptinMonster (exit-intent)
- Smile.io або Loyalty Lion (віджет винагород)
- Yotpo або Judge.me (відгуки)
- Tidio або Gorgias (чат)
- Hotjar або Microsoft Clarity (запис сесій)
- GA4, Meta Pixel, TikTok Pixel (аналітика)
Кожен з них здається безкоштовним, коли ви його встановлюєте. Жоден з них не безкоштовний. Ціна виявляється спершу в INP, потім у LCP, потім у вашому коефіцієнті конверсії.
Виправлення LCP для сторінок товарів
LCP на сторінці товару — це майже завжди головне зображення. Три зміни в порядку впливу:
1. Віддавайте правильний формат і розмір. PNG 4000×4000 прямо від вашого фотографа товарів важить 6 МБ. Це саме зображення як належним чином розміряний WebP або AVIF на тих розмірах, які фактично рендеряться, часто важить менше 150 КБ. І Shopify, і WooCommerce обробляють це, якщо ви припините перекривати їхнє масштабування.
2. Підготовляйте головне зображення наперед. Додайте preload-підказку в <head>, щоб браузер почав отримувати його ще до парсингу решти сторінки:
<link rel="preload" as="image"
href="/products/wallet-hero.webp"
imagesrcset="/products/wallet-hero-400.webp 400w,
/products/wallet-hero-800.webp 800w,
/products/wallet-hero-1200.webp 1200w"
imagesizes="(max-width: 768px) 100vw, 50vw">
3. Не використовуйте lazy-load для зображень над згином. loading="lazy" на вашому головному зображенні — найпоширеніший вбивця LCP на сторінках товарів. Використовуйте lazy-load для мініатюр і знімків галереї під згином; ніколи — для першого видимого зображення.
Довідка: Optimize LCP на web.dev.
Виправлення INP для сторінок товарів
INP — це там, де більшість магазинів має найгірший час. Шаблон послідовний: сторінка виглядає завантаженою, користувач торкається «Додати в кошик», і нічого не відбувається 600 мс. Ця затримка — це JavaScript, що виконується в головному потоці.
1. Відкладайте некритичні скрипти. Додайте defer або завантажуйте через async усе, що не потрібне для рендерингу кнопки купівлі. Віджети відгуків, чат-бульбашки, рушії рекомендацій — усе це має завантажуватися після того, як сторінка стане інтерактивною, а не під час цього.
2. Безжально аудитуйте сторонні віджети. Більшість магазинів несуть два віджети, які роблять однакову роботу (два інструменти аналітики, два провайдери попапів). Оберіть один. Видаліть інший. Кожен зайвий віджет нашаровується.
3. Замініть важкі віджети відгуків серверно-відрендереними рейтингами. Віджет відгуків, який гідратує 500 відгуків у DOM на клієнті, — топ-3 порушник INP. Рендеріть зведений рейтинг і три топ-відгуки на сервері; завантажуйте повний список відгуків ліниво, коли користувач до нього прокрутить.
Для магазинів на Next.js / React-основі правильні «кролячі нори» — це документація React щодо важкої гідратації та стрімінгового SSR від Next.js.
Виправлення CLS для сторінок товарів
Зсув макета — найдешевший з трьох для виправлення і найбільш ганебний, якщо залишити його зламаним. Три зміни:
1. Встановлюйте явні розміри для кожного зображення. Завжди вказуйте атрибути width і height (або CSS aspect-ratio), щоб браузер резервував місце до завантаження зображення:
<img src="/products/wallet.webp"
width="800" height="800"
alt="Hand-stitched leather wallet, front view">
2. Використовуйте font-display: swap обережно. Спалах нестилізованого тексту зсуває макет, коли завантажується кастомний шрифт. Або підготовляйте шрифт наперед, або використовуйте font-display: optional, щоб запобігти пізнім підміненням.
3. Резервуйте місце для ембедів. Віджети відгуків, каруселі рекомендацій і слоти оголошень, які вставляються над наявним контентом, спричиняють каскадні зсуви. Загорніть їх у контейнер фіксованої висоти, поки вони завантажуються.
Довідка: Optimize CLS.
Як EshopAuditor виявляє це
Оцінка CWV в EshopAuditor відображає продуктивність вашої головної сторінки, виміряну Google PageSpeed Insights у стратегіях Mobile та Desktop. Решта просканованих сторінок аналізується щодо HTML-структури, schema, метаданих і on-page SEO-проблем — але без запуску Lighthouse для кожної сторінки. Lighthouse для кожної сторінки обчислювально дорого запускати в масштабі; CWV головної — індикативний сигнал для типового профілю продуктивності всього сайту.
CWV головної — індикативний, не вичерпний: якщо ваша головна повільна, ваші сторінки товарів майже завжди повільніші (та сама тема, ті самі віджети, те саме завантаження скриптів). Для точного CWV для кожної сторінки в усьому каталозі поєднуйте цей звіт з оглядом Core Web Vitals у Google Search Console, який використовує польові дані CrUX від реальних користувачів для кожного URL, для якого Google має покази.
Несправедлива правда про CWV і ранжування
Google був чітким: Core Web Vitals — це сигнал ранжування, але незначний. Дві сторінки з порівнянною якістю контенту, за запитом, де CWV близький, побачать, як CWV діє як тайбрейкер. От і все.
На що Core Web Vitals впливає драматично — це коефіцієнт конверсії. 1-секундна затримка LCP не скине вас зі сторінки 1 на сторінку 2 Google. Але вона вимірно б'є по коефіцієнту checkout — і на трафіку e-commerce це падіння конверсії зазвичай затьмарює будь-який SEO-плюс чи мінус. На чверті трафіку дельта окуплює ваші інструменти, ваші рекламні витрати та ваш час кілька разів.
Виправляйте Core Web Vitals тому, що це робить ваш магазин прибутковішим, а не тому, що так каже Google. SEO-виграш — це бонус.
Запустіть безкоштовний аудит вашого магазину на eshopaudit.io — реєстрація не потрібна для першого сканування.