Магазин выглядит отлично, но в отчёте поисковика страницы помечены жёлтым и красным, а покупатели жалуются, что «сайт тормозит» и «кнопка уезжает из-под пальца». За этими ощущениями стоят конкретные, измеримые величины — Core Web Vitals. Это три метрики, которыми Google оценивает реальное удобство загрузки страницы, и они влияют и на поведение людей, и на позиции в поиске.
Ниже — разбор без воды: что такое LCP, CLS и INP простыми словами, где именно они проседают в интернет-магазине на 1С-Битрикс и какими штатными инструментами их вытягивают в зелёную зону. Это выжимка из наших проектов по ускорению магазинов на 1С-Битрикс и разработке интернет-магазинов на 1С-Битрикс — с упором на то, что реально двигает метрики.
Коротко
- Core Web Vitals — три метрики: LCP (скорость основного контента), CLS (стабильность вёрстки), INP (отзывчивость).
- Зелёная зона: LCP до 2,5 с, CLS до 0,1, INP до 200 мс — по реальным пользователям, а не «в среднем».
- LCP в магазине чаще всего тянут медленная сборка страницы и тяжёлые картинки; лечит композит, кэш и оптимизация изображений.
- CLS чинят размерами картинок и резервом места под динамику, INP — разгрузкой JavaScript.
Что такое Core Web Vitals и почему они важны
Core Web Vitals (дословно — «основные веб-показатели жизнеспособности») — это набор метрик от Google, который оценивает не «красоту» сайта, а реальный пользовательский опыт загрузки: быстро ли появился контент, не дёргается ли вёрстка, отзывчиво ли реагирует страница на клики. Ключевая особенность — метрики считаются по живым посетителям, на их реальных устройствах и сетях, а не только в лабораторном тесте.
Почему это важно для магазина? Во-первых, скорость и стабильность напрямую влияют на поведение: с медленной или «прыгающей» страницы люди уходят, не дойдя до корзины. Во-вторых, Core Web Vitals — это сигнал ранжирования: при прочих равных поиск предпочтёт страницу, которая удобнее загружается. То есть плохие метрики бьют дважды — по конверсии и по трафику.
Чем Core Web Vitals отличаются от «просто скорости»
Раньше скорость мерили одной цифрой вроде «время загрузки страницы». Но пользователь воспринимает загрузку не как одно число, а как несколько разных ощущений: «когда я увидел контент», «дёргалось ли всё при загрузке», «откликнулась ли страница на мой клик». Core Web Vitals как раз раскладывают восприятие на эти три измеримые составляющие — поэтому работать с ними точнее, чем гнаться за абстрактной «общей скоростью».
Три метрики: LCP, CLS и INP
В основе Core Web Vitals лежат три метрики, и каждая отвечает за свою сторону опыта. Разберём их по очереди — без формул, на бытовом языке.
- LCP (Largest Contentful Paint) — «когда появился главный контент». Это время до отрисовки крупнейшего видимого элемента: большого баннера, главного фото товара, заголовка раздела. Чем быстрее посетитель видит «суть» страницы, тем лучше LCP.
- CLS (Cumulative Layout Shift) — «насколько прыгала вёрстка». Метрика суммирует неожиданные сдвиги элементов при загрузке: когда подгрузилась картинка и текст уехал вниз, когда баннер вытолкнул кнопку. Чем стабильнее раскладка, тем ниже (лучше) CLS.
- INP (Interaction to Next Paint) — «как быстро страница отвечает на действия». Измеряет задержку между действием посетителя (клик, тап, ввод) и видимой реакцией страницы на протяжении всего визита. Чем отзывчивее интерфейс, тем ниже INP.
Пороги зелёной зоны и как их читать
У каждой метрики есть три зоны: «хорошо» (зелёная), «требует улучшения» (жёлтая) и «плохо» (красная). Ориентиры зелёной зоны такие:
| Метрика | Хорошо | Требует улучшения | Плохо |
|---|---|---|---|
| LCP | до 2,5 с | 2,5–4 с | более 4 с |
| CLS | до 0,1 | 0,1–0,25 | более 0,25 |
| INP | до 200 мс | 200–500 мс | более 500 мс |
Тонкость, которую часто упускают: пороги считаются по 75-му перцентилю, а не по среднему. Это значит, что «хорошо» должно быть у трёх четвертей реальных посетителей, включая тех, кто заходит с медленного мобильного интернета и недорогого телефона. Поэтому ориентироваться на «у меня на рабочем ноутбуке всё летает» нельзя — метрика смотрит на массу пользователей, а не на лучший случай.
Где метрики проседают в магазине на Битриксе
В интернет-магазине на 1С-Битрикс у каждой метрики свои типичные «слабые места». Знание этих мест экономит время: вы сразу смотрите туда, где проблема вероятнее всего.
| Метрика | Типичная причина в магазине | Чем лечится |
|---|---|---|
| LCP | Медленная сборка страницы на сервере, тяжёлое главное фото | Композит, кэш, оптимизация изображений |
| LCP | Блокирующие отрисовку скрипты и шрифты | Отложенная загрузка, корректная подача шрифтов |
| CLS | Картинки и баннеры без заданных размеров | Явные width/height, резерв места |
| CLS | Поздняя подгрузка корзины и уведомлений | Зарезервированное место под динамику |
| INP | Тяжёлый JavaScript, много обработчиков | Разбивка задач, удаление лишних скриптов |
Закономерность видна сразу: LCP — это в первую очередь про бэкенд и картинки, CLS — про вёрстку и резерв места, INP — про фронтенд и скрипты. Это разные источники, и лечат их разными средствами. Дальше разберём каждую метрику по отдельности.
Как улучшить LCP
LCP — обычно самая «дорогая» метрика для магазина, потому что упирается сразу в две вещи: как быстро сервер отдаёт страницу и как быстро грузится главный визуальный элемент. Работают по обоим направлениям.
Ускоряем отдачу страницы сервером
Чем дольше сервер собирает HTML, тем позже браузер вообще начинает рисовать. Здесь работают кэширование и композит: статическая часть с основным контентом отдаётся мгновенно, ещё до запуска тяжёлого ядра. Это самый сильный рычаг по LCP в Битриксе — мы посвятили ему отдельный материал про композитный сайт, потому что именно он чаще всего вытягивает LCP из жёлтой зоны.
Облегчаем главное изображение
Часто крупнейший элемент экрана — это большой баннер или фото товара. Если оно весит мегабайты и в старом формате, LCP проседает даже на быстром сервере. Что делать:
- Современные форматы. Отдавайте картинки в экономных форматах (например, WebP) вместо тяжёлых исходников.
- Правильный размер. Не грузите изображение 4000 пикселей туда, где экран показывает 800 — масштабируйте под реальный размер.
- Приоритет главному. Изображение первого экрана грузите в приоритете, а не откладывайте — оно и есть LCP-элемент.
- Ленивая загрузка остального. Картинки ниже первого экрана грузите лениво, чтобы они не конкурировали за канал с главным.
Как убрать сдвиги вёрстки (CLS)
CLS — самая «обидная» метрика: страница вроде быстрая, но всё прыгает, и посетитель промахивается по кнопке или случайно нажимает не туда. Хорошая новость — CLS чаще всего лечится дёшево и быстро, потому что его причины типовые.
- Размеры у картинок и медиа. Указывайте ширину и высоту (или соотношение сторон) у изображений, видео, iframe — тогда браузер резервирует место заранее, и контент не «уезжает» при подгрузке.
- Резерв под динамику. Корзина в шапке, плашки уведомлений, баннеры — всё, что подгружается позже, должно иметь заранее отведённое место, чтобы не выталкивать соседние блоки.
- Аккуратная подача шрифтов. Подмена шрифта не должна резко менять размеры текста — иначе блок «перескакивает». Шрифты грузят так, чтобы текст не прыгал.
- Никаких вставок над контентом. Баннеры и сообщения, которые внезапно появляются над уже прочитанным контентом и сдвигают его вниз, — прямой источник CLS.
В магазине на Битриксе особое внимание — карточке товара и списку каталога: именно там много изображений, и именно там цена сдвига высока, потому что рядом кнопка «купить». Зарезервируйте место под фото и под динамическую цену — и CLS обычно сразу уходит в зелёную зону.
Как улучшить отзывчивость (INP)
INP отвечает за ощущение «живости» интерфейса: нажал — и сразу видишь реакцию. Главный враг здесь — тяжёлый JavaScript, который надолго занимает основной поток браузера, и пока он работает, страница не успевает откликнуться на клик.
Что обычно помогает по INP в магазине:
- Меньше лишних скриптов. Аудит подключённого JavaScript: счётчики, виджеты, чаты, баннерные системы складываются в тяжёлый «хвост», который тормозит отклик. Лишнее — убрать или отложить.
- Отложенная и асинхронная загрузка. Несрочные скрипты грузите так, чтобы они не блокировали взаимодействие на первом экране.
- Разбивка длинных задач. Тяжёлую логику дробят на части, чтобы между ними браузер успевал реагировать на действия пользователя.
- Аккуратные обработчики. Не навешивайте тяжёлые вычисления на каждое движение или ввод; используйте экономные приёмы вроде «отложить, пока пользователь не закончил».
INP — это почти всегда фронтенд, а не сервер. Поэтому композит и кэш, которые отлично лечат LCP, на INP влияют лишь косвенно: они разгружают сервер в пики, но тяжёлый клиентский JavaScript никуда не девают. Это важно понимать, чтобы не лечить INP «не тем лекарством».
Композит и кэш как фундамент скорости
Если из всех инструментов выбрать один с максимальным эффектом на серверную скорость магазина на Битриксе — это связка кэширования и композитного сайта. Они закладывают фундамент, на котором остальные оптимизации работают в полную силу.
Логика простая: пока сервер долго собирает каждую страницу, никакая оптимизация картинок не спасёт — браузер просто поздно получает HTML. Композит отдаёт статическую часть с основным контентом мгновенно из кэша, а персональные блоки (корзина, цены) догружает отдельно. Это резко улучшает LCP и снимает просадку в часы пик.
Мы подробно разобрали механику в материале про композитный сайт в 1С-Битрикс: как делить статику и динамику, как не сломать корзину и как прогревать кэш после обмена с 1С. А связь скорости каталога с умным фильтром — в статье про умный фильтр и фасетный индекс: быстрый фильтр и тёплый кэш напрямую помогают LCP страниц каталога. Эти три темы — композит, кэш и фасет — работают в одной связке.
Картинки, шрифты и скрипты
Три «расходных» ресурса страницы — изображения, шрифты и скрипты — влияют сразу на несколько метрик. Сведём рекомендации в одну таблицу, чтобы видеть, что на что действует.
| Ресурс | Что делать | На какие метрики влияет |
|---|---|---|
| Изображения | Современные форматы, правильный размер, lazy-load ниже первого экрана | LCP, частично CLS |
| Изображения | Явные width/height для резерва места | CLS |
| Шрифты | Подача без скачка текста, ограниченный набор начертаний | LCP, CLS |
| Скрипты | Убрать лишнее, отложить несрочное, разбить тяжёлые задачи | INP, частично LCP |
| Скрипты | Асинхронная загрузка сторонних виджетов | INP |
Отдельно про сторонние виджеты — чаты, аналитику, баннерные системы. Каждый из них тянет свой JavaScript и нередко портит INP и LCP. Это не значит «выкинуть всё», но стоит периодически проводить ревизию: что из подключённого реально нужно, а что висит «по привычке» и только замедляет сайт. На работающем магазине такая ревизия — часть регулярной технической поддержки, потому что скрипты имеют свойство накапливаться со временем.
Как измерять: лаборатория и поле
Чтобы управлять метриками, их нужно правильно мерить, и здесь важно не путать два типа данных.
- Лабораторные (синтетические) данные. Это тест в контролируемых условиях: один прогон, заданная сеть и устройство. Удобны для диагностики — стабильны, повторяемы, показывают, что именно тормозит. Но это «лаборатория», а не реальные посетители.
- Полевые данные (реальные пользователи). Это метрики, собранные по живым визитам на разных устройствах и сетях. Именно по ним считается итоговая оценка Core Web Vitals, потому что они отражают реальный опыт.
Практичный подход: диагностируйте лабораторно, контролируйте по полю. Лабораторный аудит подскажет конкретные причины («тяжёлый скрипт», «большая картинка», «нет кэша»), а полевые данные покажут, дошёл ли результат до реальных людей. Ориентироваться только на синтетику опасно — она может показывать зелёное там, где живым пользователям с медленным интернетом плохо.
Core Web Vitals, SEO и конверсия
Вокруг Core Web Vitals много мифов — от «это не влияет на поиск» до «это волшебная кнопка в топ». Истина посередине, и её полезно проговорить честно.
Для SEO. Core Web Vitals — это сигнал удобства страницы, который участвует в ранжировании. Он не перевесит релевантность и качество контента, но при прочих равных быстрая и стабильная страница выигрывает. Особенно это заметно в конкурентных нишах, где сайты близки по содержанию, и «техническое здоровье» становится решающим различием.
Для конверсии. Здесь связь ещё прямее и не зависит от поисковика. Медленная страница повышает отказы — люди уходят с белого экрана. «Прыгающая» вёрстка ведёт к ошибочным кликам и раздражению. Тормозящий интерфейс отбивает желание оформлять заказ. Поэтому работа над метриками окупается даже там, где трафик не из поиска: быстрый и стабильный магазин просто лучше продаёт. Скорость — лишь одна сторона конверсии; не меньше дают удобная корзина и возврат ушедших покупателей, о чём мы пишем в материале про брошенную корзину в 1С-Битрикс.
Скорость особенно важна для большого каталога и высокой нагрузки — там, где счёт идёт на тысячи страниц и сотни одновременных посетителей. Если магазин крупный, метрики стоит закладывать в архитектуру с самого начала: посмотрите смежные услуги в каталоге всех услуг B2Bsite или сразу ускорение сайта на 1С-Битрикс.
Частые ошибки при работе с метриками
Типичные грабли, на которые наступают при работе с Core Web Vitals:
- Лечат INP композитом. Композит ускоряет сервер и LCP, но INP — это фронтенд и JavaScript. Лечить отзывчивость серверным кэшем бесполезно.
- Отложили главное фото lazy-load. Ленивая загрузка LCP-элемента первого экрана только ухудшает LCP. Lazy-load — для того, что ниже видимой области.
- Не задали размеры картинкам. Без width/height вёрстка прыгает при подгрузке — это прямой источник CLS, который чинится за минуты.
- Меряют только на мощном устройстве. «У меня всё быстро» на рабочем ноутбуке ничего не говорит о 75-м перцентиле живых пользователей с мобильного.
- Гонятся за синтетическими баллами. Оптимизируют ради цифры в лабораторном тесте, а не ради опыта реальных посетителей по полевым данным.
- Копят сторонние скрипты. Чаты, счётчики и виджеты накапливаются и тихо роняют INP. Нужна периодическая ревизия.
- Чинят детали при нерешённой базе. Тонко настраивают шрифты, пока на сайте нет композита и кэша — сначала фундамент, потом отделка.
Чек-лист по Core Web Vitals
Короткий список, по которому удобно довести метрики магазина до зелёной зоны:
- Включены кэширование компонентов и композитный сайт — статика отдаётся мгновенно (LCP).
- Главное изображение первого экрана оптимизировано, в современном формате и в приоритете загрузки (LCP).
- Картинки ниже первого экрана грузятся лениво (LCP, трафик).
- У всех изображений и медиа заданы размеры или соотношение сторон (CLS).
- Под корзину, уведомления и баннеры зарезервировано место (CLS).
- Шрифты подаются без скачка текста, набор начертаний ограничен (CLS, LCP).
- Проведена ревизия скриптов: лишнее убрано, несрочное отложено (INP).
- Тяжёлые задачи фронтенда разбиты, обработчики экономны (INP).
- Метрики диагностируются лабораторно и контролируются по полевым данным.
- Кэш и композит сбрасываются и прогреваются после обмена с 1С.
Вывод
Core Web Vitals — это не абстрактные баллы, а три измеримых стороны опыта: как быстро появился контент (LCP), не прыгала ли вёрстка (CLS) и отзывчив ли интерфейс (INP). В магазине на 1С-Битрикс у каждой метрики свои типичные причины просадки и свои инструменты лечения, и путать их не стоит: LCP — это сервер и картинки, CLS — вёрстка и резерв места, INP — фронтенд и скрипты.
Действуйте по порядку: сначала фундамент — кэш и композит для LCP, затем оптимизация картинок и шрифтов и резерв места против CLS, и наконец разгрузка JavaScript ради INP. Диагностируйте лабораторно, контролируйте по живым пользователям — и зелёная зона перестанет быть недостижимой даже на большом каталоге.
