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

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

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

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

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

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

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

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

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

Разработка

12 июля 2026

8 мин чтения

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

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

Для бизнеса

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, алерты по ошибкам/метрикам и дисциплина релизов.