Страница может быть полезной, хорошо написанной и всё равно проигрывать, если она открывается вяло, реагирует с задержкой или "прыгает" прямо под курсором. Пользователь редко формулирует это как техническую проблему. Он просто закрывает вкладку.
Именно поэтому Core Web Vitals важны не только для разработчиков. Это метрики на стыке SEO, UX и конверсии.
Что именно измеряют Core Web Vitals
У этих метрик разные роли, и смотреть на них лучше вместе.
1. LCP (Largest Contentful Paint)
LCP показывает, когда в видимой области экрана появляется основной крупный элемент. Чаще всего это hero-изображение, баннер, видеообложка или первый важный текстовый блок.
Хороший ориентир: 2,5 секунды или меньше.
2. INP (Interaction to Next Paint)
INP измеряет, насколько быстро страница визуально реагирует на реальное действие пользователя: клик, тап, открытие меню, ввод в форму.
Нормальная цель: 200 мс или меньше.
3. CLS (Cumulative Layout Shift)
CLS показывает, насколько сильно макет неожиданно сдвигается во время загрузки.
Желательно держать показатель на уровне 0,1 или ниже.
Как измерять без хаотичных правок
Любая оптимизация начинается с внятной диагностики. Иначе очень легко потратить время не на тот узкий участок.
1. Google Search Console и PageSpeed Insights
Отчёт Core Web Vitals в Search Console помогает увидеть проблемные группы URL по реальным пользовательским данным. PageSpeed Insights подходит для разбора конкретной страницы.
2. Lighthouse в Chrome
Lighthouse удобен для быстрой технической проверки. Смотри в первую очередь на:
- какой элемент распознан как LCP
- какие скрипты забивают main thread
- какие ресурсы блокируют первый рендер
- в какой момент происходят layout shift
3. RUM-данные
Лабораторные тесты полезны, но не заменяют реальных пользователей. Старые устройства, мобильные сети, внешние скрипты и региональные задержки лучше всего видны именно в RUM.
Чтобы приоритизировать задачи со стороны SEO, можно дополнительно прогнать страницы через SEO Analyzer и быстрее понять, какие URL дают наибольшую просадку.
Как снизить LCP
Плохой LCP обычно связан не с десятком мелочей, а с несколькими очевидными тормозами: тяжёлый главный визуал, медленный сервер, лишние ресурсы на критическом пути.
1. Приведи в порядок главное изображение
- используй WebP или AVIF
- отдавай разные размеры через
srcsetили<picture> - сжимай изображение до публикации
- не ставь
loading="lazy"на LCP-кандидат - задавай
widthиheight
1<picture> 2 <source 3 srcset="hero-1200.webp 1200w, hero-800.webp 800w, hero-400.webp 400w" 4 type="image/webp" 5 sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px" 6 > 7 <source 8 srcset="hero-1200.jpg 1200w, hero-800.jpg 800w, hero-400.jpg 400w" 9 type="image/jpeg" 10 sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px" 11 > 12 <img src="hero-800.jpg" alt="Homepage hero image" width="1200" height="800" loading="eager"> 13</picture>
2. Ускорь ответ сервера
Если TTFB высокий, браузеру просто нечего показывать.
- включи кэширование там, где оно уместно
- отдай статику через CDN
- проверь медленные запросы к базе
- убери тяжёлую серверную логику с критического пути
3. Сократи блокирующие ресурсы
Часто страница тормозит не из-за контента, а из-за лишнего CSS, шрифтов и JavaScript до первого экрана.
- вынеси critical CSS в приоритет
- загружай второстепенные скрипты через
defer - для независимых сторонних скриптов используй
async - исключи библиотеки, которые не нужны на старте
1<head> 2 <link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin> 3 <script src="/js/main.js" defer></script> 4 <script src="https://analytics.example.com/script.js" async></script> 5</head>
4. Используй preload точечно
preload отлично помогает для LCP-изображения или ключевого шрифта. Но если приоритизировать всё подряд, можно только усилить конкуренцию за сеть.
Как улучшить INP
Плохой INP почти всегда означает, что основной поток браузера перегружен.
1. Облегчи JavaScript
- разбей крупные бандлы
- загружай второстепенные функции по требованию
- убери мёртвый код
- не гидратируй слишком рано то, что не требует мгновенного взаимодействия
1document.querySelector('.open-chart').addEventListener('click', async () => { 2 const { renderChart } = await import('./chart-module.js'); 3 renderChart(); 4});
2. Пересмотри сторонние скрипты
Чат-виджеты, трекеры, карты, рекламные блоки, A/B-платформы часто портят отклик сильнее, чем собственный код.
Стоит задать три вопроса:
- этот скрипт действительно приносит бизнес-ценность?
- можно ли загрузить его после первой прокрутки или первого действия?
- можно ли отказаться от него совсем?
3. Разбивай длинные задачи
Если один JS-процесс надолго блокирует main thread, страница перестаёт реагировать вовремя.
- дели тяжёлые операции на части
- отправляй второстепенные задачи в
requestIdleCallback - выноси вычисления в Web Worker
Как уменьшить CLS
CLS редко появляется из-за одной большой ошибки. Обычно это цепочка мелких недочётов.
1. Резервируй место для медиа и встраиваемых блоков
Изображения, видео и iframe должны иметь заранее понятный размер.
- указывай
widthиheight - используй
aspect-ratioдля адаптивных блоков - размещай embeds в контейнерах со стабильной высотой
2. Не вставляй элементы внезапно
Плашки, баннеры, рекомендации, блоки рекламы, появляющиеся сверху, легко ломают визуальную стабильность.
- резервируй место заранее
- используй overlay, если не хочешь двигать контент
- задавай минимальную высоту рекламным слотам
3. Проверь загрузку шрифтов
Шрифты тоже могут вызывать заметные сдвиги.
- предварительно загружай основной шрифт
- используй
font-display: swap - подбирай fallback-шрифт с похожими метриками
Что это даёт на практике
У одного e-commerce проекта с большим мобильным трафиком стартовые показатели были такими:
- LCP: 4,8 с
- INP: 180 мс
- CLS: 0,25
- конверсия: 1,2 %
- показатель отказов: 65 %
Что сделали:
- перевели основные изображения в WebP
- зарезервировали размеры для картинок и рекламы
- отложили загрузку аналитики и рекламных скриптов
- добавили preload для ключевых hero-изображений
- сократили critical CSS
- вынесли статику на CDN
- пересобрали стратегию шрифтов через
font-display: swap
После этого получилось:
- LCP: 1,9 с
- INP: 65 мс
- CLS: 0,08
- конверсия: 2,8 %
- показатель отказов: 42 %
Не магия, а нормальная расстановка приоритетов.
Почему на этом нельзя останавливаться
Core Web Vitals часто ухудшаются постепенно: новый виджет, новый баннер, ещё один пиксель, тяжёлая картинка в hero-блоке, и проблема возвращается.
1. Нужен постоянный мониторинг
Следи за Search Console, RUM и ключевыми типами страниц на постоянной основе.
2. Нужны performance budget
Полезно ограничить:
- общий вес JavaScript
- максимальный размер изображений
- количество шрифтов
- число сторонних скриптов
3. Встрой проверку в релизный процесс
Новая посадочная страница, редизайн или крупная функция должны проходить короткую проверку на LCP, INP и CLS до публикации.
4. Делай это задачей команды, а не одного человека
На эти метрики влияют разработка, дизайн, контент и маркетинг. Не только код.
Коротко по сути
- LCP улучшается через главный ресурс, сервер и критический путь рендера.
- INP улучшается, когда основному потоку браузера становится легче.
- CLS снижается, когда интерфейс заранее знает, сколько места займут элементы.
- Лабораторные тесты полезны, но решают реальные пользовательские данные.
- Цель не в красивом отчёте, а в странице, которая быстрее загружается и лучше продаёт.
Если сначала нужно понять, какие URL проседают сильнее всего из-за производительности, начни с SEO Analyzer, а затем добейся точности через Lighthouse и RUM.
