Core Web Vitals: LCP, INP и CLS в зелёной зоне

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

Кому подходит решение, а кому нет

Рекомендуется:

• Сайт уже работает, но PageSpeed Insights показывает красные зоны по ключевым метрикам.
• Много трафика с мобильных устройств — там метрики критичнее из-за слабых сетей.
• Планируете рекламу и не хотите терять конверсию на медленной загрузке.

Не подходит:

• Сайт ещё не запущен — сфокусируйтесь на базовой настройке сервера и кэша.
• Проблема в самих данных: нет аналитики, и непонятно, какие страницы реально важны.
• Ждёте, что одни метрики вытянут сайт в топ — релевантность контента важнее.

Что говорят цифры и исследования

Официальные пороги метрик описаны в документации web.dev (Google): LCP считается хорошим до 2,5 секунды, INP — до 200 миллисекунд, CLS — до 0,1. Это не эмпирика отдельных оптимизаторов, а единые границы, по которым Google оценивает опыт страницы.

Google разделяет лабораторные и полевые данные. Лабораторные даёт Lighthouse — он воспроизводимо показывает, что именно тормозит страницу. Полевые собирает отчёт Chrome UX Report с реальных устройств, и именно эти значения попадают в оценку поисковика. Поэтому оптимизацию начинают с полевых метрик, а лабораторный тест используют как инструмент поиска причин.

По документации Google Search Central об опыте страницы, Core Web Vitals учитываются как один из сигналов ранжирования. Это не самый весомый фактор, но при прочих равных более быстрая страница получает преимущество.

Три метрики и их пороги

Пошаговое руководство

1. Шаг 1: Снимите текущие значения

   Откройте PageSpeed Insights и посмотрите обе части отчёта: полевые данные сверху и лабораторный анализ ниже. Запишите проблемные страницы, а не весь сайт целиком.

   https://pagespeed.web.dev/

2. Шаг 2: Ускорьте LCP

   Основной контент чаще всего тормозит из-за тяжёлого hero-изображения или медленного ответа сервера. Уменьшите размер картинки, переведите её в WebP, настройте кэш и сжатие на сервере.

   <img src="hero.webp" width="1200" height="630" fetchpriority="high">

3. Шаг 3: Сократите INP

   Отклик страдает от избыточного JavaScript и тяжёлых обработчиков событий. Разбейте длинные задачи, уберите неиспользуемые скрипты и отложите второстепенные виджеты.

   <script src="/app.js" defer></script>

4. Шаг 4: Уберите сдвиги CLS

   Элементы прыгают, когда у изображений, баннеров и встроенных блоков не заданы размеры. Указывайте ширину и высоту у img и iframe, резервируйте место под рекламу.

   <iframe src="..." width="560" height="315"></iframe>

5. Шаг 5: Перепроверьте и сравните с прошлым замером

   После правок снова снимите полевые метрики и сравните с исходными. Полевые данные обновляются с задержкой, поэтому оценивайте динамику за несколько дней, а не за минуты.

   https://pagespeed.web.dev/  → поле «Оригинальные данные»

Подводные камни и частые ошибки

• Гнаться только за лабораторным тестом: зелёная сотня в Lighthouse ничего не значит, если полевые метрики реальных пользователей плохие. Смотрите на Chrome UX Report.
• Оптимизировать не те страницы: правки на страницах без трафика не влияют на общую оценку. Начинайте с тех, куда реально приходят люди.
• Откладывать скрипты вслепую: неаккуратный defer или async ломает интерактив и ухудшает INP. Проверяйте каждое изменение.
• Забыть про мобильные: метрики считаются в первую очередь по мобильным устройствам. Тестируйте именно мобильный вариант, а не только десктоп.

Контрольный чек-лист

• [ ] Сняты полевые и лабораторные метрики по ключевым страницам
• [ ] Hero-изображение сжато и переведено в WebP
• [ ] У изображений и iframe заданы размеры
• [ ] Лишний JavaScript отложен или удалён
• [ ] Настроены кэш и сжатие на сервере
• [ ] Проведён повторный замер и сравнение с исходным

Часто задаваемые вопросы

Какие значения Core Web Vitals считаются хорошими?

Официальные пороги Google: LCP не больше 2,5 секунды, INP не больше 200 миллисекунд, CLS не выше 0,1. Значения ниже этих границ считаются хорошими, выше — требуют доработки. Метрики оцениваются по полевым данным реальных пользователей, а не только по лабораторному тесту.

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

Да, но как один из второстепенных сигналов. Google использует их в составе фактора «опыт страницы», поэтому сами по себе метрики не вытащат сайт наверх, но плохие значения могут незаметно тянуть вниз. Релевантность контента остаётся важнее скорости.

Почему в тесте одна скорость, а у пользователей другая?

Лабораторный тест Lighthouse запускается на быстром компьютере с фиксированными условиями, а полевые данные собираются с реальных устройств в разных сетях. Ориентироваться стоит на полевые метрики в отчёте Chrome UX Report, а лабораторный тест использовать для поиска конкретных узких мест.

С чего начать, если все метрики красные?

Начните с LCP: чаще всего это тяжёлое hero-изображение или медленный сервер. Затем займитесь INP, сократив объём JavaScript и тяжёлые обработчики. CLS обычно лечится указанием размеров у изображений и баннеров. Улучшение одной метрики часто подтягивает и остальные.

Вывод

Core Web Vitals — это не разовая акция, а короткий чек-лист: снимите метрики, уберите узкие места по LCP, INP и CLS, перепроверьте полевые данные. Если сайт отдаётся медленно на уровне сервера, поможет материал как не переплатить за VPS. А чтобы раздать статику через быстрый CDN, посмотрите Cloudflare Pages.