Core Web Vitals для e-commerce: метрики, що впливають на виручку
Більшість команд ставиться до Core Web Vitals як до SEO-галочки. Ми — ні. На commerce-сайтах LCP, CLS та INP прямо впливають на те, куплять у вас чи підуть. Повільне завантаження, стрибаючий макет, гальмуючі фільтри — користувачі не чекають. Ось звідки ростуть реальні проблеми і як ми їх виправляємо.
Звіт PageSpeed Insights для Magento 2 до оптимізації. LCP — 6,2 с, CLS — 0,38 — обидва значно за межею «Добре».
Три метрики і чому вони важливі в e-commerce
LCP — Largest Contentful Paint
LCP вимірює, скільки часу потрібно для рендерингу найбільшого видимого елементу. На сторінці товару це зазвичай головне зображення. На головній — часто повноширинний банер.
Поріг «Добре» від Google — менше 2,5 секунди. Більшість Magento-магазинів «з коробки» показують 4–7 секунд без жодних оптимізацій. Патерн, який ми знову і знову спостерігаємо: скинути секунду з мобільного LCP — і конверсія підтягується. Точна цифра залежить від магазину й категорії, але напрямок достатньо передбачуваний, щоб на нього спиратися.
Винуватці майже завжди одні й ті самі: неоптимізовані зображення (не той формат, немає fetchpriority="high" на hero-елементі), JS, що блокує рендеринг у <head>, і повільний TTFB через промахи FPC-кешу. Майже завжди одне з трьох.
CLS — Cumulative Layout Shift
CLS вимірює візуальну нестабільність — елементи, що «стрибають» під час завантаження сторінки. Класичний порушник в e-commerce — кнопка «Додати до кошика», яка зміщується, коли промобейдж або ціна завантажується асинхронно.
Вище 0,1 — ви в зоні «Потребує покращення». На мобільних кнопка, що зміщується, провокує випадкові тапи і тапи від роздратування. Це один із тих UX-провалів, що не очевидний у записах сесій, але добре видний у цифрах.
Виправлення зазвичай включає явні атрибути ширини та висоти для зображень, зарезервований простір для динамічного контенту (акції, відгуки) та відмову від вставки контенту вище наявних елементів DOM.
INP — Interaction to Next Paint
INP замінив FID у березні 2024-го. Різниця суттєва: FID міряв лише першу взаємодію; INP фіксує найгіршу затримку серед усіх. Тож панель фільтрів, що гальмує при кожному кліку по фасету, спливе тут — навіть якщо початкове завантаження сторінки здавалося швидким.
Вище 200 мс — користувачі це відчувають. На PLP-сторінках із JS-фільтрами корінь проблеми майже завжди один: синхронна маніпуляція DOM при кожній зміні стану — все дерево фільтрів перемальовується від одного знятого чекбоксу. Розбити цю роботу на чанки (або відкласти невидимі частини) зазвичай вирішує проблему.
Після оптимізації зображень, прогріву FPC та виправлення зсувів макету: LCP знизився з 6,2 с до 1,9 с, CLS — з 0,38 до 0,04.
Практичні виправлення за пріоритетом
Не всі оптимізації дають однакову віддачу. За порядком впливу для більшості Magento/Shopify-магазинів:
- Оптимізація зображень. Конвертуйте в WebP або AVIF. Ставте явні розміри на все. Додайте
fetchpriority="high"на LCP-зображення іloading="lazy"на все нижче згину. Ця одна зміна на кількох магазинах, з якими ми працювали, зсунула LCP з 5 с до рівня нижче 2,5 с. - Налаштування Full Page Cache та CDN. Переконайтеся, що відсоток влучань FPC вище 95% для кешованих сторінок. Поставте Varnish або Fastly перед origin. TTFB нижче 200 мс прискорює все наступне.
- Інлайн критичного CSS. Стилі вище згину мають бути інлайновані в
<head>, а не завантажуватися з блокуючої таблиці стилів. Це повністю усуває один запит, що блокує рендеринг. - Аудит сторонніх скриптів. Commerce-сайти регулярно тягнуть 15–25 сторонніх скриптів — чат-віджети, тег-менеджери, інструменти відгуків, пікселі ретаргетингу. Розберіться, що реально потрібно при завантаженні сторінки, а що може зачекати до першої взаємодії. Відкладення некритичного нерідко повертає 0,5–1,5 с, іноді більше — залежно від того, наскільки вони блокують.
- Резервування місця під зсуви макету. Встановлюйте явні пропорції для всіх зображень та слотів банерів. Уникайте вставки промоконтенту без зарезервованого місця.
Вимірювання того, що важливо
Лабораторні дані — Lighthouse, PageSpeed Insights — корисні для відловлювання регресій у CI. Але вони не відображають того, що бачать ваші реальні користувачі. Мікс пристроїв, умови мережі, CDN-маршрутизація — нічого цього немає в лабораторному запуску з однієї точки.
Налаштуйте Real User Monitoring і дивіться дані CrUX (Chrome UX Report), щоб відстежувати LCP на 75-му перцентилі по реальному трафіку. Саме цю цифру Google використовує для ранжування. Це означає: кожен четвертий користувач має мати «хороший» досвід, щоб сайт отримав високу оцінку — не медіана, не найкращий випадок.
Бізнес-кейс
Прив'язати конкретну цифру до покращень продуктивності можна лише через A/B-тестування у вашому контексті — загальні бенчмарки не враховують ні вашу аудиторію, ні категорію товарів. З нашого досвіду: на сайтах з виручкою близько €50K на місяць покращення мобільного LCP з 5 с до 2 с зазвичай повертає 3–6%. Інженерні зусилля — 3–4 тижні зосередженої роботи — відбиваються вже в перший місяць.
Наступний крок
Працюєте над складною commerce-системою?
Ми допомагаємо інженерним командам проєктувати, будувати та масштабувати високонавантажені платформи — з чітким процесом та передбачуваними строками.
Поговорімо