Core Web Vitals для сайта компании, что измерять и как ускорять

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

Три метрики Core Web Vitals без лишней теории

LCP (Largest Contentful Paint) показывает время, за которое на экране появляется самый крупный элемент: обычно главная картинка или заголовочный блок. Это про ощущение «страница загрузилась».

CLS (Cumulative Layout Shift) отвечает за визуальную стабильность. Если вы тянетесь к кнопке, а в этот момент сверху подгружается баннер и всё съезжает вниз, это и есть сдвиг макета.

INP (Interaction to Next Paint) описывает, как быстро страница отзывается на клики, нажатия и ввод. Он заменил прежнюю метрику FID и учитывает отклик на протяжении всего визита.

Рекомендованные пороги «хорошо», «требует улучшения» и «плохо» публикует сам Google в документации web.dev, и они иногда пересматриваются, поэтому актуальные значения лучше сверять там. Я не буду называть цифры по памяти: важнее понимать, какая метрика у вас проседает и почему.

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

Чем измерять: лабораторные и полевые данные

Данные бывают двух видов, и их нельзя путать.

Лабораторные данные получаются при тестовом прогоне на выбранном устройстве и канале: Lighthouse в браузере, PageSpeed Insights. Они воспроизводимы и хороши для поиска причин и проверки правок.

Полевые данные собраны с реальных посетителей. PageSpeed Insights показывает их, если у сайта достаточно трафика, а в панелях для вебмастеров есть отчёты по основным показателям. Это то, что действительно влияет на оценку, потому что у людей разные телефоны и разная связь.

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

Рабочая привычка: перед правками зафиксируйте результаты для 3-5 ключевых страниц (главная, главная услуга, статья, страница контактов), после правок сравните. Без исходных замеров вы не отличите улучшение от случайного колебания.

Как ускорить LCP, главный элемент страницы

LCP чаще всего страдает по четырём причинам, и проверять их стоит в таком порядке.

1. Медленный ответ сервера. Если HTML приходит долго, всё остальное начинается с опозданием. Причины: слабый тариф хостинга, тяжёлая CMS без кэша, медленные запросы к базе. Кэширование страниц и нормальный хостинг дают здесь больше всего. Подробнее о выборе в материале как выбрать хостинг для сайта бизнеса.
2. Тяжёлое главное изображение. Огромная фотография в полном разрешении — классика. Используйте современные форматы (WebP или AVIF), сжатие и размеры под реальное отображение.
3. Поздняя загрузка нужного ресурса. Браузер обнаруживает картинку слишком поздно, потому что она подставляется скриптом или задана в CSS. Делайте главное изображение обычным тегом <img> и подсказывайте приоритет.
4. Блокирующие CSS и скрипты в голове страницы. Пока они загружаются, браузер ничего не рисует.

Главному изображению полезно дать приоритет, а остальным, наоборот, ленивую загрузку:

<img src="/img/hero.webp" width="1200" height="600" alt="..." fetchpriority="high">

<img src="/img/team.webp" width="600" height="400" alt="..." loading="lazy">

Ленивую загрузку нельзя применять к главному изображению первого экрана: оно как раз нужно сразу.

Как убрать сдвиги макета и сделать CLS спокойным

Сдвиги почти всегда вызваны тем, что браузер не знает заранее размер будущего элемента. Лечение системное.

• Указывайте width и height у изображений и видео, либо задавайте пропорции через CSS aspect-ratio. Тогда место под них резервируется до загрузки.
• Резервируйте место под баннеры, виджеты, рекламу и формы cookie-уведомлений. Если блок появится позже, пусть для него заранее будет пустая область нужной высоты.
• Не вставляйте новый контент выше уже показанного, кроме случаев после действия пользователя.
• Подключайте веб-шрифты так, чтобы смена шрифта не прыгала текстом: используйте font-display: swap и, если можно, близкий по размерам системный шрифт на время загрузки, а также предзагрузку критичного файла шрифта.
• Анимации делайте через transform и opacity, а не через изменение размеров и позиций, которые заставляют пересчитывать вёрстку.

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

Как улучшить INP и отзывчивость

INP ухудшается, когда основной поток браузера занят JavaScript, и клик ждёт своей очереди. На сайтах компаний главные виновники известны: тяжёлые сторонние виджеты (чаты, карты, всплывающие окна, несколько счётчиков аналитики), большие фреймворки ради простых страниц и обработчики событий, делающие слишком много работы.

Что помогает:

• Провести инвентаризацию сторонних скриптов и убрать те, которыми никто не пользуется. Часто на сайте висят забытые счётчики и виджеты прошлых экспериментов.
• Загружать некритичные скрипты с атрибутами defer или async, а виджеты чата и карты подгружать после первого взаимодействия или после загрузки страницы.
• Разбивать долгие задачи на части и откладывать несрочные вычисления.
• Для лёгких сайтов услуг реально обходиться минимумом JavaScript: статичные страницы и одна-две небольшие вставки.

Обратите внимание, что бизнес-польза нередко прямо противоположна желанию «набить» страницу. Каждая лишняя вставка стоит скорости, и вопрос «окупается ли она» нужно задавать про каждую. Если вы выбираете технологию под новый проект, это стоит учесть заранее, как и в сравнении PHP без фреймворка и Laravel.

Порядок работ: как не распыляться

Чтобы ускорение не превратилось в бесконечную гонку за зелёными значками, я предлагаю такой порядок.

1. Замерить ключевые страницы на мобильном профиле, записать результаты.
2. Найти самые тяжёлые ресурсы в отчёте (картинки, шрифты, скрипты) и устранить их.
3. Включить сжатие текстовых ответов на сервере и кэширование статических файлов.
4. Настроить кэш страниц, если сайт динамический.
5. Проверить CLS и добавить размеры к медиа.
6. Пересмотреть сторонние скрипты.
7. Повторить замеры и сравнить.

На практике первые три-четыре пункта дают основную часть выигрыша. Дальше возвраты уменьшаются, и тратить время на доведение каждой страницы до идеала обычно не стоит.

Как не сломать скорость после ускорения

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

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

Если сайт на CMS, обратите внимание на обновления. Старые версии тем и плагинов нередко подгружают лишние библиотеки на каждой странице, даже там, где они не нужны. Чистка подключений по страницам иногда даёт заметный эффект без единой строчки новой разработки.

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

Частые вопросы

Влияют ли Core Web Vitals на позиции в поиске?

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

Почему в PageSpeed разные результаты при повторных запусках?

Лабораторные измерения зависят от нагрузки на сервер, сети и самого тестового окружения. Делайте несколько прогонов и смотрите на тенденцию, а не на одно число.

Достаточно ли поставить плагин кэширования?

Для CMS плагин кэша часто даёт заметное улучшение, но не решает проблем с тяжёлыми картинками, сторонними скриптами и медленной базой. Это один из шагов, не весь план.

Как часто проверять метрики?

После каждого заметного изменения на сайте (новая тема, плагин, виджет) и в плановом порядке раз в квартал. Регресс обычно приходит вместе с очередным подключённым скриптом.

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