Аудит Core Web Vitals и PageSpeed для сайта на 1С-Битрикс

Аудит Core Web Vitals и PageSpeed — это глубокая диагностика скорости и стабильности сайта на 1С-Битрикс, по итогам которой вы получаете не абстрактный балл, а конкретный список причин и приоритизированный план правок. Мы раскладываем общую оценку PageSpeed Insights на отдельные метрики: LCP, отвечающую за время отрисовки главного блока, INP, измеряющую отклик страницы на действия пользователя, и CLS, показывающую визуальную стабильность вёрстки. К ним добавляем FCP и TTFB как фундамент, без которого остальные метрики не выйдут в зелёную зону. Такой разбор превращает непонятный красный балл в управляемый набор задач.

Ключевая идея аудита в том, что одного лабораторного замера недостаточно. PageSpeed Insights показывает два типа данных: лабораторные, снятые через Lighthouse в идеальных условиях, и полевые, собранные с реальных пользователей через CrUX. Именно полевые данные учитывает поиск и показывает Search Console, поэтому зелёная лаборатория при красном поле — частая и обманчивая ситуация. Мы всегда сверяем оба источника, а при необходимости подключаем RUM-мониторинг, чтобы увидеть, как сайт ведёт себя у конкретных сегментов аудитории на их устройствах и сетях.

Какие метрики мы измеряем

Core Web Vitals — это три ключевые метрики, но для полной картины их недостаточно. LCP показывает, за сколько отрисовывается самый крупный видимый элемент, обычно главное изображение или заголовок; зелёная зона — до 2,5 секунды. INP измеряет задержку между действием пользователя и реакцией страницы; хорошее значение — меньше 200 миллисекунд. CLS отражает суммарный сдвиг вёрстки при загрузке; зелёная зона — ниже 0,1. Дополнительно мы смотрим FCP, первую отрисовку контента, и TTFB, время до первого байта от сервера, потому что именно они определяют, насколько быстро всё начинается.

Основные показатели, которые мы снимаем и разбираем:

• LCP — время отрисовки главного блока и причины его задержки;
• INP — отклик на клики и тапы, длинные задачи в основном потоке;
• CLS — сдвиги вёрстки от изображений, шрифтов и поздних блоков;
• FCP — первая отрисовка контента на экране;
• TTFB — время ответа сервера и эффективность кэша Битрикса;
• сопутствующие сигналы: вес страницы, число запросов, блокирующие ресурсы.

Где сайты на Битриксе теряют скорость

Чаще всего метрики проседают по предсказуемым причинам. LCP уходит за допустимые секунды из-за тяжёлого главного изображения в старом формате без preload и адаптивных источников. CLS растёт, когда у картинок и баннеров не заданы размеры, поздно подгружаются блоки или шрифты меняют начертание при загрузке. INP страдает от тяжёлого и блокирующего JavaScript: обработчиков фильтров, сторонних виджетов и аналитики, которые надолго занимают основной поток. А TTFB тянет всё вниз, когда отключён или неправильно настроен кэш Битрикса, перегружена база или слабый хостинг. Мы находим каждую из этих причин по водопаду загрузки и профилировке.

Отдельное внимание — фронтенду шаблона. На многих проектах в страницу подключены десятки CSS и JS файлов, часть из которых не используется или дублируется. Браузер вынужден ждать загрузки блокирующих стилей перед первой отрисовкой и выполнять лишний код. Мы выделяем критический CSS, нужный для видимой части экрана, откладываем некритичные стили и скрипты, настраиваем lazy-load для ресурсов ниже первого экрана и preload для самого важного. Это прямой путь к улучшению FCP, LCP и INP без переписывания сайта.

Зачем это бизнесу, а не только SEO

Зелёные Core Web Vitals дают двойную выгоду. С одной стороны, это фактор ранжирования: при прочих равных более быстрый сайт получает преимущество в поиске, и улучшение полевых метрик нередко сопровождается ростом позиций по конкурентным запросам. С другой стороны, скорость напрямую влияет на конверсию и отказы. Каждая лишняя секунда ожидания и каждый прыжок вёрстки уводят часть посетителей, особенно на мобильных с небыстрым интернетом. Поэтому аудит окупается не только трафиком из поиска, но и заказами, которые перестают теряться на медленной загрузке. По итогу вы получаете дорожную карту, по которой сайт становится быстрее для людей и заметнее для поиска одновременно.

Чем аудит отличается от прогона PageSpeed

Запустить PageSpeed Insights и получить балл может кто угодно за минуту. Разница в том, что аудит не заканчивается баллом, а начинается с него. Мы снимаем метрики не для одной страницы, а по всем ключевым шаблонам сайта, потому что главная, каталог, карточка товара и корзина ведут себя по-разному и тормозят по разным причинам. Затем разбираем водопад загрузки каждого шаблона: в каком порядке грузятся ресурсы, что блокирует отрисовку, какой именно элемент становится LCP и почему он задерживается. Профилируем основной поток, чтобы поймать длинные задачи, которые портят INP, и отслеживаем каждый источник сдвига вёрстки для CLS. Только после этого формулируем правки.

Такой подход экономит бюджет: вместо того чтобы вслепую применять десяток модных оптимизаций, вы получаете точный список из нескольких действий, которые реально сдвинут метрики именно вашего сайта. Мы оцениваем каждое из них по эффекту и трудозатратам, чтобы вы начали с быстрых побед и видели результат уже на первой неделе работ, а не через месяцы экспериментов.

Когда сайт на 1С-Битрикс показывает красные баллы в PageSpeed Insights, первый соблазн — поставить модуль-ускоритель, нажать кнопку «оптимизировать всё» и надеяться, что метрики позеленеют сами. Иногда балл действительно немного подрастает за счёт минификации и общего сжатия. Но в большинстве случаев такой подход лечит симптом, а не причину: универсальные настройки не знают, какой именно элемент у вас является LCP, какой скрипт блокирует отклик и откуда берётся сдвиг вёрстки. В результате полевые данные в CrUX остаются красными, Search Console продолжает помечать URL как требующие улучшения, а владелец сайта недоумевает, почему лабораторный тест зелёный, а поиск так не считает. Ниже разбираем, почему аудит работает иначе и что он даёт.

Почему один балл PageSpeed ничего не объясняет

Балл PageSpeed — это свёртка нескольких метрик в одно число. Сайт может иметь приличный балл и при этом проваливать конкретную метрику, важную именно для вашей аудитории. Например, на десктопе всё зелёное, а на мобильных LCP уходит за четыре секунды, потому что главный баннер грузится в тяжёлом формате без адаптивных источников. Или общий балл неплохой, но INP высокий из-за тяжёлого фильтра каталога, и пользователи чувствуют, что сайт залипает при кликах. Пока балл не разложен на LCP, INP, CLS, FCP и TTFB, вы чините наугад. Аудит начинается именно с разложения: мы показываем, какая метрика проседает, на каких типах страниц и почему, и только потом переходим к правкам.

Эта детализация особенно важна для интернет-магазинов и B2B-порталов, где разные типы страниц ведут себя по-разному. Главная, карточка товара, каталог с фильтром и корзина имеют разный набор тяжёлых элементов и скриптов. Оптимизировать их одним рецептом нельзя. Если вы планируете развивать коммерческую часть сайта, имеет смысл связать ускорение производительности с аудитом интернет-магазина на Битрикс, чтобы увидеть и техническую скорость, и узкие места конверсии в одной картине.

Лаборатория против реальных пользователей

Главная ошибка самостоятельной оптимизации — ориентироваться только на лабораторный балл. Lighthouse запускается на быстром виртуальном устройстве с заданной сетью и показывает идеализированную картину. Реальные пользователи приходят с разных телефонов, через мобильный интернет разного качества, с включёнными расширениями и фоновыми вкладками. Поэтому поле почти всегда хуже лаборатории, и именно поле учитывает поиск. Мы строим аудит вокруг полевых данных CrUX, а где нужна детализация по сегментам — подключаем RUM-мониторинг, который собирает метрики прямо в браузерах ваших посетителей. Это позволяет приоритизировать работы по тому, что реально ощущают люди, а не по красивому числу в синтетическом тесте.

Разрыв между лабораторией и полем часто указывает на проблемы, которые универсальные ускорители не видят в принципе: медленный отклик на действия на слабых устройствах, сдвиги вёрстки от рекламных блоков и виджетов, задержки от сторонних скриптов аналитики и чатов. Эти вещи не лечатся кнопкой, их нужно находить через профилировку и понимание поведения конкретного сайта.

Почему важен фундамент: сервер и кэш Битрикса

Сколько ни оптимизируй фронтенд, если сервер отдаёт первый байт за секунду и больше, метрики не вытянуть. TTFB — это фундамент, и на Битриксе он чаще всего проседает из-за неверно настроенного кэша, отключённого композитного режима, тяжёлых компонентов без кэширования или перегруженной базы. Мы разбираем, какие части страницы можно закэшировать, корректно настраиваем композит так, чтобы динамические блоки вроде корзины и персональных данных подгружались отдельно, и при необходимости подключаем CDN для статики. Если узкое место в хостинге, мы прямо об этом говорим: иногда переезд на более быстрое окружение даёт больше, чем десяток фронтенд-правок. Этот серверный пласт логично смотреть вместе с более широким аудитом производительности сайта, который охватывает не только метрики страницы, но и инфраструктуру целиком.

Как мы приоритизируем правки

Главная ценность аудита — не длинный список рекомендаций, а порядок их выполнения. Мы оцениваем каждую правку по двум осям: насколько она улучшит метрику и сколько усилий потребует. Сначала идут быстрые победы с большим эффектом — перевод LCP-изображения в современный формат с preload, резервирование места под баннеры для устранения CLS, отсрочка пары тяжёлых сторонних скриптов. Затем — более трудоёмкие работы вроде выделения критического CSS, переработки загрузки шрифтов и оптимизации обработчиков каталога. Такой план позволяет получить заметный результат уже на первой неделе и двигаться дальше осознанно, а не распылять бюджет на правки, которые почти не влияют на полевые метрики.

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

Что вы получаете на выходе

Результат аудита — это структурированный отчёт, в котором по каждому типу страниц показаны метрики, причины красных значений и конкретные действия с оценкой эффекта. К нему прилагается дорожная карта: что делать в первую очередь ради быстрого роста полевых метрик и позиций, а что — на следующих итерациях. Отчёт написан так, чтобы по нему могла действовать и ваша команда, и любой подрядчик, и мы сами в формате внедрения. Никакой привязки и чёрных ящиков: вы понимаете, почему сайт был медленным и что именно сделает его быстрым.

Внедрение и контроль результата

Аудит можно заказать как отдельный продукт или вместе с внедрением. В формате с внедрением мы выполняем оптимизацию изображений и шрифтов, выделяем критический CSS, откладываем и разбиваем тяжёлый JS, настраиваем lazy-load и preload, при необходимости — серверный кэш и CDN. После каждого блока работ перезамеряем метрики и сверяем их с полевыми данными, чтобы видеть реальное движение, а не только изменение лабораторного балла. Важная деталь: мы не применяем lazy-load к LCP-элементу первого экрана и не откладываем критичные ресурсы вслепую, потому что неаккуратная оптимизация способна ухудшить метрики. Опыт работы с ядром и компонентами Битрикса как раз и нужен, чтобы ускорять сайт без риска сломать вёрстку, кэш или бизнес-логику.

Типичные возражения, которые мы слышим

«У нас уже стоит модуль ускорения, разве этого мало». Модуль делает общую часть работы — минификацию, сжатие, объединение файлов. Но он не знает специфики вашего сайта и не работает с полевыми данными, поэтому конкретные метрики вроде INP и CLS он почти не двигает. Аудит дополняет модуль точечной работой по причинам. «Мы боимся, что оптимизация сломает сайт». Мы тестируем правки на копии, проверяем ключевые сценарии после каждого изменения и не трогаем ядро напрямую, поэтому риск минимален. «Нам нужен только балл повыше для отчёта руководству». Балл вырастет как следствие, но мы ориентируемся на полевые метрики и реальную скорость, потому что именно они приносят позиции и заказы, а не красивое число в синтетике.

Кому особенно нужен аудит

Аудит Core Web Vitals окупается быстрее всего там, где много мобильного трафика и где скорость прямо влияет на деньги: интернет-магазины, B2B-порталы с каталогами и фильтрами, лендинги с дорогим трафиком из рекламы, медиа и сервисы с высокой посещаемостью. Если в Search Console часть URL помечена как требующие улучшения или плохие, если конкуренты обходят вас в выдаче при схожем контенте, если на мобильных растут отказы — это прямые сигналы, что метрики тянут сайт вниз. Чем больше трафика и выше средний чек, тем дороже обходится каждая лишняя секунда загрузки и тем быстрее окупается приведение метрик в зелёную зону.

Как метрики связаны между собой

Метрики Core Web Vitals не живут изолированно — они влияют друг на друга, и это важно учитывать при оптимизации. Медленный TTFB задерживает старт загрузки, а значит, тянет за собой и FCP, и LCP: пока сервер не ответил, браузеру нечего отрисовывать. Тяжёлый JavaScript одновременно вредит и LCP, потому что блокирует основной поток во время загрузки, и INP, потому что длинные задачи мешают отвечать на клики. Поздняя подгрузка шрифтов способна испортить и LCP, если LCP-элемент содержит текст, и CLS, если начертание меняется уже после первой отрисовки. Поэтому мы не оптимизируем метрики поодиночке, а смотрим картину целиком: одна грамотная правка нередко улучшает сразу несколько показателей, а неаккуратная — чинит одно и ломает другое.

Хороший пример — работа с главным изображением. Если просто включить для него lazy-load заодно со всеми картинками, LCP резко ухудшится, потому что браузер отложит загрузку самого важного элемента. Правильное решение — наоборот, добавить ему preload и высокий приоритет, а lazy-load применять только к изображениям ниже первого экрана. Подобных нюансов в производительности много, и именно понимание этих связей отличает осмысленный аудит от механического прогона рекомендаций инструмента.

Как мы фиксируем и контролируем результат

Чтобы оптимизация не превратилась в гадание, мы фиксируем исходные метрики до начала работ и сравниваем с ними каждый этап. После внедрения правок снимаем замеры повторно — и лабораторные, и полевые, — потому что полевые данные CrUX обновляются с задержкой, и важно убедиться, что улучшение дошло до реальных пользователей, а не осталось красивым числом в синтетике. Для проектов с высокой посещаемостью подключаем RUM-мониторинг на постоянной основе, чтобы видеть динамику метрик в реальном времени и ловить регрессии, когда новый функционал или сторонний скрипт незаметно замедляют сайт. Производительность — это не разовая акция, а состояние, которое нужно поддерживать, и мы помогаем выстроить контроль так, чтобы метрики не сползали обратно в красную зону после очередного релиза.

Отдельно следим за тем, чтобы оптимизация не вступала в конфликт с маркетингом и аналитикой. Сторонние скрипты — счётчики, чаты, рекламные пиксели — частая причина просадки INP и CLS, но просто выкинуть их нельзя, они нужны бизнесу. Поэтому мы ищем компромисс: подключаем их с отложенной загрузкой, после взаимодействия пользователя или через менеджер тегов с правильными приоритетами, чтобы они выполняли свою задачу и при этом не мешали отклику страницы. Такой баланс между скоростью и бизнес-инструментами — часть нашей работы.

С чего начать

Начните с бесплатного экспресс-замера. Пришлите адрес сайта и ключевые страницы — мы снимем метрики по лабораторным и полевым данным, назовём главные причины красных значений и сориентируем по объёму и стоимости работ. Дальше вы решаете: взять полный аудит с дорожной картой, заказать аудит вместе с внедрением до зелёных метрик или получить только внедрение по уже готовому плану. В любом случае вы будете точно понимать, что и в каком порядке делать, чтобы сайт на Битриксе стал быстрым для людей и заметным для поиска. Обсудим ваш проект — и переведём метрики из красной зоны в зелёную.