Главная · Frontend
Frontend

Как измерять производительность фронтенда: Core Web Vitals на практике.

3DH.su3DH.su 7 июня 2026 5 мин чтения
Как измерять производительность фронтенда: Core Web Vitals на практике.

Когда мы говорим о «быстром сайте», новички обычно имеют в виду время загрузки страницы (Load time). Но для опытного фронтенд-разработчика это понятие слишком размыто. Пользователю плевать, что ваш HTML прилетел за 200 мс, если страница «прыгает» при загрузке или кнопка «Купить» не реагирует на нажатие еще две секунды из-за тяжелого JS-бандла.

Google решил эту проблему, внедрив Core Web Vitals (CWV). Это не просто набор метрик для SEO, а попытка оцифровать пользовательский опыт (UX). В этой статье мы разберем, что это за метрики, как их реально измерять и где искать «бутылочное горлышко» в вашем коде.

Что такое Core Web Vitals и почему они важны?

Core Web Vitals — это три ключевых показателя, которые оценивают три разных аспекта взаимодействия с сайтом: скорость отрисовки основного контента, стабильность верстки и скорость отклика интерфейса.

Если ваши показатели в «зеленой зоне», Google ранжирует сайт выше. Но важнее другое: высокая производительность напрямую коррелирует с конверсией. Каждый лишний шанс, что пользователь закроет вкладку из-за тормозов, — это потерянные деньги бизнеса.

Рассмотрим каждую метрику подробно.

1. Largest Contentful Paint (LCP): Скорость отрисовки

LCP измеряет время, за которое самый большой видимый элемент (обычно это главный баннер, изображение или большой блок текста) полностью отрисовывается на экране.

Что считается «хорошим» результатом?

    • Хорошо: до 2.5 секунд.
    • Нужно улучшить: от 2.5 до 4 секунд.
    • Плохо: более 4 секунд.

Как оптимизировать LCP на практике?

Чаще всего LCP «тормозит» из-за тяжелых изображений или медленного ответа сервера. Вот что нужно проверить в первую очередь:

  1. Оптимизация ресурсов. Используйте современные форматы (WebP, AVIF) и адаптивные изображения через srcset.
  2. Приоритезация загрузки. Для главного изображения (LCP-элемента) используйте атрибут fetchpriority="high". Это скажет браузеру, что этот файл важнее остальных.
  3. Устранение блокирующего рендеринга. Минифицируйте CSS и выносите критический CSS (Critical CSS) в <head>, чтобы браузер не ждал загрузки огромного файла стилей, прежде чем начать рисовать страницу.
  4. Кеширование и CDN. Если ваш сервер отвечает 500 мс (TTFB), никакой фронтенд не спасет ситуацию. Используйте CDN, чтобы доставить статику максимально близко к пользователю.

2. Cumulative Layout Shift (CLS): Визуальная стабильность

Вы наверняка сталкивались с этим: хотите нажать на ссылку, но в этот момент сверху подгружается рекламный баннер, контент прыгает вниз, и вы кликаете совсем не туда. Это и есть плохой CLS.

Что считается «хорошим» результатом?

    • Хорошо: менее 0.1.
    • Нужно улучшить: от 0.1 до 0.25.
    • Плохо: более 0.25.

Как бороться с «прыжками» контента?

CLS — это не про скорость, а про геометрию. Чтобы верстка не «гуляла», следуйте этим правилам:

  1. Резервируйте место под изображения и видео. Всегда указывайте атрибуты width и height или используйте CSS-свойство aspect-ratio. Браузер заранее зарезервирует место, и контент не сдвинется при загрузке картинки.
  2. Осторожнее с динамическим контентом. Если вы вставляете рекламный блок или уведомление сверху страницы, делайте это в фиксированном контейнере с заданной высотой.
  3. Шрифты и FOIT/FOUT. Замена системного шрифта на кастомный часто вызывает скачок текста. Используйте font-display: swap;, чтобы текст был виден сразу, а затем плавно заменился на красивый шрифт.

3. Interaction to Next Paint (INP): Отклик интерфейса

Раньше была метрика FID (First Input Delay), но с марта 2024 года ее заменил INP. Если FID измерял только первое взаимодействие, то INP оценивает общую отзывчивость страницы на протяжении всего сеанса.

Что считается «хорошим» результатом?

    • Хорошо: до 200 мс.
    • Нужно улучшить: от 200 до 500 мс.
    • Плохо: более 500 мс.

Почему интерфейс «тупит» и как это исправить?

Основная причина плохого INP — перегруженный основной поток (Main Thread). JavaScript однопоточен: пока выполняется тяжелый скрипт, браузер не может обработать клик или скролл.

Стратегии оптимизации:

  1. Разбиение тяжелых задач. Если у вас есть функция, которая обрабатывает массив на 10 000 элементов, не делайте это одним куском. Используйте setTimeout или requestIdleCallback, чтобы разбить задачу на части и дать браузеру «вдохнуть».
  2. Оптимизация JS-бандла. Удаляйте неиспользуемый код (Tree Shaking) и используйте динамический импорт import(), чтобы загружать код только тогда, когда он действительно нужен.
  3. Web Workers. Переносите сложные вычисления в отдельные потоки (Web Workers), чтобы они не блокировали UI.

Инструментарий: где и как измерять?

Измерение производительности делится на два типа: лабораторные данные (синтетика) и полевые данные (реальные пользователи).

Лабораторные инструменты (для разработки)

Это инструменты, которые имитируют условия. Они полезны для отладки, но не показывают всей картины.

    • Lighthouse (Chrome DevTools): Быстрый способ получить общий отчет. Но помните: Lighthouse запускается в «стерильных» условиях с быстрым интернетом.
    • PageSpeed Insights: Комбинирует данные Lighthouse и реальные данные из Chrome User Experience Report (CrUX).
    • Web Vitals Extension: Расширение для Chrome, которое показывает метрики в реальном времени прямо в браузере.

Полевые данные (Real User Monitoring — RUM)

Это данные от реальных людей с разными смартфонами, плохим 3G и старыми версиями браузеров.

    • Google Search Console: Показывает, какие страницы вашего сайта имеют проблемы с CWV с точки зрения Google.
    • Кастомный мониторинг: Использование библиотеки web-vitals от Google для отправки метрик в вашу систему аналитики. Это единственный способ узнать, что у пользователей из определенного региона сайт тормозит из-за специфического API.

Практический план оптимизации (Чек-лист)

Если вы только начинаете заниматься производительностью, не пытайтесь исправить всё сразу. Идите по этому списку:

  1. Анализ. Запустите PageSpeed Insights и найдите самую слабую метрику.
  2. LCP Fix: Проверьте размер главного изображения $\rightarrow$ Сжатие $\rightarrow$ fetchpriority="high".
  3. CLS Fix: Проверьте все картинки и рекламные блоки $\rightarrow$ Добавьте aspect-ratio.
  4. INP Fix: Найдите «тяжелые» скрипты через вкладку Performance в DevTools $\rightarrow$ Разбейте длинные задачи (Long Tasks).
  5. Верификация. Снова замерьте показатели и сравните с предыдущими результатами.

Заключение

Core Web Vitals — это не просто гонка за «зелеными кружками» в Lighthouse. Это инструмент, который заставляет разработчика думать о пользователе. Скорость — это часть UX.

Помните, что идеальных показателей не бывает. Ваша цель — не достичь 100 баллов, а сделать так, чтобы пользователь не чувствовал дискомфорта. Начните с малого: оптимизируйте LCP, уберите прыжки верстки, и вы увидите, как растет и конверсия, и лояльность аудитории.