Как улучшить Core Web Vitals интернет-магазина
Core Web Vitals описывают три стороны пользовательского опыта: когда появился основной контент, насколько быстро страница отвечает на действия и остаётся ли интерфейс визуально стабильным. Для интернет-магазина эти метрики особенно чувствительны к фотографиям товара, фильтрам, вариантам, виджетам и большому JavaScript-бандлу.
Работа с метриками начинается не с попытки получить 100 баллов в одном тесте, а с определения проблемного шаблона и конкретной причины. Категория, карточка товара и корзина могут иметь разные показатели и требовать разных исправлений.
Какие метрики считаются хорошими
В текущем наборе Core Web Vitals используются:
- LCP — момент отрисовки крупнейшего изображения, текстового блока или видео в области просмотра;
- INP — задержка визуального ответа на взаимодействия пользователя;
- CLS — величина неожиданных сдвигов содержимого.
Google относит к хорошим значениям LCP до 2,5 секунды, INP до 200 мс и CLS до 0,1. Оценка строится по 75-му процентилю просмотров, отдельно для мобильных и настольных устройств [1]. Это означает: единичный быстрый лабораторный запуск не заменяет данные реальных посетителей.
Сначала определить, какие страницы проигрывают
Магазин делят минимум на группы:
- главная и посадочные страницы;
- категории без фильтра и с применёнными фильтрами;
- карточки простого товара и товара с предложениями;
- поиск;
- корзина и оформление заказа.
Полевые данные берут из отчёта Core Web Vitals в Search Console, PageSpeed Insights или собственной системы RUM. Лабораторный тест используют, чтобы воспроизвести проблему и увидеть сетевой водопад, загрузку главного потока и сдвиги. Web.dev рекомендует начинать именно с полевых данных, если они доступны, а затем переходить к диагностике конкретных URL [2].
LCP: почему поздно появляется основной контент
На карточке товара LCP часто становится главное фото, а в категории — заголовок, баннер или крупная карточка. Полное время LCP складывается из TTFB, задержки начала загрузки ресурса, самой загрузки и задержки отрисовки [3]. Это удобная схема: она показывает, на каком этапе теряется время.
Если медленно отвечает сервер
Высокий TTFB сдвигает загрузку всех последующих ресурсов. Проверяют кеширование HTML, PHP, SQL, внешние API, редиректы и расстояние до сервера. Ускорение картинки не компенсирует несколько секунд ожидания первого байта.
Если браузер поздно находит LCP-изображение
Главное изображение должно быть обнаружимо в исходном HTML. Его не стоит подставлять только после выполнения JavaScript или помечать loading="lazy". Если ресурс скрыт в CSS или цепочке зависимостей, обоснованно применяют preload или fetchpriority="high", но не раздают высокий приоритет множеству картинок [3].
Если файл слишком большой
Используют WebP или AVIF там, где поддержка проекта это позволяет, задают srcset и sizes, чтобы телефон не скачивал десктопный оригинал. Картинки ниже первого экрана можно загружать лениво; это освобождает канал для главного ресурса [4].
INP: почему фильтр, меню или корзина реагируют с задержкой
INP страдает, когда основной поток браузера занят длинной задачей. В магазине это бывает при инициализации фильтра, перерасчёте вариантов, рендеринге большого списка, работе нескольких аналитических и рекламных скриптов.
Диагностика начинается с записи взаимодействия: открыть фильтр, сменить размер, добавить товар, изменить количество. В Performance-профиле смотрят, какой обработчик занял время, сколько DOM-узлов он меняет и не запускает ли синхронный большой пересчёт.
Типичные исправления:
- разделить длинную работу на небольшие задачи и отдавать управление браузеру;
- не выполнять тяжёлую инициализацию виджетов до момента, когда они нужны;
- уменьшить объём собственного и стороннего JavaScript;
- избегать повторного полного рендера списка при локальном изменении;
- перенести подходящие вычисления в Web Worker, если они не требуют DOM.
Длинными в инструментах браузера считаются задачи свыше 50 мс; одна такая задача не равна значению INP, но помогает найти участки кода, которые блокируют реакцию интерфейса [5].
CLS: почему элементы прыгают во время загрузки
В каталоге сдвиги часто создают изображения без зарезервированного размера, поздно появившиеся баннеры, блок доставки, отзывы, чат и смена шрифта. Пользователь может нажать «Купить», а в этот момент кнопка сдвинется — это уже функциональная проблема, а не только метрика.
Для изображений и видео задают width и height либо CSS-соотношение сторон. Под рекламные и рекомендательные блоки заранее резервируют место. Динамическое сообщение лучше добавлять в предусмотренный контейнер, а не вставлять над уже отрисованным содержимым. MDN отдельно указывает, что отсутствие размеров у адаптивного изображения оставляет до загрузки нулевую высоту и создаёт сдвиг [4].
Шрифты сокращают до необходимых начертаний, используют WOFF2 и подходящую стратегию font-display. Если смена метрик запасного и основного шрифта заметна, подбирают близкий fallback или корректируют его метрики.
Как проверять результат
- Сохранить исходные полевые значения и лабораторный профиль.
- Исправить одну установленную причину на тестовой версии.
- Проверить ключевой сценарий магазина и отсутствие визуальных ошибок.
- Повторить лабораторный тест несколько раз в одинаковых условиях.
- После публикации следить за ошибками и собственной RUM-аналитикой.
- Дождаться обновления агрегированных полевых данных: отчёты на основе CrUX используют скользящий период, поэтому эффект появляется не мгновенно [2].
Проверять нужно не одну страницу, а репрезентативный набор каждого шаблона. Если новая карточка стала быстрой, а старые товары с тяжёлыми изображениями нет, проблему нельзя считать решённой.
Влияние на поиск без преувеличений
Core Web Vitals используются системами ранжирования Google, но хороший отчёт не гарантирует высоких позиций. Google отдельно подчёркивает, что релевантность и общая полезность страницы остаются важнее попытки получить идеальный балл [6]. Для бизнеса главный эффект ускорения — посетителю проще увидеть товар, применить фильтр и завершить заказ.
Источники
[1] web.dev — пороговые значения Core Web Vitals: web.dev/articles/defining-core-web-vitals-thresholds
[2] web.dev — рабочий процесс с инструментами Core Web Vitals: web.dev/articles/vitals-tools
[3] web.dev — оптимизация Largest Contentful Paint: web.dev/articles/optimize-lcp
[4] MDN — оптимизация изображений и мультимедиа: developer.mozilla.org/.../Performance/Multimedia
[5] MDN — мониторинг и оптимизация веб-производительности: developer.mozilla.org/en-US/blog/optimize-web-performance/
[6] Google Search Central — Page Experience: developers.google.com/search/docs/appearance/page-experience