Core Web Vitals: метрики скорости сайта и как их улучшить

Что такое Core Web Vitals и почему Google их использует

Core Web Vitals — три метрики, которые Google выделил как ключевые индикаторы пользовательского опыта на странице: насколько быстро появляется основной контент, насколько быстро сайт реагирует на действия пользователя и насколько стабильна вёрстка при загрузке (не «прыгают» ли элементы). С 2021 года эти метрики официально входят в алгоритм ранжирования как часть более широкого набора сигналов Page Experience.

Важно понимать масштаб влияния: Core Web Vitals — это тай-брейкер, а не решающий фактор. Если у двух страниц одинаково хороший, релевантный запросу контент, страница с лучшими показателями скорости получит небольшое преимущество. Но отличная скорость никогда не компенсирует слабый или нерелевантный контент — это лишь один из множества сигналов наравне с E-E-A-T и другими факторами.

Название «Core» (основные) выбрано намеренно: Google периодически расширяет и пересматривает набор показателей Page Experience, но именно три метрики Core Web Vitals остаются стабильным базовым ядром уже несколько лет, в отличие от более второстепенных сигналов вроде наличия интерстициальных объявлений, которые то добавлялись, то теряли самостоятельное значение как отдельный фактор.

LCP — largest contentful paint

LCP измеряет время до отрисовки самого крупного видимого элемента на экране при загрузке — обычно это главное изображение, видео или крупный текстовый блок. Именно этот момент пользователь субъективно воспринимает как «страница загрузилась».

Чаще всего долгий LCP связан с тяжёлым несжатым изображением-героем в начале страницы, отсутствием предзагрузки (preload) ключевого ресурса или блокирующими рендер сторонними скриптами, которые загружаются раньше основного контента.

Важно, что LCP-элемент может отличаться в зависимости от устройства и ширины экрана: на десктопе это часто крупное изображение в шапке, а на мобильном — уже другой блок, например заголовок статьи, если изображение на узком экране визуально меньше по площади. Отчёт PageSpeed Insights явно указывает, какой конкретно элемент был признан LCP для каждого теста, и стоит сверяться именно с этим указанием, а не полагаться на предположения.

INP — отзывчивость на действия пользователя

INP (Interaction to Next Paint) заменил метрику FID в 2024 году и оценивает задержку между действием пользователя (клик, тап, ввод текста) и визуальным откликом интерфейса на протяжении всего времени взаимодействия со страницей, а не только при первом клике.

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

Особенность INP в том, что метрика учитывает не среднее, а близкое к худшему взаимодействие пользователя со страницей (по факту — 98-й процентиль задержек за сессию). Это значит, что даже одно медленное действие среди десятков быстрых способно испортить итоговую оценку страницы, поэтому точечная оптимизация «самого тяжёлого» обработчика клика на странице часто даёт больший эффект, чем равномерное облегчение всех скриптов понемногу.

CLS — стабильность вёрстки при загрузке

CLS (Cumulative Layout Shift) измеряет, насколько сильно «прыгают» элементы на странице во время загрузки — классический пример: пользователь собирается нажать на кнопку, но в этот момент сверху догружается баннер, и клик случайно попадает совсем на другой элемент.

Норма CLS: до 0.1  — хорошо
           0.1-0.25 — требует улучшения
           более 0.25 — плохо

Главные причины высокого CLS — изображения и видео без явно заданных атрибутов width/height (браузер не резервирует место заранее), динамически подгружаемые рекламные блоки и веб-шрифты, которые визуально заменяют системный шрифт после подгрузки (эффект FOIT/FOUT).

Отдельная частая причина скачков CLS на маркетинговых сайтах — баннеры cookie-согласия и всплывающие формы подписки, которые появляются поверх контента через секунду-две после загрузки страницы, сдвигая всё, что находится ниже. Если такой баннер обязателен по юридическим причинам, стоит резервировать под него место заранее в вёрстке, а не давать ему «наезжать» на уже отрисованный контент.

Как измерить Core Web Vitals

Есть два принципиально разных источника данных: лабораторные тесты (Lighthouse, PageSpeed Insights в режиме симуляции) показывают результат в контролируемых условиях один раз, а полевые данные CrUX (Chrome User Experience Report), доступные в отчёте Core Web Vitals в Search Console, показывают реальные показатели у реальных посетителей сайта за последние 28 дней. Для оценки влияния на ранжирование важны именно полевые данные — Google использует в алгоритме их, а не лабораторный результат.

У сайтов с небольшим трафиком полевые данные CrUX иногда попросту отсутствуют в отчёте Search Console — для формирования статистики нужен минимальный объём реальных посещений через браузер Chrome за 28-дневный период. В этом случае лабораторный тест Lighthouse остаётся единственным доступным ориентиром, хотя он и не отражает напрямую то, что учитывает алгоритм ранжирования у более крупных сайтов.

Как улучшить LCP, INP и CLS

• Сжимайте и правильно форматируйте изображения — современные форматы (WebP, AVIF) уменьшают вес в 2-3 раза без потери качества.
• Используйте preload для ключевого изображения LCP-элемента и lazy loading для остальных изображений ниже первого экрана.
• Откладывайте загрузку некритичных сторонних скриптов (чаты, виджеты) до взаимодействия пользователя со страницей.
• Задавайте явные width/height у всех изображений и видео, резервируйте место под баннеры и рекламу заранее.
• Минимизируйте и разбивайте на части тяжёлый JavaScript, чтобы не блокировать главный поток длинными задачами.
• Используйте кэширование статики и CDN для ускорения повторных загрузок и снижения задержки для пользователей из разных регионов.

Важно оптимизировать метрики в правильном порядке приоритета: если у сайта серьёзные проблемы одновременно по всем трём показателям, начинать стоит с LCP — он напрямую влияет на субъективное восприятие «быстроты» сайта пользователем, тогда как INP и CLS чаще заметны только при активном взаимодействии со страницей уже после первой отрисовки.

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

Хорошая практика — включить проверку Core Web Vitals в регулярный процесс перед каждым релизом сайта, а не только в разовый годовой аудит: небольшой лабораторный тест PageSpeed Insights на тестовом контуре перед выкладкой изменений в продакшн занимает пару минут, но позволяет поймать регрессию до того, как она повлияет на реальных пользователей и на позиции в выдаче.

Связь Core Web Vitals с техническим SEO

Core Web Vitals — лишь один из пунктов более широкого чек-листа технического SEO: сама по себе быстрая загрузка не спасёт сайт с закрытыми в robots.txt важными разделами или без корректных canonical. Проверять скорость стоит в рамках общего технического аудита, а не изолированно.

Погоня за идеальными 100 баллами в PageSpeed Insights без учёта реального пользовательского опыта — частая ловушка: важнее полевые данные CrUX за реальных посетителей, чем лабораторный синтетический тест.

Чек-лист оптимизации скорости сайта

1. Проверить полевые данные CrUX в Search Console (не только лабораторный тест)
2. LCP-изображение — в современном формате, с preload
3. Все изображения ниже первого экрана — на lazy loading
4. Явные width/height у изображений, видео и рекламных блоков
5. Сторонние скрипты — асинхронно или отложенно
6. Веб-шрифты — с font-display: swap или предзагрузкой
7. Проверка результата на реальных мобильных устройствах, не только на десктопе

После внедрения любых изменений стоит выждать хотя бы 28 дней перед тем, как делать выводы по полевым данным CrUX — именно за такой период накапливается статистика по реальным пользователям в отчёте Search Console, и более ранняя оценка может показывать смешанные, ещё не устоявшиеся цифры.