Core Web Vitals — это набор метрик, с помощью которых Google измеряет качество взаимодействия пользователя со страницей: как быстро появляется основной контент, насколько мгновенно сайт реагирует на клики и не «прыгает» ли верстка» вёрстка при загрузке. Для владельца бизнеса это выглядит проще: скорость загрузки сайта прямо влияет на то, сколько людей дождутся страницы, а не вернутся в поиск за следующим результатом. В этом материале SEO-команда Voice разбирает, что именно измеряют LCP, CLS и INP, как их проверить, какие причины чаще всего тормозят сайт и как ускорить сайт без переписывания проекта с нуля.
Что такое Core Web Vitals простыми словами (LCP, CLS, INP)
Google свел десятки технических параметров к трем показателям, которые описывают три разные боли пользователя.
Наибольшая отрисовка контента время до появления наибольшего видимого элемента в пределах экрана: баннера, главного изображения товара, крупного заголовка. Это не «полная загрузка страницы», а момент, когда человек видит, что страница действительно открылась. LCP состоит из четырех частей: время до первого байта от сервера, загрузка ресурса, задержка перед его рендерингом и сам рендеринг. Именно такая раскладка помогает понять, кого «лечить» — хостинг, картинки или шаблон.
Совокупное смещение макета суммарное смещение макета. Классическая ситуация: пользователь тянется к кнопке «Купити», в этот момент догружается баннер, и палец попадает в рекламу. CLS измеряется не в секундах, а в условных единицах: насколько велик элемент и как далеко он сдвинулся.
Задержка ввода до следующего отрисованного кадра реакция интерфейса на действия. Метрика фиксирует задержку между кликом (тапом, нажатием клавиши) и моментом, когда браузер нарисовал визуальный ответ. INP с 2024 года заменил предыдущую метрику FID и оценивает все взаимодействия в течение сессии, а не только первое. Это гораздо более жесткий показатель: он показывает, не «подвисает» ли сайт от перегруженного JavaScript.
Важная деталь: Google оценивает не среднее значение, а 75-й перцентиль реальных визитов за последние 28 дней, отдельно для мобильных и десктопов. То есть три четверти ваших пользователей должны получить результат в пределах нормы, красивая цифра «у меня на ноутбуке всё летает» здесь не аргумент.
Таблица 1. Нормативы Core Web Vitals
| Показатель | Норма | Требует улучшения | Плохо |
| ЛКП | до 2,5 с | 2,5–4,0 с | более 4,0 с |
| ИНП | до 200 мс | 200–500 мс | более 500 мс |
| CLS | до 0,1 | 0,1–0,25 | более 0,25 |
| TTFB (вспомогательная) | до 0,8 с | 0,8–1,8 с | более 1,8 с |
| ФСП (вспомогательная) | до 1,8 с | 1,8–3,0 с | более 3,0 с |
TTFB и FCP не входят в Core Web Vitals, но без них невозможно понять, почему LCP плохой: они показывают, на каком этапе теряется время.
Влияет ли скорость действительно на позиции: что говорит Google
Здесь стоит разделить маркетинговые мифы и официальную позицию. Google прямо указывает, что единого «сигнала скорости» не существует: ранжирующие системы учитывают набор сигналов, связанных с общим пользовательским опытом страницы. Так же в документации сказано, что хорошие показатели в отчете Search Console или сторонних сервисах не гарантируют топ, а погоня за «зеленой сотней» исключительно ради SEO — не лучшее использование времени.
Что это значит на практике?
Во-первых, релевантность контента остается главной. Быстрая страница с поверхностным текстом не обойдет глубокий материал, который действительно отвечает на запрос.
Во-вторых, Core Web Vitals работают как фактор дифференциации. Когда несколько страниц примерно одинаково отвечают запросу, техническое качество становится аргументом в пользу одной из них. В конкурентных коммерческих нишах, где в топе десяток похожих интернет-магазинов, этот аргумент решает.
В-третьих, существует косвенный, но мощный эффект. Медленный сайт увеличивает показатель отказов и pogo-sticking — возвращение в поиск сразу после перехода. Ухудшается поведенческая картина, падает конверсия, дорожает трафик из рекламы. Метрики Core Web Vitals — это, по сути, оцифрованный пользовательский опыт, и именно через него скорость влияет на бизнес-результат сильнее, чем через прямое ранжирование.
Практический вывод для технического SEO: не нужно гоняться за 100 баллами. Нужно вывести все три показателя в «зеленую» зону по полевым данным и остановиться, перераспределив ресурс на контент и ссылки.
Как измерить показатели (PageSpeed Insights, GSC, Lighthouse)
Первое, что нужно усвоить: существуют два типа данных, и они показывают разное.
Полевые данные реальные измерения от пользователей Chrome, собранные в базе CrUX. Это именно то, что учитывает Google. Они доступны за 28-дневный период и только для страниц с достаточным трафиком.
Лабораторные данные синтетический тест в эмуляторе: фиксированное устройство, фиксированная скорость сети. Они нужны для диагностики и проверки гипотез, но не для отчетности. INP в лабораторных условиях вообще не измеряется, так как никто ничего не нажимает.
Инструменты, которые стоит иметь в работе:
- PageSpeed Insights — самый быстрый старт. Вверху полевые данные по URL и по домену, ниже лабораторный аудит Lighthouse с конкретными рекомендациями и экономией в секундах. Смотреть всегда начинайте с мобильной вкладки.
- Google Search Console, отчет Core Web Vitals — единственное место, где виден масштаб проблемы по всему сайту. GSC группирует похожие URL, так что вы сразу видите: «медленные» не отдельные страницы, а весь шаблон карточки товара. Это экономит десятки часов.
- Lighthouse в DevTools предлагает более глубокую диагностику: детализацию LCP по фазам, долгие задачи в JavaScript и снимки смещений макета.
- Панель Performance в DevTools и библиотека web-vitals для точечной работы с INP: она позволяет поймать конкретный обработчик события, который блокирует главный поток.
- Отчет Chrome UX в BigQuery, когда нужно сравнить себя с конкурентами по реальным данным, а не по лабораторному тесту.
10 типичных причин медленного сайта
По результатам наших аудитов картина повторяется из проекта в проект:
- Несжатые изображения в оригинальном размере. Фотография шириной 3000 пикселей, которая выводится в блоке 400 пикселей, — самая частая причина плохого показателя LCP.
- Отсутствие современных форматов. Форматы WebP и AVIF обеспечивают экономию веса на 30–60% без видимой потери качества.
- Медленный сервер и высокий TTFB. Дешевый shared-хостинг, тяжелые запросы к базе, отсутствие кэширования на стороне сервера.
- Куча сторонних скриптов. Чат-виджеты, аналитика, пиксель, гугловские теги, A/B-тесты — каждый добавляет работы главному потоку и портят INP.
- Блокирующие CSS и JS в head. Браузер не может начать рендеринг, пока не загрузит все, что вы ему туда положили.
- Раздутый шаблон и плагины. Универсальная тема с десятком слайдеров, из которых вы используете один.
- Изображения и встроенные элементы без заданных размеров. Прямой путь к плохому CLS: контент прыгает, когда догружается баннер или iframe.
- Шрифты без font-display и без preload. Либо невидимый текст, либо резкий скачок после подмены шрифта.
- Отсутствие кеширования в браузере и CDN. Повторные визиты стоят столько же, сколько первые.
- Тяжелый JavaScript-фреймворк там, где нужен обычный HTML. Особенно больно на страницах категорий и карточек товара.
Что делать: чеклист оптимизации Core Web Vitals
Изображение. Сжмите и переведите в WebP/AVIF. Задайте атрибуты width и height или aspect-ratio для каждого изображения. Включите lazy-loading для всего, что ниже первого экрана, и обязательно отключите его для LCP-элемента, добавив ему fetchpriority=”high”. Это самое дешевое действие с наибольшим эффектом.
Сервер и кэш. Проверьте TTFB, если он превышает 0,8 с, оптимизация фронтенда не спасет. Включите серверное кеширование страниц, сжатие Brotli, HTTP/2 или HTTP/3, подключите CDN, если аудитория распределена географически. Настройте Cache-Control для статики на длительный срок.
JavaScript и CSS. Проведите ревизию сторонних скриптов: всё, что не критично, с атрибутом defer или async, аналитику через менеджер тегов с отложенным запуском. Уберите неиспользуемый CSS, разбейте бандлы на части, длинные задачи свыше 50 мс разделите. Именно это вытягивает INP.
Шрифты. Локальный хостинг вместо внешнего запроса, font-display: swap, preload для основного начертания, сабсеттинг под кириллицу.
Стабильность макета. Зарезервируйте места под баннеры, виджеты и cookie-уведомления. Никогда не вставляйте новый контент над уже видимым, за исключением реакции на действие пользователя.
Порядок работ. Сначала страницы с наибольшим трафиком и худшими показателями, далее шаблоны, и только потом точечная косметика. После каждой итерации ждите обновления полевых данных: CrUX работает с 28-дневным окном, так что мгновенного результата в отчете не будет.
Пример: как ускорение сайта повлияло на трафик
Обобщенный сценарий из нашей практики: интернет-магазин на 4 000 страниц, тематика — товары для дома.
Исходная ситуация: LCP на мобильных устройствах — 5,1 с, INP — 480 мс, CLS — 0,29. В Search Console 781 URL со статусом «Плохо». Позиции по среднечастотным коммерческим запросам — 11–18 места, при этом контент и ссылочный профиль не уступали конкурентам из топ-5.
Что сделали за шесть недель: мы конвертировали каталог изображений в WebP и убрали оригиналы, добавили размеры всем картинкам, перенесли чат-виджет и три маркетинговых скрипта на отложенную загрузку после взаимодействия, включили серверный кэш и Brotli, зарезервировали место под баннер акций в шапке, переписали инициализацию фильтров в каталоге, разделив длинные задачи.
Результат через два месяца после внедрения: LCP 2,2 с, INP 170 мс, CLS 0,04, доля «зеленых» URL 91%. Органический трафик на категории вырос примерно на четверть, конверсия в корзину на 12%, средняя позиция по целевому кластеру поднялась до 5–8 мест.
Честная ремарка: часть прироста — это не ранжирование, а поведение. Люди просто перестали закрывать страницу, не дождавшись каталога. Но именно комбинация этих двух эффектов делает перформанс сайта одним из наиболее недооцененных направлений в SEO.
Выводы
Core Web Vitals — это не волшебная кнопка и не гарантия топа. Это базовая гигиена, без которой остальные усилия работают хуже: вы платите за трафик, который не доходит до контента.
Что стоит запомнить:
- Три метрики, три разные боли: LCP — скорость появления контента, INP — реакция интерфейса, CLS — стабильность макета.
- Google оценивает 75-й перцентиль реальных визитов за 28 дней, отдельно для мобильных. Ориентируйтесь на полевые данные, а не на баллы Lighthouse.
- Мета — «зеленая» зона по трем показателям, а не 100 баллов. Дальше ресурс эффективнее вкладывать в контент.
- Наибольший эффект дают простые вещи: изображения, кэш, ревизия сторонних скриптов.
- Скорость влияет на бизнес двумя путями: через ранжирование и, сильнее, через поведение пользователей.
Если вы не знаете, с чего начать, или оптимизация уже проводилась, а показатели стоят на месте, начните с диагностики. Технический performance-аудит сайта от Voice покажет, какие именно шаблоны тормозят сайт, сколько секунд можно отыграть на каждом из этапов и в каком порядке это делать, чтобы получить результат при минимальном бюджете разработки. Оставьте заявку, и мы подготовим отчет с приоритизированным планом работ.
