EN UA RU
Главная Блог Performance
Performance

Core Web Vitals для e-commerce: метрики, которые влияют на выручку

A
Flexor Engineering
28 февраля 2025
6 мин чтения

Большинство команд относится к Core Web Vitals как к SEO-галочке. Мы — нет. На commerce-сайтах LCP, CLS и INP напрямую влияют на то, купят у вас или уйдут. Медленная загрузка, прыгающий макет, тормозящие фильтры — пользователи не ждут. Вот откуда берутся реальные проблемы и как мы их чиним.

PageSpeed Insights · Magento 2 Store · Before Optimization SCORE 28 POOR LCP Largest Contentful Paint 6.2s POOR CLS Cumulative Layout Shift 0.38 POOR INP Interaction to Next Paint 280ms NI FIELD DATA · 75TH PERCENTILE · MOBILE

Отчёт 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 при каждом изменении состояния — всё дерево фильтров перерисовывается от одного снятого чекбокса. Разбить эту работу на чанки (или отложить невидимые части) обычно решает проблему.

BEFORE LCP 6.2s CLS 0.38 INP 280ms OPTIMIZED AFTER LCP 1.9s CLS 0.04 INP 140ms IMAGE OPT · FPC WARMUP · LAYOUT SHIFT FIXES · SCRIPT DEFER

После оптимизации изображений, прогрева FPC и исправления сдвигов макета: LCP снизился с 6,2 с до 1,9 с, CLS — с 0,38 до 0,04.

Практические исправления по приоритету

Не все оптимизации дают одинаковую отдачу. По порядку воздействия для большинства Magento/Shopify-магазинов:

  1. Оптимизация изображений. Конвертируйте в WebP или AVIF. Ставьте явные размеры на всё. Добавьте fetchpriority="high" на LCP-изображение и loading="lazy" на всё ниже сгиба. Это одно изменение на нескольких магазинах, с которыми мы работали, сдвинуло LCP с 5 с до уровня ниже 2,5 с.
  2. Настройка Full Page Cache и CDN. Убедитесь, что процент попаданий FPC выше 95% для кешируемых страниц. Поставьте Varnish или Fastly перед origin. TTFB ниже 200 мс ускоряет всё последующее.
  3. Инлайн критического CSS. Стили выше сгиба должны быть инлайнены в <head>, а не загружаться из блокирующей таблицы стилей. Это полностью устраняет один блокирующий рендеринг запрос.
  4. Аудит сторонних скриптов. Commerce-сайты регулярно тащат 15–25 сторонних скриптов — чат-виджеты, тег-менеджеры, инструменты отзывов, пиксели ретаргетинга. Разберитесь, что реально нужно при загрузке страницы, а что может подождать до первого взаимодействия. Откладывание некритичного нередко возвращает 0,5–1,5 с, иногда больше — в зависимости от того, насколько они блокируют.
  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 недели сфокусированной работы — отбиваются в первый же месяц.

Share Post on X LinkedIn
Назад к блогу

Следующий шаг

Работаете над сложной commerce-системой?

Мы помогаем инженерным командам проектировать, строить и масштабировать высоконагруженные платформы — с чётким процессом и предсказуемыми сроками.

Поговорим