Core Web Vitals простыми словами: LCP, INP и CLS и как их улучшить
Core Web Vitals это три метрики, которыми Google оценивает, насколько удобно человеку пользоваться страницей. LCP показывает, как быстро появляется главное содержимое первого экрана. INP показывает, как быстро страница реагирует на клики и ввод. CLS показывает, насколько «прыгает» вёрстка во время загрузки. Хорошие значения: LCP до 2,5 секунды, INP до 200 миллисекунд, CLS до 0,1. Ниже разберём, как устроена каждая метрика, почему PageSpeed Insights показывает две разные оценки и как найти конкретный элемент или скрипт, который портит результат.
Откуда взялись Core Web Vitals
Раньше скорость сайта мерили десятком технических показателей, понятных только разработчикам: время до первого байта, событие DOMContentLoaded, полная загрузка. Проблема в том, что они плохо совпадали с ощущениями человека. Страница могла «загрузиться» по формальным признакам, а посетитель всё ещё смотрел на белый экран или не мог нажать на кнопку.
В 2020 году Google предложил три метрики, привязанные к опыту пользователя: увидеть, нажать, не промахнуться. С марта 2024 года метрику FID заменили на INP, она точнее отражает реакцию страницы. Сейчас набор такой:
| Метрика | Вопрос, на который отвечает | Хорошо | Нужно улучшить | Плохо |
|---|---|---|---|---|
| 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 |
Для Яндекса Core Web Vitals не заявлены как отдельный фактор, но то, что они измеряют, влияет на поведение посетителей: ушёл ли человек, не дождавшись, промахнулся ли по кнопке, бросил ли форму. Поведенческие факторы для Яндекса значат много.
Полевые и лабораторные данные: почему две оценки
Откройте PageSpeed Insights, и вы увидите два блока. Их часто путают.
Полевые данные (блок «Узнайте, с какими проблемами сталкиваются ваши пользователи») собраны у реальных посетителей, которые зашли на сайт из Chrome. Источник называется Chrome UX Report. Данные усредняются за последние 28 дней, и оценивается 75-й процентиль: значение, которое лучше, чем у трёх четвертей визитов. То есть LCP 2,4 секунды в полевых данных значит, что у 75 % посетителей главный элемент появился быстрее 2,4 секунды.
Лабораторные данные (блок «Диагностика проблем с производительностью») это один прогон Lighthouse на сервере Google с эмуляцией среднего смартфона и медленного мобильного интернета. Отсюда баллы от 0 до 100.
Что из этого следует:
- Если вы исправили проблему, лабораторная оценка изменится сразу, а полевые данные будут обновляться в течение четырёх недель.
- Для небольшого сайта полевых данных может не быть совсем: у Chrome недостаточно визитов. Тогда ориентируйтесь на лабораторный замер и собственные замеры.
- INP в лаборатории не измеряется, потому что Lighthouse ничего не нажимает. Вместо него показан TBT, суммарное время блокировки основного потока. Это косвенный признак: высокий TBT обычно означает плохой INP.
- Оценка «пройдено» или «не пройдено» в полевых данных относится ко всем трём метрикам сразу: если хотя бы одна в жёлтой или красной зоне, проверка не пройдена.
LCP: когда появилось главное
LCP фиксирует момент, когда отрисовался самый крупный видимый элемент первого экрана. Обычно это главное фото, баннер, видео-обложка или крупный блок текста с заголовком.
Как найти LCP-элемент
В PageSpeed Insights в разделе диагностики есть пункт «Элемент Largest Contentful Paint». Там указан конкретный тег. Часто это неожиданность: вы думали про баннер, а самым крупным элементом оказался фон слайдера или текстовый абзац.
В Chrome DevTools откройте вкладку Performance, нажмите кнопку перезагрузки с записью, и на дорожке Timings появится отметка LCP. При наведении подсветится элемент.
Из чего складывается LCP
Время LCP делится на четыре части. Понять, какая из них большая, значит понять, что чинить.
- Время ответа сервера (TTFB). Браузер ждёт HTML. Если эта часть больше 0,8 секунды, проблема на сервере: медленная CMS, нет кеша, слабый хостинг.
- Задержка до начала загрузки ресурса. HTML пришёл, но браузер не сразу узнал о картинке. Так бывает, когда изображение подставляется через JavaScript, задано фоном в CSS или стоит в слайдере, который инициализируется скриптом.
- Время загрузки ресурса. Картинка большая или грузится с медленного стороннего сервера.
- Задержка отрисовки. Картинка уже скачана, но браузер не может её показать: ждёт стили, шрифты или выполнение скриптов.
Как улучшить LCP
- Главное изображение первого экрана должно быть обычным тегом
<img>в HTML, а не фоном и не частью слайдера, собираемого скриптом. - Добавьте ему
fetchpriority="high"и ни в коем случае не ставьтеloading="lazy". Ленивая загрузка на LCP-элементе одна из самых частых ошибок: браузер намеренно откладывает главную картинку. - Если картинка с другого домена, добавьте
<link rel="preconnect">к этому домену или перенесите файл к себе. - Уменьшите вес изображения и отдавайте его в WebP или AVIF.
- Если LCP-элемент текстовый, ускорьте загрузку шрифта или покажите текст системным шрифтом сразу.
Про сжатие картинок, кеширование и серверную часть подробно написано в статье как ускорить сайт, здесь не будем повторяться.
INP: насколько быстро страница реагирует
INP измеряет задержку между действием пользователя (клик, касание, нажатие клавиши) и следующей отрисовкой, когда человек видит результат. Учитываются все взаимодействия за визит, а в итог идёт одно из худших. Поэтому одна тормозящая кнопка «Купить» портит INP всей страницы.
Из чего складывается INP
- Задержка ввода. Человек нажал, но основной поток браузера занят другой задачей, например выполнением скрипта чата или аналитики. Обработчик клика ждёт своей очереди.
- Обработка. Выполняется сам код обработчика. Если по клику на фильтр каталога скрипт перебирает тысячи товаров и перестраивает весь список, это долго.
- Задержка отрисовки. Код выполнился, но браузеру нужно пересчитать стили и вёрстку большой страницы.
Как найти виновника
В полевых данных PageSpeed Insights видно только итоговое значение. Чтобы найти конкретное медленное действие:
- Откройте страницу в Chrome, DevTools, вкладку Performance. В современных версиях там показываются Live metrics, включая INP, прямо во время работы со страницей.
- Включите замедление CPU в 4 раза: так вы увидите сайт глазами владельца среднего смартфона.
- Покликайте по меню, фильтрам, кнопкам корзины, раскрытию FAQ. Действие с большим INP подсветится.
- Запишите профиль этого действия и посмотрите длинные задачи (Long Tasks, отмечены красным углом). В них будет видно, какой скрипт занимает время.
Чаще всего виновники такие: сторонние виджеты, которые выполняют код при каждом клике, тяжёлые фреймворки на страницах, где они не нужны, обработчики, которые сразу делают всю работу вместо того, чтобы сначала показать реакцию.
Как улучшить INP
- Сначала показать отклик, потом считать. По клику на «Применить фильтр» сразу покажите индикатор загрузки, а пересчёт запустите следующим шагом. Пользователь видит реакцию за десятки миллисекунд.
- Дробить длинные задачи. Если скрипт обрабатывает большой массив, делите работу на части и отдавайте управление браузеру между ними, например через
setTimeoutилиscheduler.yield()там, где он поддерживается. - Убрать лишний JavaScript. Каждый подключённый скрипт конкурирует за основной поток. Особенно сторонние: пиксели, виджеты, коллтрекинг.
- Не перестраивать всю страницу. Обновляйте только изменившийся блок, а не весь каталог.
- Сократить размер DOM. Страница с 5000 элементов перерисовывается медленнее, чем с 1500. Длинные списки можно подгружать частями.
CLS: прыгает ли вёрстка
CLS считает, насколько сдвигаются видимые элементы без участия пользователя. Классическая ситуация: вы хотите нажать на ссылку, в этот момент сверху загружается баннер, текст съезжает вниз, и вы нажимаете не туда.
Значение CLS считается как произведение доли экрана, которую занимает сдвинувшийся элемент, на расстояние сдвига. Сдвиги группируются в «окна» до 5 секунд, и в итог идёт самое плохое окно. Сдвиги в течение 0,5 секунды после клика или нажатия клавиши не учитываются: если человек сам раскрыл блок, это ожидаемо.
Как найти, что сдвигается
- В PageSpeed Insights в диагностике есть пункт «Не допускайте значительных сдвигов макета» со списком элементов.
- В DevTools откройте меню Rendering (три точки, More tools, Rendering) и включите Layout Shift Regions. При загрузке страницы сдвигающиеся области будут подсвечиваться синим.
Частые причины и что делать
| Причина | Что происходит | Решение |
|---|---|---|
| Картинки и видео без размеров | браузер не знает высоту, пока не скачал файл | указать width и height или aspect-ratio в CSS |
| Баннеры, рекламные блоки, виджеты | появляются после загрузки и раздвигают контент | заранее зарезервировать место фиксированной высоты |
| Плашка cookie или акции сверху | сдвигает всю страницу вниз | показывать поверх контента, внизу экрана |
| Веб-шрифты | текст перерисовывается другим шрифтом и меняет размеры | подобрать запасной шрифт с близкими метриками, использовать size-adjust |
Анимации через top, margin, height | каждый кадр сдвигает соседей | анимировать transform и opacity |
| Контент, подгружаемый скриптом | список отзывов, карта, блок цен появляется позже | место под блок задаётся сразу, со скелетоном |
Пример резервирования места под блок, который загрузится позже:
.reviews-widget {
min-height: 420px;
}
.video-cover {
aspect-ratio: 16 / 9;
width: 100%;
}Как следить за Core Web Vitals постоянно
Разовый замер покажет состояние на сегодня. Но метрики ухудшаются незаметно: маркетолог добавил виджет, контент-менеджер загрузил фото на 4 МБ, вышло обновление темы.
Что можно настроить:
- Google Search Console, отчёт «Основные интернет-показатели». Группирует страницы сайта по статусу и показывает, какие шаблоны проблемные. Работает на тех же полевых данных Chrome.
- Собственный сбор метрик. Библиотека
web-vitalsот Google измеряет LCP, INP и CLS у каждого посетителя, в том числе в Яндекс Браузере, где Chrome UX Report данные не собирает. Значения можно отправлять в параметры визитов Яндекс Метрики.
import { onLCP, onINP, onCLS } from "web-vitals";
function sendToMetrika(metric) {
const value = metric.name === "CLS"
? Math.round(metric.value * 1000)
: Math.round(metric.value);
ym(12345678, "params", { cwv: { [metric.name]: value } });
}
onLCP(sendToMetrika);
onINP(sendToMetrika);
onCLS(sendToMetrika);После этого в Метрике в отчёте «Параметры визитов» видно распределение значений, а через сегменты можно найти страницы и устройства с плохими цифрами.
- Проверка при каждом изменении. Прогон Lighthouse в DevTools на трёх-четырёх ключевых шаблонах после каждой заметной правки занимает пять минут.
Как вписать замеры в общую проверку сайта, мы описали в статье как проверить сайт на ошибки.
Частые ошибки при работе с Core Web Vitals
- Смотреть только на баллы. Балл PageSpeed это лабораторная оценка одного прогона. Реальным посетителям важны полевые значения трёх метрик.
- Проверять только главную. Карточка товара или статья блога могут быть в красной зоне при зелёной главной.
- Проверять только десктоп. Большая часть проблем видна на мобильных.
- Ждать изменений в полевых данных через день. Окно 28 дней, результат правок станет виден через 2-4 недели.
- Оптимизировать ради 100 баллов. Если все три метрики в зелёной зоне, дальнейшая работа мало что даёт посетителям.
Частые вопросы
Что такое Core Web Vitals в одном предложении?
Это три показателя, которые измеряют, как быстро человек видит главное на странице, как быстро она реагирует на его действия и не прыгает ли вёрстка.
Почему у меня зелёный балл, а Core Web Vitals не пройдены?
Балл считается по лабораторному прогону, а оценка Core Web Vitals по полевым данным реальных посетителей. У настоящих людей бывают медленные телефоны, плохая связь и взаимодействия, которых лабораторный тест не делает. Ориентируйтесь на полевые данные.
Влияет ли CLS на конверсию?
Напрямую измерить сложно, но промах по кнопке из-за сдвига вёрстки раздражает и иногда приводит к случайному клику на рекламу или не ту ссылку. На страницах с формами и корзиной стабильность вёрстки особенно заметна.
Если Core Web Vitals вашего сайта в красной зоне и непонятно, что именно их портит, мы разберём каждую метрику до конкретного элемента и скрипта и сделаем ускорение сайта. Когда старый движок не позволяет выйти в зелёную зону, предложим редизайн на Astro, где быстрые страницы получаются без отдельной оптимизации.