Core Web Vitals: что это и как улучшить показатели сайта

Что такое Core Web Vitals

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

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

Важно различать два источника данных. Лабораторные данные (lab) собираются инструментами вроде Lighthouse в контролируемых условиях — они удобны для отладки. Полевые данные (field) берутся из реального трафика через CrUX (Chrome User Experience Report) и отражают опыт настоящих посетителей. Google в ранжировании опирается именно на полевые данные, поэтому ориентироваться нужно прежде всего на них.

Три ключевые метрики: LCP, INP, CLS

Сегодня в Core Web Vitals входят три метрики. С марта 2024 года метрику FID (First Input Delay) официально заменили на INP (Interaction to Next Paint) — она точнее отражает отзывчивость страницы.

• LCP (Largest Contentful Paint) — время отрисовки самого большого видимого элемента: крупного изображения, баннера или блока текста. Хороший показатель — до 2,5 секунд, требует улучшения — 2,5–4 секунды, плохой — более 4 секунд.
• INP (Interaction to Next Paint) — задержка визуального отклика на действия пользователя за всю сессию. Хорошо — до 200 мс, нужно улучшать — 200–500 мс, плохо — более 500 мс.
• CLS (Cumulative Layout Shift) — суммарное смещение элементов вёрстки без участия пользователя. Хорошо — до 0,1, средне — 0,1–0,25, плохо — выше 0,25.

Чтобы страница считалась «прошедшей» проверку CWV, все три метрики должны попадать в зелёную зону по 75-му перцентилю — то есть у 75% посетителей значения не хуже пороговых. Это значит, что нельзя ориентироваться только на «среднюю» скорость: важен опыт большинства, включая пользователей со слабыми устройствами и медленным интернетом.

Чем измерять Core Web Vitals

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

• PageSpeed Insights — показывает и полевые (CrUX), и лабораторные данные для конкретного URL. Удобен как точка входа.
• Google Search Console — отчёт «Основные интернет-показатели» группирует страницы по статусам на уровне всего сайта и показывает динамику.
• Lighthouse (в DevTools браузера) — для глубокой отладки в лабораторных условиях с детализацией проблем.
• Web Vitals extension и панель Performance в Chrome — помогают ловить смещения вёрстки и медленные взаимодействия в реальном времени.

Помните о разнице между lab и field: Lighthouse может показать отличный LCP на быстром канале, но реальные пользователи на мобильном 4G увидят другую картину. Если CrUX-данных по сайту мало (малопосещаемые страницы), ориентируйтесь на лабораторные показатели и здравый смысл. Полноценная диагностика обычно входит в технический SEO-аудит, где метрики связывают с конкретными причинами в коде и инфраструктуре.

Как улучшить LCP

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

• Ускорьте ответ сервера (TTFB). Подключите кэширование, оптимизируйте запросы к базе данных, используйте быстрый хостинг и CDN для отдачи статики ближе к пользователю.
• Оптимизируйте главное изображение. Сжимайте картинки, переводите в современные форматы WebP или AVIF, задавайте корректные размеры под вьюпорт. LCP-изображение не стоит грузить лениво — наоборот, добавьте ему приоритет (fetchpriority="high").
• Используйте preload для критичных ресурсов. Предзагрузка ключевого изображения или шрифта сокращает время до его появления.
• Уберите блокирующий CSS и JS. Выделите критический CSS для первого экрана, остальное грузите асинхронно. Скрипты по возможности откладывайте через defer.
• Следите за шрифтами. Применяйте font-display: swap, чтобы текст не оставался невидимым во время загрузки веб-шрифта.

Частая ошибка — пытаться улучшить LCP только сжатием картинок, игнорируя медленный сервер. Если TTFB уже 1,5 секунды, никакая оптимизация изображений не вытянет метрику в зелёную зону.

Как улучшить INP

INP измеряет отзывчивость, поэтому корень проблемы почти всегда — тяжёлый JavaScript, который надолго блокирует основной поток браузера. Когда пользователь кликает, а скрипт в этот момент выполняет долгую задачу, отклик задерживается.

• Сократите объём и сложность JS. Уберите неиспользуемый код, тяжёлые библиотеки, дубли. Чем меньше скриптов выполняется при взаимодействии, тем быстрее отклик.
• Разбивайте длинные задачи. Длительные вычисления дробите на части, освобождая основной поток. Используйте requestIdleCallback или вынос тяжёлой логики в Web Workers.
• Откладывайте несрочное. Аналитика, виджеты чатов, баннеры и сторонние скрипты часто можно подгружать после взаимодействия или с задержкой.
• Оптимизируйте обработчики событий. Не вешайте тяжёлую логику прямо на клик — давайте браузеру сначала отрисовать визуальный отклик, а сложные операции выполняйте асинхронно.
• Контролируйте сторонние теги. Каждый внешний скрипт через GTM или напрямую — потенциальный источник долгих задач. Аудит сторонних подключений нередко даёт самый быстрый прирост.

INP сложнее отлаживать, чем LCP, потому что проблема проявляется только при реальных действиях. Используйте панель Performance, записывайте взаимодействия и ищите «длинные задачи» (long tasks) дольше 50 мс.

Как улучшить CLS

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

• Изображения и видео без размеров. Всегда указывайте атрибуты width и height или задавайте aspect-ratio через CSS, чтобы браузер заранее резервировал место под медиа.
• Рекламные блоки и встраиваемые виджеты. Заранее выделяйте под них фиксированное пространство контейнером с минимальной высотой.
• Динамически вставляемый контент. Не добавляйте элементы над уже видимым контентом — это сдвигает всё вниз. Если контент появляется после действия пользователя, смещение в CLS не засчитывается.
• Веб-шрифты. Резкая подмена системного шрифта на веб-шрифт меняет высоту текста. Подбирайте резервные шрифты с близкими метриками и используйте size-adjust.

CLS — самая «дешёвая» в исправлении метрика: чаще всего достаточно проставить размеры медиа и зарезервировать место под динамические блоки. Зато её игнорирование особенно сильно бьёт по поведенческим факторам и конверсии.

Типичные ошибки и правильный порядок работы

На практике команды совершают одни и те же ошибки. Самая частая — оптимизация по лабораторным данным в отрыве от реальных пользователей. Сайт показывает 95 баллов в Lighthouse, но в Search Console страницы остаются красными, потому что у реальной аудитории слабые телефоны и плохая связь.

Вторая ошибка — точечные правки без диагностики причин. Сжали картинки, а LCP не сдвинулся, потому что узкое место было в сервере. Поэтому работу выстраивают по логике:

• Соберите полевые данные по группам страниц через Search Console и определите, какие шаблоны проседают (главная, карточка товара, статья).
• Для проблемных шаблонов выявите конкретную причину через PageSpeed Insights и Lighthouse.
• Сначала чините то, что массово влияет на 75-й перцентиль, а не отдельные URL.
• Внедряйте изменения и ждите обновления CrUX — полевые данные считаются по скользящему окну около 28 дней, мгновенного эффекта не будет.

Третья ошибка — относиться к CWV как к разовой задаче. После релизов, установки новых виджетов или редизайна метрики легко деградируют. Нужен регулярный мониторинг. Для проектов в локальном и региональном поиске стоит учитывать, что скорость особенно критична на мобильных — а это основная аудитория услуг локального продвижения.

Наконец, не гонитесь за идеальными цифрами в ущерб смыслу. Цель — чтобы все три метрики стабильно были в зелёной зоне у большинства пользователей, а не чтобы Lighthouse показал ровно 100. Реальный комфорт посетителей важнее красивого отчёта.

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

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

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

Почему PageSpeed Insights и Search Console показывают разные данные?

PageSpeed может показывать лабораторный тест конкретного URL, а Search Console — полевые данные CrUX по группам страниц за период около 28 дней. В ранжировании учитываются именно полевые данные реальных пользователей.

Как быстро улучшатся метрики после оптимизации?

Лабораторные показатели меняются сразу, а полевые обновляются постепенно: CrUX считает значения по скользящему окну примерно в 28 дней. Поэтому после доработок реальный статус в зелёную зону переходит не мгновенно, а в течение нескольких недель.