Скорость загрузки B2B-сайта: как замерить Core Web Vitals

Коротко о главном

• Core Web Vitals - это три метрики Google: LCP (как быстро появляется главный элемент страницы), INP (как быстро страница отвечает на нажатие) и CLS (прыгает ли вёрстка при загрузке). Хорошими считаются LCP до 2,5 секунды, INP до 200 миллисекунд и CLS не выше 0,1.
• Оценка строится по реальным визитам и считается по 75-му процентилю: порог должны выдерживать три визита из четырёх, а не среднее значение.
• Смотреть нужно на полевые данные (реальные посетители за последние 28 дней). Лабораторный тест в PageSpeed Insights нужен, чтобы найти причину, а не чтобы поставить оценку.
• У B2B-сайта трафика обычно немного, поэтому по отдельной странице данных может не быть. Тогда опираются на данные по сайту в целом, Яндекс Метрику и ручную проверку на телефоне.
• Начинайте со страниц, которые приводят заявки: первый экран, сторонние скрипты, форма. Гнаться за 100 баллами в тесте не нужно.
• Результат правок в полевых данных появляется не сразу, до 28 дней. Зелёные метрики не гарантируют позиций в поиске, но убирают лишние задержки между посетителем и формой.

Где на самом деле теряется заявка

Представьте закупщика оборудования. Он открывает с телефона три сайта поставщиков и быстро сравнивает, у кого есть нужные допуски и какие сроки поставки. На вашей странице экран пару секунд остаётся пустым, потом заголовок уезжает вниз, потому что подгрузилась фотография цеха. Он нажимает «Запросить расчёт», и ничего не происходит, потому что страница занята загрузкой скриптов. Человек возвращается в выдачу и открывает следующий сайт. В отчёте это выглядит как обычный отказ, а в CRM заявки просто нет.

Скорость сайта часто воспринимают как претензию SEO-специалиста или оценку от Google. На деле это вопрос, доходит ли посетитель до формы. Чаще всего причины одни и те же: тяжёлые фотографии и видео в первом экране, десяток счётчиков и виджетов, подключённых разными подрядчиками в разное время, шаблон на конструкторе с избыточными скриптами. Трафика у B2B-сайта немного, поэтому проблему месяцами никто не замечает: общие цифры по сайту выглядят нормально, а на странице с формой посетитель ждёт.

Ниже разберём, как замерить скорость так, чтобы цифрам можно было верить, на какие страницы смотреть в первую очередь и какие правки действительно сокращают задержки.

Три метрики простыми словами

Раньше скорость часто сводили к одной цифре: «сайт грузится 3 секунды». Сейчас Google смотрит на три разных ощущения посетителя. LCP показывает, когда на экране появился самый крупный элемент: обычно это главная картинка или большой заголовок. INP измеряет, как быстро страница реагирует на клики, нажатия и ввод. Из всех взаимодействий за визит берётся самое долгое, без случайных выбросов. CLS складывает неожиданные сдвиги вёрстки: кнопка уехала в момент нажатия, текст сполз вниз.

Метрика INP заменила старую FID в марте 2024 года, так что старые материалы про «задержку первого ввода» уже не актуальны. Пороги, которые публикует Google на web.dev, сведены в таблицу.

Страница считается прошедшей проверку, только если все три метрики попадают в «хорошо» на 75-м процентиле. Если у четверти посетителей загрузка медленнее порога, оценка не будет зелёной, даже когда у остальных всё в порядке. Для B2B это правдоподобная картина: ваша аудитория открывает сайт и с мощного ноутбука в офисе, и со смартфона на промплощадке с плохой связью. Мобильные и десктопные данные Google оценивает отдельно.

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

Где смотреть: инструменты и что каждый показывает

Одного инструмента недостаточно. Каждый отвечает на свой вопрос, поэтому лучше сразу понимать, чем они различаются.

PageSpeed Insights: начинать с верхнего блока

Отчёт состоит из двух частей, и их часто путают. Верхний блок с реальными посетителями берётся из отчёта Chrome User Experience Report (CrUX) за скользящие 28 дней. Нижний блок с диагностикой - это Lighthouse: один тестовый прогон на эмулированном устройстве при заданных условиях сети. Разумный порядок такой: сначала посмотреть, прошла ли страница оценку по реальным данным, и только потом открывать диагностику, чтобы понять причину.

Есть и свежая оговорка. В начале ноября 2026 года вышло обновление Lighthouse, которое изменило симуляцию загрузки, и лабораторные оценки у части сайтов выросли без единой правки на самом сайте. Поэтому, если подрядчик показывает резкий рост балла, стоит спросить, что изменилось: сайт или инструмент. Полевые данные от этого обновления не меняются.

Search Console: какие группы страниц страдают

Отчёт Core Web Vitals в Search Console тоже построен на данных CrUX, то есть на реальных сеансах посетителей. Страницы в нём сгруппированы по статусам «Низкая скорость», «Нужно увеличить скорость» и «Хорошо», а также по метрикам и группам URL. Это удобно для сайта с шаблонами: часто выясняется, что проблема не в десяти страницах, а в одном шаблоне карточки продукта, который лежит под всеми ними.

Яндекс: Вебмастер и Метрика

Для Яндекса нужно сказать честно: прямого аналога Core Web Vitals там нет, свои пороги он не публикует и связь скорости с позициями не комментирует. Ориентиры тут другие: раздел про скорость в Вебмастере и отчёт «Время загрузки страниц» в Метрике, где данные разбиты по квантилям. Работа над метриками Google помогает и в Яндексе, потому что медленная страница одинаково неприятна для любого посетителя, но переносить зелёную оценку из одного поиска в другой нельзя.

Chrome DevTools: когда надо найти виновника

Если отчёт говорит «LCP 4 секунды», а почему - непонятно, открывают DevTools. Вкладка Performance показывает, какой именно элемент стал LCP, какие скрипты занимали главный поток и где возникли длинные задачи. Эта работа для разработчика, но заказчику полезно знать, что такой инструмент есть и что ответ «не воспроизводится» можно проверить.

Почему цифры не совпадают и каким верить

Типичная сцена: в PageSpeed Insights у страницы 92 балла, а в Search Console она в жёлтой зоне. Противоречия тут нет. Лабораторный тест - один прогон на условном устройстве. Полевые данные - это реальные люди за четыре недели, с разными телефонами, сетями и браузерами. Google ориентируется на полевые данные, а Lighthouse-балл в оценку Core Web Vitals не входит.

Из этого следуют три практических вывода. Во-первых, не называйте целью «100 баллов»: последние баллы стоят дорого и ничего не меняют для посетителя. Цель формулируется иначе: три метрики укладываются в пороги на реальных данных. Во-вторых, лабораторные прогоны хороши для быстрой проверки правки: изменили, перепроверили через минуту. В-третьих, полевые данные запаздывают. Если вы исправили проблему сегодня, в отчёте будет смесь старых и новых визитов, и полностью картина обновится примерно через 28 дней.

Что делать, если по вашей странице данных нет

Для небольшого B2B-сайта это обычная ситуация. CrUX учитывает только пользователей Chrome и требует достаточного числа визитов. Если по конкретному адресу данных мало, PageSpeed Insights переключается на данные по сайту целиком. Если и их мало, остаётся только лабораторный результат без итоговой оценки.

В этом случае работают такие приёмы:

• Смотрите отчёт «Время загрузки страниц» в Яндекс Метрике: он строится на вашем собственном трафике, в том числе из Яндекса.
• Проверяйте страницы руками: откройте сайт с реального телефона, на мобильном интернете, в режиме инкогнито. Нажмите на кнопку формы и посчитайте, сколько вы ждёте.
• Оценивайте группы страниц, а не отдельные адреса. Если все карточки услуг сделаны на одном шаблоне, достаточно проверить два-три примера.
• Если разработчик подключает мониторинг реальных посетителей, это даст данные быстрее, чем накопится CrUX. Но эта задача нужна не каждому сайту, а скорее тем, у кого есть сложный каталог или конфигуратор.

С каких страниц начинать

Проверять все страницы подряд бессмысленно. Начните с тех, которые приводят заявки или стоят на пути к ним. Для типичного сайта производителя или IT-компании это главная, страницы услуг или продуктов, страница с контактами и формой, а также несколько самых посещаемых статей блога. Найти их можно в Метрике по числу визитов и по целям.

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

Что исправлять: от первого экрана к форме

LCP: ускорить появление главного элемента

Время LCP складывается из четырёх частей: ответ сервера, задержка перед началом загрузки главного элемента, сама загрузка и отрисовка. Чаще всего проблема не в тяжести картинки, а в том, что браузер узнаёт о ней поздно.

• Главная картинка должна быть видна в HTML. Если баннер подключён как фон через CSS или подставляется скриптом, браузер находит его с задержкой. Лучше использовать обычный тег изображения и дать ему высокий приоритет через атрибут fetchpriority.
• Не откладывайте загрузку первого экрана. Ленивая загрузка (lazy loading) полезна для картинок ниже первого экрана, но если её включили на главной картинке, браузер ждёт лишнее время. Это частая ошибка шаблонов и плагинов.
• Сожмите изображения и используйте современные форматы. WebP и AVIF обычно заметно легче JPEG при том же визуальном качестве, а адаптивные размеры не заставляют телефон скачивать картинку для широкого монитора.
• Проверьте ответ сервера. Если HTML отдаётся медленно, остальное ускорять трудно. Помогают кэширование страниц и CDN, а также разбор тяжёлых запросов к базе данных на каждый визит.

INP: освободить страницу для реакции на клик

Страница не реагирует на нажатие, когда браузер занят выполнением скриптов. Длинной считается задача дольше 50 миллисекунд. Источники таких задач на B2B-сайтах знакомы: чат-виджеты, системы аналитики и тепловых карт, окна согласия на cookie, скрипты рекламных пикселей, тяжёлая библиотека для слайдера, которую подключили ради одного блока.

Практичный порядок действий такой. Составьте список всех сторонних скриптов и для каждого определите, кто им владеет и какую пользу он приносит. Лишнее уберите: счётчик, который никто не смотрит, лучше удалить, чем оптимизировать. Нужное загружайте позже, после первой отрисовки, или по действию пользователя. Для собственного кода разработчик может разбить длинные операции на короткие части, чтобы браузер успевал реагировать на клики. Chrome DevTools помогает найти неиспользуемый код, который тоже можно убрать.

CLS: убрать прыжки вёрстки

Сдвиги вёрстки возникают, когда страница не знает заранее, сколько места занять. Основные причины и решения такие:

• У изображений и видео не указаны ширина и высота. Их нужно задать в атрибутах или зарезервировать место через CSS-свойство aspect-ratio.
• Поздно появляются баннеры, формы, встроенные карты и видео. Для них резервируют блок с минимальной высотой. Убирать зарезервированное место потом тоже нельзя: сжатие вызывает такой же сдвиг, как и появление.
• Шрифты подменяются после загрузки. Подбирайте запасной шрифт близким по размерам и настройте font-display, чтобы текст не перестраивался на глазах.
• Баннер cookie или чат всплывают сверху и сдвигают контент. Их стоит показывать поверх страницы, а не вставлять в поток.

Таблица: симптом, вероятная причина, задача разработчику

Ловушки, в которые попадают чаще всего

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

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

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

Ждать результата назавтра. Полевые данные накапливаются за 28 дней, поэтому через неделю после правок отчёт ещё покажет смесь старой и новой картины. Не стоит по ошибке откатывать удачные изменения только потому, что оценка не позеленела сразу.

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

Убирать аналитику вслепую. Если удалить счётчик, чтобы улучшить INP, и не предупредить маркетинг, можно потерять данные об источниках заявок. Список скриптов нужно согласовывать с теми, кто ими пользуется.

Как поставить задачу и принять результат

Чёткая формулировка экономит и время, и бюджет. Вместо «ускорьте сайт» лучше написать так: «Для страниц услуг и страницы контактов LCP на мобильных до 2,5 секунды, INP до 200 мс, CLS до 0,1 по данным Search Console, форма заявки реагирует без заметной задержки». К задаче стоит приложить список страниц, перечень сторонних скриптов с владельцами и исходные замеры: скриншоты полевых данных и результат лабораторного прогона до начала работ.

Приёмка проходит в два шага. Сразу после выкладки: повторный лабораторный прогон, ручная проверка на телефоне, тестовая заявка с проверкой, что она дошла в CRM и что цели в Метрике сработали. Через 4-5 недель: сверка полевых данных с исходными. Если зелёной зоны всё ещё нет, у разработчика уже есть данные, где искать остаточные проблемы.

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

1. Откройте PageSpeed Insights для пяти страниц, которые приводят заявки, и запишите полевые значения LCP, INP и CLS отдельно для телефона и компьютера. Если полевого блока нет, отметьте это.
2. Посмотрите отчёт Core Web Vitals в Search Console и «Время загрузки страниц» в Яндекс Метрике. Найдите шаблоны, которые в красной или жёлтой зоне.
3. Откройте сайт с реального телефона на мобильном интернете и пройдите путь до формы. Засеките, где вы ждали.
4. Составьте список всех сторонних скриптов: чаты, счётчики, пиксели, окна согласия. Для каждого определите владельца и цель, лишнее отметьте на удаление.
5. Поставьте задачу разработчику с конкретными порогами, списком страниц и исходными замерами, а в календаре отметьте повторную проверку через 4-5 недель.
6. После правок проверьте, что заявки доходят в CRM, а цели в Метрике считаются.

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

Читайте также