Core Web Vitals: пороги и что измерять

Core Web Vitals. По сути это про три вещи: как быстро появляется главное, как отзывается нажатие, не прыгает ли текст.

Три метрики Google, по которым я смотрю "живость" сайта после оптимизаций. Ниже - пороги "хорошо" для полевых данных (p75) и то, что чаще всего ломает цифры на практике.

LCP (Largest Contentful Paint)

• Хорошо: ≤ 2,5 с; нужно улучшить: 2,5-4 с; плохо: > 4 с.
• Частая причина: тяжёлый hero-баннер, медленный TTFB, блокирующий JS до отрисовки.
• Действия: WebP/AVIF, responsive images, preload критичного шрифта, кэш CDN, серверная отдача HTML быстрее 200 мс до региона ЦА.

INP (Interaction to Next Paint)

• Хорошо: ≤ 200 мс; нужно улучшить: 200-500 мс; плохо: > 500 мс.
• Заменил FID: смотрит не первый клик, а отзывчивость UI в целом.
• Частые причины: длинные задачи в main thread, тяжёлые бандлы React без code splitting, синхронные обработчики на input.

CLS (Cumulative Layout Shift)

• Хорошо: ≤ 0,1; нужно улучшить: 0,1-0,25; плохо: > 0,25.
• Частые причины: баннеры/виджеты без резерва высоты, веб-шрифты без font-display: swap + fallback метрик, lazy-load без плейсхолдера.

Где смотреть

• Chrome DevTools → Lighthouse (лаборатория, не поле).
• Search Console → отчёт "Core Web Vitals" (поле по реальным пользователям Chrome).
• PageSpeed Insights - агрегирует lab + частично поле.

Что прописать в ТЗ

• Целевые p75: LCP / INP / CLS + инструмент приёмки (URL отчёта Lighthouse CI или порог в PSI).
• Ограничение на сторонние скрипты (реклама, чаты) - они чаще всего убивают INP.

Зачем Google вообще смотрит на скорость — простыми словами

Поисковик хочет, чтобы люди не уходили злыми: слишком долго грузится, всё прыгает при чтении, кнопка не срабатывает с первого раза. Это не «кара», а здравый смысл: быстрый удобный сайт чаще оставляет деньги у вас, а не у конкурента.

Когда главная картинка грузится вечность

Часто виновато большое фото на всю ширину без облегчённой версии для телефона. Плюс тяжёлые шрифты и отсутствие нормального кеширования на сервере. Цель простая: полезный текст и картинка появляются быстро, а не красивый крутильщик «подождите».

Когда страница «дёргается» при прокрутке

• Сверху внезапно вылезает баннер — и вы промахиваетесь мимо кнопки.
• Шрифт сменился, и блоки перескочили.
• Снизу подгрузился блок и сдвинул то, на что вы уже целились нажать.

Когда кнопка ведёт себя «как хочет»

Если на сайте много тяжёлого JavaScript, телефон может не успевать обрабатывать нажатия. В итоге кажется, что «сайт глючит». Лечится упрощением первого экрана и отложенной загрузкой лишнего.

Код: шрифты без скачка CLS

Указываю font-display: swap и fallback с близкими метриками.

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-var.woff2") format("woff2");
  font-display: swap;
  font-weight: 100 900;
}

Код: размеры у картинок

Атрибуты width и height резервируют место до загрузки.

<img
  src="/images/hero.webp"
  alt="Услуги"
  width="1200"
  height="630"
  loading="eager"
  fetchpriority="high"
>

Код: preload LCP-ресурса

<link rel="preload" href="/images/hero.webp" as="image" type="image/webp">

Core Web Vitals: пороги и что измерять — не абстрактная «оптимизация ради галочки», а влияние на заявки: медленная страница режет конверсию сильнее, чем спорный оттенок кнопки. Разберём, что проверять в первую очередь.

Чеклист перед релизом

• LCP: тяжёлый hero сжат (WebP/AVIF), критичный шрифт не блокирует отрисовку.
• CLS: у картинок и embed заданы width/height или aspect-ratio.
• INP: нет тяжёлых синхронных обработчиков на каждый input.
• JS: code splitting, без лишних UI-kit на весь сайт.
• Третьи стороны: метрика и чаты — после load или по согласию.

Гонитесь за метрикой в контексте устройства ЦА, а не только за зелёным Lighthouse на MacBook.

Типичные ошибки

Перегруз эффектами и библиотеками «на всякий случай»; отсутствие проверки на слабом интернете и старых телефонах; копирование чужого дизайна без адаптации под свою аудиторию; отсутствие явного CTA; ожидание, что «сайт сам продаст» без трафика и оффера.

Для коммерческих проектов отдельно болит размытое ТЗ и бесконечные правки без доплаты — лечится этапами и лимитом итераций.

Когда имеет смысл привлечь разработчика

Если нужен не шаблон, а связка дизайна, скорости, интеграций и сопровождения — проще обсудить задачу один раз, чем чинить конструктор полгода. Я беру лендинги, визитки и MVP под ключ; ориентиры по срокам и бюджету — на странице цен.

Короткие ответы на частые вопросы

Сколько времени займёт? Лендинг — 1 день при готовых материалах, до 1–2 дней с нуля; визитка — 2–5 дней; магазин и интеграции — от нескольких дней до ~2 недель. Точнее после брифа.

Нужен ли дизайн в Figma? Не всегда: для MVP и многих лендингов достаточно согласованной структуры блоков и референсов; для бренда с уникальной айдентикой — да.

Кто владеет кодом? Обычно заказчик после оплаты; фиксируем в договоре или переписке. Подробнее — в статье про права на сайт.

Что по поддержке? После запуска можно договориться на пакет правок или почасовую помощь — отдельно от разработки.

Итог

Тема «Core Web Vitals: пороги и что измерять» сводится к дисциплине: меньше случайных решений, больше проверки на реальных устройствах и честный scope. Если хотите разобрать ваш кейс — напишите в Telegram, скину вопросы для брифа без обязательства заказывать.

Читать дальше

• Core Web Vitals — метрики скорости
• Vite вместо CRA — стек сборки
• Услуги — разработка под задачу