Core Web Vitals: LCP, INP и CLS

Команда тратит два спринта на оптимизацию API. Server P99 падает с 400 мс до 90 мс. Google Search Console показывает: LCP «Poor» у 40% мобильных пользователей. API не был узким местом. 800 КБ JS-bundle, блокирующий main thread, — был.

Три метрики и что они меряют

Core Web Vitals от Google — три field-метрики, собираемые от реальных Chrome-пользователей через датасет CrUX, — измеряют разные аспекты пользовательского опыта.

LCP (Largest Contentful Paint) — время от начала навигации до рендера самого большого видимого элемента above the fold. Обычно hero image, H1 или фоновый блок. Target: менее 2,5 с — «Good»; 2,5-4,0 с — «Needs Improvement»; более 4,0 с — «Poor». Тяжёлый JS, блокирующий main thread, задерживает момент рисования — LCP страдает напрямую.

INP (Interaction to Next Paint) — введён в марте 2024, заменил FID. INP измеряет worst-case latency от любого пользовательского ввода (клик, нажатие, тап) до следующего visual update за всё время жизни страницы. Target: менее 200 мс — «Good»; 200-500 мс — «Needs Improvement»; более 500 мс — «Poor». Долгие JS-задачи на main thread — включая parse и execute большого bundle — поднимают INP.

CLS (Cumulative Layout Shift) — насколько видимый контент непредвиденно сдвигается при загрузке. Target: менее 0,1 — «Good»; 0,1-0,25 — «Needs Improvement»; более 0,25 — «Poor». Размер bundle не вызывает CLS напрямую; layout shifts возникают из-за картинок без размеров, поздней загрузки шрифтов и JS, вставляющего above-fold контент после initial paint.

Правило 100-170 КБ

Рекомендации Google Web Fundamentals: держи initial JS под 100-170 КБ gzip’d для fast first interactive на mid-range mobile. Математика: 170 КБ gzip’d разжимается примерно в 500 КБ. V8 парсит 200-400 КБ/сек на mid-range Android, значит parse занимает 1,5 с. Добавь compile и execute — итого 2-2,5 с CPU. Добавь 4G download ~500 мс — получается около 3 с до interactive. Это верхняя граница, удерживающая LCP под 2,5 с. Каждые дополнительные 100 КБ сверх неё добавляют примерно 300-500 мс к LCP на median устройстве.

Разные routes могут нести разные бюджеты: marketing homepage — жёстко (50-100 КБ), dashboard — средне (150-250 КБ), admin tools — мягче (300-500 КБ). Homepage несёт самый жёсткий cap, потому что это точка входа для конверсии.

Три инструмента: Lighthouse, PageSpeed Insights, RUM

Эти инструменты измеряют одни метрики, но с разных точек зрения.

Lighthouse запускает синтетический тест — DevTools или CLI — с CPU throttling. Надёжен для поимки регрессий в PR. Не field-данные; один синтетический запуск.

PageSpeed Insights — Google-managed Lighthouse плюс field-данные из CrUX-датасета (реальные агрегированные метрики от Chrome-пользователей на твоём домене). Полезен для public-facing анализа. Обновляется раз в день.

Real User Monitoring (RUM) — собственная выборка реальных юзеров через Web Vitals JS library, Sentry, Datadog RUM и подобные. Самый точный, но требует setup и бюджет. Senior pattern: Lighthouse в CI для поимки регрессий перед мержем; RUM в production для регрессий, которые CI пропустил; PageSpeed Insights ежеквартально для cross-reference.