Core Web Vitals — это три метрики, по которым Google оценивает пользовательский опыт: скорость загрузки основного контента, отзывчивость интерфейса и визуальную стабильность. Для интернет-магазина они важны не сами по себе, а потому что напрямую связаны с конверсией: медленный первый экран и «залипающие» кнопки убивают продажи на мобильном трафике.
В 2026 году набор метрик стабилен, но акценты сместились. INP окончательно заменил FID, мобильная версия стала основной точкой входа, а сторонние скрипты — одним из главных источников проблем. Ниже — что именно проверять и в каком порядке исправлять.
Из чего состоят Core Web Vitals
Метрик три, и каждая отвечает за свой тип ощущений. Оценка считается по 75-му перцентилю реальных пользователей за последние 28 дней. Это значит, что быстрый офисный компьютер не поможет: важны данные мобильных посетителей на обычном соединении.
Время до отрисовки самого крупного элемента первого экрана: баннера, фото товара или заголовка. Хорошо — до 2,5 секунды, плохо — больше 4 секунд.
Задержка между действием пользователя и видимым откликом интерфейса. Хорошо — до 200 миллисекунд, плохо — больше 500 миллисекунд.
Суммарный сдвиг вёрстки за время просмотра. Хорошо — до 0,1, плохо — больше 0,25.
Lighthouse показывает, что можно улучшить, но не отражает реальный опыт всех посетителей. Сначала смотрим данные поля — CrUX, Метрику и RUM, затем воспроизводим проблему в лаборатории.
LCP: что чаще всего тормозит
LCP — самая заметная метрика для покупателя. Пока первый экран пустой, человек не видит ни товара, ни цены, ни кнопки. В интернет-магазинах главный элемент обычно оказывается изображением товара или баннером, поэтому проблемы чаще всего связаны с картинками и сервером.
- Огромное изображение первого экрана без WebP или AVIF, srcset и правильных размеров.
- Ленивая загрузка главной картинки: атрибут loading="lazy" на первом экране задерживает LCP.
- Медленный TTFB из-за тяжёлых запросов к базе, синхронных интеграций или отсутствия кэша.
- Блокирующие CSS и шрифты, которые не дают браузеру отрисовать контент.
- Слайдер, который подгружает первый слайд через JavaScript уже после загрузки страницы.
- Сторонние скрипты метрик, чатов, виджетов и пикселей, конкурирующие за сеть и процессор.
- Отсутствие CDN для статики и изображений.
- Слишком тяжёлый DOM и лишние обёртки, из-за которых браузер долго строит страницу.
Как ускорить LCP
Откройте Lighthouse или Performance в DevTools и посмотрите, какой именно элемент считается главным на мобильном и десктопе. На разных шаблонах это могут быть разные картинки.
Если сервер отдаёт HTML дольше 600–800 миллисекунд, сначала займитесь кэшем, запросами и инфраструктурой. Оптимизация картинок не спасёт медленный ответ.
Переведите в WebP или AVIF, задайте width и height, подготовьте srcset под мобильные и десктоп, уберите lazy с первого экрана.
Вынесите критический CSS, отложите некритичные стили и скрипты, используйте font-display: swap и preload для основного шрифта.
Смоделируйте 3G или Slow 4G и средний Android. Именно там LCP отличается от красивых цифр на Wi-Fi в офисе.
Часто самый большой эффект даёт не переписывание фронтенда, а несколько точечных изменений: кэш HTML, сжатые изображения первого экрана и отключение пары тяжёлых виджетов. Эти работы занимают дни, а не месяцы.
INP: почему интерфейс «задумывается»
INP измеряет задержку не только кликов, но и любых взаимодействий: нажатий, тапов, ввода в поле. Проблема проявляется, когда главный поток занят длинной JavaScript-задачей и не может быстро показать реакцию. Пользователь нажимает «В корзину», а кнопка отвечает через секунду — и он нажимает ещё раз.
- Длинные задачи в JavaScript: обработчики, которые считают цены, фильтры или рекомендации прямо в браузере.
- Тяжёлые библиотеки, подключённые целиком ради одной функции.
- Синхронные запросы к API в момент клика, хотя данные можно загрузить заранее.
- Большие списки товаров и фильтров, которые перерисовываются при каждом действии.
- Сторонние виджеты: чаты, отзывы, аналитика и A/B-тесты.
- Гидратация сложного фронтенда на слабом устройстве.
Как снизить INP
- Разбейте длинные задачи на части через setTimeout, requestIdleCallback или планировщик.
- Вынесите тяжёлые вычисления на сервер или в Web Worker.
- Используйте делегирование событий вместо обработчика на каждой карточке.
- Отложите некритичные скрипты и загружайте виджеты только после взаимодействия.
- Проверяйте не только в Chrome на быстром ноутбуке, но и на среднем Android с throttling.
Отдельная ловушка — «оптимизация ради оценки». Можно получить зелёный Lighthouse, но оставить тяжёлый обработчик на кнопке оформления заказа. Проверяйте именно критические сценарии: выбор товара, добавление в корзину, переход между шагами checkout.
CLS: почему прыгает вёрстка
CLS раздражает пользователей и приводит к случайным кликам. Человек хочет нажать «Купить», а в этот момент над кнопкой появляется баннер, и палец попадает в другое место. Для магазина это прямые потери и рост ошибок в аналитике.
- Изображения и видео без указанных width и height.
- Баннеры, промо-блоки и рекламные места без зарезервированной высоты.
- Шрифты, которые подменяются после загрузки и меняют размеры текста.
- Cookie-баннеры и всплывающие окна, сдвигающие основной контент.
- Динамические блоки рекомендаций, отзывов и «с этим покупают».
- Анимации, которые меняют layout вместо transform и opacity.
Лечится CLS обычно быстро: зарезервируйте место под все динамические блоки, задайте размеры изображений и не вставляйте баннеры поверх уже отрисованного контента. Это одна из самых дешёвых побед в скорости.
Как измерять и не обманывать себя
Есть три уровня данных, и путать их нельзя. Данные поля показывают реальный опыт, лаборатория — воспроизводимую картину, а синтетические тесты помогают ловить регрессии после релизов.
- CrUX и PageSpeed Insights — агрегированные данные реальных пользователей Chrome.
- Яндекс Метрика и собственный RUM — скорость на вашей аудитории, включая браузеры без CrUX.
- Lighthouse и WebPageTest — лабораторные замеры для диагностики и сравнения до/после.
- Логи и APM — TTFB, медленные запросы, ошибки и время ответа внешних сервисов.
Средняя оценка по сайту скрывает проблему: главная может быть быстрой, а карточка товара — грузиться шесть секунд. Разбивайте отчёты по типам страниц: главная, каталог, карточка, корзина, checkout.
План на 30 дней
Зафиксируйте LCP, INP и CLS по ключевым шаблонам на мобильных и десктопе. Сохраните отчёты и настройте еженедельный срез, чтобы видеть динамику.
Проверьте TTFB, изображения первого экрана, шрифты и блокирующие скрипты. Обычно этого достаточно, чтобы сдвинуть метрику в зелёную зону.
Отключите лишние виджеты, разбейте длинные задачи, зарезервируйте место под динамические блоки. Проверьте критические сценарии на среднем устройстве.
Добавьте метрики в мониторинг, настройте алерты на деградацию и проверку после каждого релиза. Иначе скорость вернётся к исходной через пару месяцев.
Типичные ошибки
- Гнаться за 100 баллами Lighthouse вместо реальных метрик и конверсии.
- Оптимизировать только главную, забыв каталог и карточку товара.
- Ставить loading="lazy" на все изображения без исключений для первого экрана.
- Включать агрессивный кэш без инвалидации и показывать покупателям старые цены.
- Не проверять результат после релиза и не оставлять мониторинг.
Что в итоге
Core Web Vitals — не самоцель, а способ сделать путь к заказу быстрым и предсказуемым. Начните с данных поля, найдите проблемные шаблоны и исправляйте в порядке влияния на деньги: сначала первый экран и checkout, затем остальное.
Если сайт большой, не пытайтесь улучшить всё сразу. Возьмите три шаблона, которые приносят основную выручку, и доведите их до хороших значений. Такой подход даёт измеримый результат за недели и не требует переписывания проекта.
Отдельно про мобильный трафик
Мобильные пользователи чаще всего видят худшие метрики: слабее процессор, нестабильная сеть, больше сторонних скриптов. Поэтому проверять Core Web Vitals нужно не на быстром ноутбуке, а на среднем Android с throttling. Именно там проявляются проблемы, которые незаметны в лаборатории.
- Тестируйте на Slow 4G и среднем устройстве, а не только на Wi-Fi.
- Отключайте неиспользуемые виджеты и откладывайте чаты до взаимодействия.
- Смотрите метрики по регионам: скорость может отличаться из-за сети и CDN.
- Проверяйте после каждого релиза, а не раз в квартал.
Не оптимизируйте под средний показатель по всему сайту. Один медленный шаблон checkout может стоить дороже, чем десять быстрых информационных страниц. Приоритет — те страницы, где пользователь принимает решение о покупке.
Снимем метрики по ключевым шаблонам, найдём узкие места и покажем, что исправлять первым. Без общих слов и переписывания ради переписывания.
Заказать аудит →
