Core Web Vitals: метрики, пороги и приоритеты оптимизации

Пороги Core Web Vitals, поиск узких мест и приоритеты оптимизации корпоративного сайта для B2B

Core Web Vitals: метрики, пороги и приоритеты оптимизации

Сначала вывод: Core Web Vitals — это оценка удобства страницы от Google. Пороговые значения трёх ключевых метрик: LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1 — по 75-му процентилю. 80% проблем с производительностью корпоративного сайта для B2B сосредоточены в трёх местах: большое изображение первого экрана не сжато, сторонние скрипты чата и CRM блокируют главный поток, у изображений нет соотношения сторон и это вызывает сдвиг макета. Порядок оптимизации: сначала LCP, потом INP, потом CLS; сначала изображения, затем скрипты и в последнюю очередь макет. Из данных доверяйте только 28-дневным полевым данным Search Console — не делайте выводов по лабораторным оценкам Lighthouse.

1. Что именно измеряют три метрики

Core Web Vitals — это не одна оценка, а сочетание трёх независимых метрик удобства. Понять, что измеряет каждая, — значит узнать, что нужно исправлять.

Показатель	Полное название	Что измеряет	Критерий	Требует улучшения
LCP	Largest Contentful Paint	Время до отрисовки самого крупного элемента первого экрана	≤ 2,5 с	от 2,5 до 4 с
INP	Interaction to Next Paint	Задержка от действия пользователя до отрисовки следующего кадра	≤ 200 мс	от 200 до 500 мс
CLS	Cumulative Layout Shift	Суммарная оценка непредвиденных сдвигов макета	≤ 0,1	от 0,1 до 0,25
TTVC	Производная от Time to First Contentful Paint	Время до отрисовки первого полезного контента	≤ 1,8 с	от 1,8 до 3 с

Два ключевых момента. Первый — 75-й процентиль: Google оценивает вашу страницу по показателям 75% реальных пользователей, а не по среднему значению и не по самым быстрым пользователям. Второй — в марте 2024 года INP официально заменил FID, и задержка взаимодействия стала ключевой метрикой. Это сильнее всего ударило по корпоративным сайтам для B2B, на которых установлены онлайн-чат, маркетинговая автоматизация и всплывающие окна чата: именно эти скрипты чаще всего блокируют главный поток.

Оптимизация производительности не существует отдельно — это две стороны одного процесса вместе с Управление медиаактивами: не разобрались с изображениями — LCP никогда не снизится; не разобрались со скриптами — INP никогда не пройдёт порог. Как выстроить систему мониторинга сайта, читайте в статье Чек-лист мониторинга и оповещений сайта.

2. Источники данных: что показывает каждый из трёх инструментов

Многие команды берут не те данные и после недели оптимизации не видят улучшений, потому что смотрят на лабораторные значения.

Инструмент	Тип данных	Выборка	Когда подходит	Ограничения
PageSpeed Insights	Лабораторные + полевые	Разовый прогон + 28 дней CrUX	Быстрая диагностика одной страницы	Лабораторные значения отличаются от реальных пользователей
CrUX	Полевые данные	Анонимные отчёты пользователей Chrome	Смотреть реальное распределение	Мало данных по сайтам с низким трафиком
Search Console	Сводка полевых данных	Скользящее окно 28 дней	Тренды по шаблонам	Нет разбивки по отдельным страницам
Lighthouse CI	Лабораторные данные	Локальный запуск тестов	Регрессия перед деплоем	Не отражает реальных пользователей на проде
Web Vitals .js	Своя полевая аналитика	Свои пользователи	Дополнить выборку для малых сайтов	Требует ресурсов разработки

Практическое правило: с помощью отчёта Core Web Vitals в Search Console найдите проблемный шаблон, через PageSpeed Insights разберите отдельную страницу и найдите узкое место, а с Lighthouse CI прогоняйте регрессию перед каждым релизом. Не наоборот — принимать лабораторные оценки за реальные показатели на проде это самая частая ошибка в оптимизации производительности.

3. Оптимизация LCP: большое изображение первого экрана — главный враг

80% проблем с LCP на корпоративных сайтах B2B связаны с hero-изображением и каруселью на первом экране.

Узкое место	Как это выглядит	Действие	Ожидаемый эффект
Главное изображение не сжато	hero-изображение PNG размером более 500 КБ	Конвертировать в WebP/AVIF, качество 80, srcset с несколькими размерами	LCP снижается на 0,5–1,5 секунды
Главное изображение не предзагружено	Браузер поздно обнаруживает hero-изображение	Добавить в head preload для главного изображения	LCP снижается на 0,2–0,5 секунды
Шрифты блокируют рендеринг	Поздняя загрузка кастомных шрифтов приводит к пустому экрану	font-display: swap, загружать только нужные начертания	LCP снижается на 0,3–0,8 секунды
Медленный ответ сервера	TTFB превышает 1,8 секунды	Подключить CDN, включить HTTP/2, кеширование PHP	LCP снижается на 0,4–1 секунду
Сторонние скрипты задерживают первую отрисовку	Скрипты трекинга в head блокируют загрузку	defer или отложенная загрузка после idle	LCP снижается на 0,2–0,6 секунды

Один упускаемый момент: на корпоративных сайтах B2B в качестве hero часто ставят панораму завода или большое фото продукта, и это обычно исходный снимок весом более 2 МБ. Сжать до 200 КБ, перевести в WebP, добавить preload — после этих трёх действий LCP обычно падает вдвое. Если сервер находится в России, а клиенты в Европе и США, TTFB изначально высокий, и без CDN не обойтись.

4. Оптимизация INP: главный виновник — сторонние скрипты

После того как INP заменил FID, корпоративные сайты B2B массово просели, потому что на таких сайтах слишком много маркетинговых скриптов и скриптов поддержки.

Тип скрипта	Частые источники	Влияние на INP	Что делать
Онлайн-чат	Intercom, Zendesk, Tawk	Долгие задачи в главном потоке 200–800 мс	Загружать с задержкой 3 секунды после первого экрана или при прокрутке до низа
Маркетинговая автоматизация	HubSpot, Marketo, Pardot	Формы и всплывающие окна блокируют взаимодействие	Загружать только на целевых страницах, с остальных убрать
Тепловые карты и аналитика	Hotjar, FullStory	Скрипты записи постоянно занимают главный поток	Выборка 10% пользователей, без записи всех
Всплывающее окно чата	Плавающее окно WhatsApp, WeChat Work	Задержка при клике по всплывающему окну	Использовать нативную кнопку, загружать скрипт после клика
Своя карусель	Карусель товаров на главной	Автовоспроизведение JS создаёт долгие задачи	Заменить на CSS-карусель, отключить автовоспроизведение

Чтобы найти узкое место, запишите одно взаимодействие на странице через панель Performance в Chrome DevTools и посмотрите фиолетовые долгие задачи в главном потоке: что занимает больше всего времени, с того и начинайте. Принцип: любой необязательный для первого экрана скрипт откладывайте до первой прокрутки пользователем или до idle 5 секунд. В выборе плагинов будьте сдержанны, ориентируйтесь на Четыре плагина для зарубежных сайтов, и чем больше вы их ставите, тем сложнее пройти по INP.

5. Оптимизация CLS: задайте размеры всем медиа

CLS — самый простой в исправлении показатель, но именно его чаще всего игнорируют.

Источник смещения	Причина	Как исправить	CLS после исправления
Изображения без размеров	у img нет width/height	Добавьте width и height или aspect-ratio	близко к 0
Недостаточно места под рекламу	асинхронная загрузка рекламы растягивает блок	Задайте контейнеру минимальную высоту	снижение с 0.05 до 0.15
Подмена шрифта	FOIT/FOUT вызывают перекомпоновку	font-display: swap, зарезервируйте размеры резервного шрифта	снижение с 0.02 до 0.08
Динамически вставляемый контент	вставка блоков рекомендаций и похожих статей	Зарезервируйте высоту контейнера-заглушки	снижение с 0.05 до 0.1
Поздняя загрузка ленивых изображений	loading=lazy откладывает загрузку и сдвигает контент ниже	Изображение-заглушка или aspect-ratio	снижение с 0.03 до 0.07

Одно жёсткое правило: у любого img, video и iframe на странице в HTML должны быть указаны атрибуты width и height, а CSS через aspect-ratio обеспечивает адаптивность. Это не требует отдельной задачи в спринте — правка шаблона один раз улучшает весь сайт. Доступность и производительность в части резервирования размеров решаются одинаково, см.Область доступности для B2B-сайтов.

6. Приоритеты оптимизации и ритм итераций

Этап	Срок	Цель	Действие	Критерий приёмки
Первая неделя	Диагностика	Найти проблемные шаблоны	Выгрузите из Search Console данные за 28 дней и составьте список 10 худших страниц	Список проблемных шаблонов
Вторая неделя	Работа над LCP	LCP всех шаблонов укладывается в 2,5 секунды	Сжатие изображений + preload + оптимизация шрифтов	Распределение LCP в PSI
Третья неделя	Работа над INP	Сокращение сторонних скриптов	Отложенная загрузка, выборочная запись, удаление ненужных скриптов	Число длинных задач снижено на 50%
Четвёртая неделя	Завершение по CLS	CLS всего сайта ниже 0,1	Атрибуты width и height, контейнеры-заглушки	В GSC нет страниц с ошибками CLS
Постоянно	Мониторинг	Нет регресса при релизах	Lighthouse CI запускается при каждом деплое	Оценка не ниже предыдущей версии

У обслуживания сайта есть свой постоянный ритм, и производительность — лишь один из его пунктов, см.Шесть ежемесячных задач по обслуживанию. После редизайна или переезда производительность легко откатывается назад, поэтому проверяйте её вместе с Редиректы 301 при миграции и сохранение SEO.

FAQ: частые вопросы

Lighthouse показывает больше 90 баллов, а Search Console сообщает о непройденной проверке. Почему?

Потому что Lighthouse измеряет лабораторные данные — один замер в чистой среде, а Search Console использует данные реальных пользователей за 28 дней, включая слабый 4G, старые телефоны и реальные сторонние скрипты. Это совершенно разные выборки. Правильный подход: считать GSC судьёй, а PSI — инструментом диагностики. Если GSC показывает, что какой-то шаблон не проходит, прогоните этот шаблон в PSI и найдите узкое место на отдельной странице, а не гонитесь за максимальным баллом Lighthouse.

У B2B-сайта мало трафика, данных CrUX не хватает. Что делать?

Небольшой сайт может собирать данные о своих реальных пользователях сам, с помощью Web Vitals.js. Код сбора занимает около 1 КБ: добавьте фрагмент в head страницы, и он будет отправлять три метрики — LCP, INP и CLS — в ваше собственное хранилище данных. Так у вас будет собственное распределение по реальным визитам, даже если в CrUX данных о вас нет. Важно: собирайте только значения метрик, не собирайте персональные данные пользователей — это соответствует GDPR, см.GDPR и соответствие требованиям к данным cookie.

Нужен ли автоматический слайдер на первом экране?

С точки зрения производительности автоматическую прокрутку лучше убрать. Второй и третий слайды пользователь всё равно не видит, но их нужно скачать, разобрать и выполнить JS слайдера — это двойная нагрузка и на LCP, и на INP. Замените на одно hero-изображение с CTA или на ручное переключение на CSS. Если бизнесу слайдер необходим, для изображений со второго слайда используйте loading=lazy, а JS слайдера не должен блокировать первый экран.

Удалять ли плагин чата для оптимизации INP?

Не удалять, а отложить. Скрипты поддержки вроде Intercom и Zendesk ценны для конверсии B2B-заявок, но они не должны запускаться при загрузке первого экрана. Сделайте так: подождите 3 секунды после загрузки первого экрана или подключите скрипт после того, как пользователь впервые прокрутит 20% области просмотра. Так вы сохраните канал связи с клиентом и не заблокируете первое взаимодействие. С плавающим окном WhatsApp та же логика: используйте нативную кнопку и загружайте web SDK только после клика.

CLS держится около 0.15 — как опустить его ниже 0.1?

Найдите смещающиеся элементы на панели Layout Shift в DevTools. На сайтах B2B чаще всего три причины: у изображений не заданы width/height; блок похожих статей или рекомендаций вставляется асинхронно через JS и не резервирует место; после загрузки шрифта текст перестраивается. После этих трёх исправлений CLS обычно уходит в пределы 0.05. Что делать конкретно: задать ширину и высоту всем img, задать aspect-ratio всем асинхронным контейнерам, использовать font-display: swap и подобрать системный резервный шрифт близкого размера.

Сколько проблем с производительностью решает CDN?

CDN в первую очередь решает вопросы TTFB и доставки статических ресурсов: его вклад в LCP составляет от 0.3 до 1 секунды, а на INP и CLS он почти не влияет. Если ваш сервер в России, а клиенты в Европе и США, TTFB может доходить до 2 секунд и больше — тогда CDN это первый приоритет. Если TTFB уже в пределах 600 мс, выгода от CDN ограничена, и деньги лучше вложить в изображения и скрипты. Бесплатного тарифа Cloudflare небольшому сайту хватит, а для корпоративного сайта стоит взять Cloudflare Pro или AWS CloudFront.

В заключение

Core Web Vitals — это не сольная партия технической команды, а общая метрика контента, дизайна и маркетинга: размер изображений — на контенте, загрузка скриптов — на маркетинге, смещение макета — на дизайне. Соберите этих трёх людей за одним столом и по две недели на каждого исправляйте метрики по порядку LCP, INP, CLS — за квартал вывести весь сайт в норму вполне реально.

Три шага на этой неделе: выгрузите из Search Console список 10 худших шаблонов; на следующей неделе сожмите hero-изображение и добавьте preload; ещё через неделю отложите загрузку всех скриптов поддержки и маркетинга. После этих трёх шагов снова загляните в GSC — доля непройденных проверок обычно падает больше чем вдвое.

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