Оптимизация скорости сайта: Core Web Vitals (LCP/INP/CLS)

Разработка

12 июля 2026

8 мин чтения

Runbook по ускорению сайта: как измерять CWV, находить причины LCP/INP/CLS, исправлять по приоритетам, план quick wins/2 дня/30–60–90 и чек-лист релиза.

Для бизнеса

Core Web Vitals = реальный UX, который влияет на лиды/продажи через удобство, и косвенно — на SEO через качество страницы.
Улучшения чаще всего дают эффект в трёх местах: TTFB (сервер), самый тяжёлый элемент первого экрана (LCP), тяжёлый JS и виджеты (INP).
Что реально сделать быстро:
- за 2 часа: отключить/отложить тяжёлые виджеты, оптимизировать hero-изображение, включить сжатие/кеш.
- за 2 дня: разгрести критический путь CSS/JS, настроить CDN/edge-cache, привести изображения к нормальным размерам/форматам.
- за 2 недели: код-сплиттинг, performance budget, регресс-контроль, стабильный релизный процесс.

Для разработчиков

Работайте по схеме: Field data (CrUX/Search Console) → root cause → фиксы по LCP/INP/CLS → регресс-контроль.
Не оптимизируйте «скор» Lighthouse вслепую: приоритет — 75-й перцентиль полевых данных и проблемные шаблоны страниц.
Почти всегда «выигрышные» направления:
- TTFB + кеши/CDN
- render-blocking CSS/JS + critical CSS
- JS-бандл + long tasks + third-party
- hero-media + приоритет загрузки

Для контент-редакторов

Скорость чаще всего ломают: огромные изображения, видео/встраивания в первом экране, баннеры, которые «прыгают», тяжёлые шрифты.
Правило публикации:
не ставить «оригинал 4000px» в первый экран;
указывать размеры медиа (или использовать компоненты, которые это делают);
не добавлять новые виджеты без проверки INP/CLS.

Правило № 1: сначала измеряем правильно

Field data vs Lab data — что это и почему нужны оба

Field data — реальные пользователи (CrUX/PSI/Search Console), исторические данные за период (обычно «скользящее окно» ~28 дней). Это то, что «чувствуют» люди.
Lab data — синтетика (Lighthouse/DevTools/WebPageTest): удобно для дебага причин, но не всегда отражает реальные устройства/сети.

Где смотреть (чек-лист инструментов)

Search Console → Core Web Vitals: группирует URL по типам проблем и «плохой метрике».
PageSpeed Insights: показывает field + lab, 75-й перцентиль и распределение.
Lighthouse (локально/CI) — диагностика критического пути.
Chrome DevTools Performance — long tasks, layout shifts, waterfall.
WebPageTest — детальный waterfall, TTFB, CDN, кеши.

Принципы, без которых вы «чините не то»

Мобильный приоритет: основная боль обычно там.
75-й перцентиль: CWV оценивают «плохой хвост», а не среднее.
Сегментация по шаблонам: лечите не «страницу /about», а тип «карточка», «каталог», «статья», «поиск», «лендинг».

Пороговые значения Core Web Vitals

Пороговые значения (Good / Needs Improvement / Poor) публикуются в официальной документации инструментов и могут обновляться — перед публикацией проверьте актуальные thresholds в документации Google/web.dev.

Ориентиры (как в PageSpeed Insights):

LCP: Good ≤ 2.5s; NI 2.5–4.0s; Poor > 4.0s
CLS: Good ≤ 0.1; NI 0.1–0.25; Poor > 0.25
INP: Good ≤ 200ms; NI 200–500ms; Poor > 500ms

Важные детали:

Field-оценка берётся по 75-му перцентилю.
Отчёты по real-user данным обычно отражают скользящий период и не «вылечиваются мгновенно» после релиза.

Runbook: сделайте это по порядку (алгоритм 10 шагов)

Соберите baseline по field data

Какие группы URL в Search Console «Poor/NI» и по какой метрике.

Выберите 3–5 репрезентативных страниц на каждый проблемный шаблон

Пример: «статья», «карточка товара», «категория», «лендинг».

Соберите lab-профили

Lighthouse + DevTools Performance для каждой репрезентативной страницы.

Определите главного «виновника»

LCP? INP? CLS?
Не лечите всё сразу — сначала самая «плохая» метрика на самых трафиковых шаблонах.

Разложите причины по слоям

Сервер/TTFB → критический путь CSS/JS → медиа → third-party.

Сделайте quick wins (1 релиз)

Кеш/сжатие, hero-изображение, отложенная загрузка виджетов.

Среднесрочные изменения (2–3 релиза)

code splitting, устранение render-blocking, preload/preconnect, оптимизация шрифтов.

Стратегические изменения (если нужно)

SSR/SSG, переработка шаблонов, дизайн-система, пересборка «тяжёлых» страниц.

Перепроверка: lab + field

Lab покажет эффект сразу. Field обновится по мере накопления данных (и может запаздывать).

Закрепите регресс-контроль

Performance budget + проверка в CI + «no new third-party without review».

Диагностика: таблицы-справочники LCP / INP / CLS

A) LCP — «грузится долго первый экран»

Симптом	Вероятная причина	Как проверить	Что сделать	Как подтвердить
LCP > порога на мобайле	высокий TTFB	waterfall (WPT/DevTools), server timing	CDN/edge cache, full-page cache, оптимизация бэкенда	TTFB упал, LCP стабильно ниже
LCP «зависает» до загрузки CSS	render-blocking CSS	Lighthouse: «Eliminate render-blocking resources»	critical CSS, разделить CSS, preload critical	LCP/TTI улучшаются, меньше blocking time
LCP ждёт JS	render-blocking JS / hydration	DevTools Performance: main thread busy	defer/async, splitting, SSR/partial hydration	LCP наступает раньше, меньше long tasks
LCP = hero-картинка и она тяжёлая	большой размер/не тот формат	network: размер/формат	AVIF/WebP, правильные размеры, srcset, preload/priority	hero грузится быстрее, LCP падает
LCP «плавает»	кеш не работает	response headers, cache-hit/miss	настроить кеши, vary/ETag, CDN	LCP стабильнее, меньше variance
LCP ломают шрифты	блокирующие webfonts	waterfall: font blocking	preload fonts, font-display, subset	меньше блокировок, быстрее first render
LCP хуже после добавления виджета	third-party блокирует	отключить → сравнить	delayed/conditional load, заменить виджет	LCP возвращается к baseline

B) INP — «кликаю, а сайт тормозит»

Симптом	Причина	Проверка	Фиксы	Подтверждение
INP плохой на всех страницах	long tasks на main thread	DevTools Performance: long tasks	splitting, убрать тяжёлые синхронные скрипты	меньше long tasks, INP падает
INP плохой на конкретном сценарии	тяжёлый обработчик события	Performance + Event log	debounce/throttle, оптимизация обработчика	interaction latency снижается
«подвисает» при открытии меню/фильтров	re-render/layout thrashing	Performance: layout recalcs	мемоизация, виртуализация списков	плавность, меньше layout
INP ухудшился после чата/аналитики	third-party	отключить → сравнить	conditional load (после consent/scroll), self-host	INP нормализуется
INP плохой в SPA	тяжёлый hydration/JS bundle	Coverage/Bundle analyzer	code splitting, SSR/partial hydration	меньше JS, быстрее интерактив
INP плохой на слабых девайсах	слишком много JS	CrUX/field сегменты, lab throttling	performance budget, удалить лишнее	улучшение у «хвоста»

C) CLS — «всё прыгает»

Симптом	Причина	Проверка	Фиксы	Подтверждение
CLS скачет при загрузке картинок	нет размеров	DevTools: layout shifts	width/height, aspect-ratio, placeholders	CLS падает
CLS при загрузке шрифтов	FOIT/FOUT	waterfall, font swap	font-display: swap/optional, preload, fallback	меньше shift при смене шрифта
CLS от баннеров/виджетов	вставка «сверху» без места	shift sources	резервировать место, sticky без reflow	CLS стабилен
CLS от поздних блоков выше фолда	lazy-load «не там»	shift sources	не lazy-load above-the-fold, skeleton	CLS падает
CLS при открытии модалок	скроллбар/overflow	воспроизведение	компенсировать scrollbar, fixed layout	CLS/визуальные скачки уходят

Кейс, как мы разработали и оптимизировали сайт для привлечения туристов на Урал за счёт улучшения визуальной привлекательности, удобства навигации и адаптации под мобильные устройства

Реальные шаги по слоям (чек-листы)

Сервер/инфраструктура (TTFB, кеши, CDN)

Чек-лист:

Включить/проверить Brotli/Gzip, корректные cache headers.
Настроить CDN/edge caching для статики и (по возможности) HTML.
Full-page cache / microcache для контентных страниц.
Уменьшить TTFB: оптимизировать бэкенд, DB-запросы, сторонние API.
Проверить keep-alive, HTTP/2/3 (где релевантно).
Понять cache-hit/miss по заголовкам и логам.

Типичный эффект: улучшение LCP за счёт снижения TTFB, стабильность.

Риски: неправильный кеш может показывать не тот контент (учесть vary, персонализацию).

Фронтенд critical path (CSS/JS/рендер)

Чек-лист:

Убрать render-blocking: critical CSS, defer/async для JS.
Code splitting по маршрутам/компонентам; tree-shaking.
preload/preconnect для критических ресурсов (fonts, hero, API).
Ограничить «первый экран»: меньше CSS/JS и меньше DOM.
Если SEO важно — рассмотреть SSR/SSG (архитектура важнее фреймворка).

Типичный эффект: LCP/INP улучшаются одновременно.

Риски: сломать порядок стилей/FOUC, нужна аккуратная регресс-проверка.

Медиа и контент (изображения/видео)

Чек-лист:

Перевести изображения в WebP/AVIF, правильные размеры.
Использовать srcset/sizes и не отдавать десктоп-размер на мобайл.
Не делать lazy-load для hero (LCP-элемент). Для hero — preload/priority.
Видео: постер + загрузка по клику; не тащить тяжёлый плеер в 1 экране.
В админке/гайде редактора: ограничения по размеру и «готовые пресеты».

Типичный эффект: быстрый выигрыш по LCP и общей скорости.

Риски: «пережатие» до мыла может ухудшить конверсию — держите баланс.

Third-party скрипты и виджеты

Чек-лист:

Инвентаризация: что грузится, вес, какие события/блокировки создаёт.
Отложенная загрузка (после согласия, after interaction, after scroll).
Conditional loading: грузить только там, где реально нужно.
По возможности — заменить тяжёлые виджеты на лёгкие или self-host.
Ввести performance budget: нельзя добавлять новый third-party без ревью.

Типичный эффект: сильное улучшение INP, иногда CLS и LCP.

Риски: потерять часть функционала/аналитики — согласовать с маркетингом.

План внедрения

Сделать за 2 часа (quick wins)

Отключить/отложить самые тяжёлые third-party (чат/виджеты) и сравнить INP/LCP.
Оптимизировать hero-изображение (формат, размер, приоритет).
Включить Brotli/Gzip и базовые cache headers.
Указать размеры изображений/видео, чтобы убрать CLS на ключевых шаблонах.
Убрать очевидные render-blocking ресурсы (минимум: defer для не-критичного JS).

Сделать за 2 дня (реальный «спринт ускорения»)

Сегментировать страницы по шаблонам и выбрать топ-2 по трафику/проблемам.
Настроить CDN для статики + кеширование HTML (где возможно).
Critical CSS для первого экрана; разделить CSS по страницам.
Code splitting по маршрутам; убрать «всё в один бандл».
Шрифты: preload + font-display + subset.
Перевести медиа на responsive (srcset) и нормальные размеры.
Условная загрузка third-party (consent/scroll) и аудит каждого.
Повторить lab-измерения и зафиксировать baseline.

План 30 / 60 / 90 дней

30 дней (стабилизация):

performance budget (LCP/INP/CLS + вес бандла)
проверки в CI (Lighthouse/скрипты)
регресс-чек-лист релиза
гайд для контент-редакторов по медиа и встраиваниям

60 дней (архитектура):

SSR/SSG где SEO критично
рефакторинг тяжёлых сценариев (INP)
оптимизация критических страниц под мобильный UX
наблюдаемость: ошибки/метрики/алерты

90 дней (операционная зрелость):

регулярный performance-review релизов
контроль third-party как отдельный процесс
плановая оптимизация шаблонов и компонентов
поддержка и стабильность (в т.ч. SLA-контур при необходимости)

Антипаттерны (что НЕ делать)

Гнаться за «100/100 Lighthouse», игнорируя field data.
Оптимизировать всё сразу без приоритизации по шаблонам и метрикам.
Включать lazy-load для hero-элемента и ухудшать LCP.
Добавлять виджеты «по просьбе» без ревью INP/CLS.
Лечить CLS «на глаз», не используя layout shift debug.
Убирать аналитику полностью ради скорости (нужно оптимизировать, а не отключать без плана).
Оптимизировать только десктоп — а проседать на мобайле.
Держать огромные изображения «на всякий случай» в первом экране.
Игнорировать кеш-инвалидацию (получить баги «показывает старое»).
Делать «перф-рефакторинг» без регресс-контроля и отката.

Чек-лист «готовность к релизу»

Есть performance budget (LCP/INP/CLS + вес JS/CSS).
Прогнаны проверки на 3–5 ключевых шаблонах страниц.
Проверено, что hero-элемент не попал под lazy-load.
Изображения/видео имеют размеры/аспект и не создают CLS.
Нет новых third-party без ревью (и есть план conditional load).
Проверены кеши: cache-hit/miss, корректные заголовки, vary.
Проверена деградация на мобайле (throttling).
Проверены long tasks и main thread блокировки на ключевых сценариях.
Ошибки фронта (error tracking) включены и мониторятся.
Есть план отката/feature flags для рисковых изменений.
После релиза — повторные измерения и фиксация результата.
(Если есть SEO-риск) проверены sitemap/robots/редиректы на затронутых страницах.
Контент-команда получила правила публикации медиа/встраиваний.

Красные флаги: когда нужен профессиональный аудит

Высокий TTFB на всех страницах — похоже на инфраструктуру/бэкенд.
INP плохой из-за тяжёлой SPA/hydration и «JS-комбайна».
CLS нестабилен из-за баннеров/рекламы/встраиваемых блоков.
Сайт «ускорили», но после каждого релиза скорость снова падает (нет регресс-контроля).
Много легаси и непонятно, что реально грузится (нужна инвентаризация).
Нет событий аналитики → вы не можете измерить эффект.
Конверсия падает при каждой «оптимизации» → проблемы с UX/контентом/компромиссами.
Команда боится трогать кеши/SSR/релизы — нет безопасного процесса изменений.

Если коротко: ускорение — это не «подкрутить Lighthouse», а поставить процесс: полевые данные → причины → приоритизированные фиксы → регресс-контроль → мониторинг.

FAQ

1. Почему PageSpeed показывает одно, а “в реальности” другое?

Потому что lab-данные — симуляция, а field-данные — реальные пользователи за период. Нужно смотреть оба: lab для причин, field для результата.

2. Что важнее: LCP или INP?

Зависит от типа сайта. Контент и лендинги чаще упираются в LCP/CLS, интерфейсы/кабинеты — в INP. Практически: начните с метрики, по которой вы “Poor” на трафиковых шаблонах.

3. Как быстро обновятся CWV в Search Console?

Field-данные накапливаются и отражают скользящий период, поэтому эффект не всегда виден “завтра”. Сначала фиксируйте lab-прирост, затем ждите подтверждение в field.

4. Можно ли улучшить CWV без переписывания сайта?

Часто — да: кеши, медиа, критический путь, third-party, code splitting дают заметный эффект без “переписывания”.

5. Как влияет хостинг/сервер?

Через TTFB и стабильность. Если сервер отвечает медленно или кеши не работают — LCP почти всегда страдает.

6. Как не сломать SEO при оптимизации?

Не меняйте URL/структуру без плана, не блокируйте нужные ресурсы, контролируйте рендеринг (особенно при SSR/SSG), и проверяйте индексацию после релизов.

7. Как контролировать скорость постоянно?

Performance budget в CI, регулярные отчёты, контроль third-party, алерты по ошибкам/метрикам и дисциплина релизов.