Core Web Vitals: что действительно двигает оценку

Три метрики, которые видят пользователи

Core Web Vitals измеряют не технические параметры страницы, а моменты, которые замечает человек. Первая метрика — Largest Contentful Paint (LCP) — фиксирует, когда на экране появляется самый крупный элемент контента. Это может быть заголовок, главная иллюстрация или блок текста. Если этот момент наступает с задержкой, пользователь видит пустую или частично загруженную страницу, что создаёт ощущение медленной работы.

Вторая метрика — Interaction to Next Paint (INP) — оценивает отзывчивость: сколько времени проходит между действием пользователя (клик, нажатие клавиши, скролл) и визуальным изменением на экране. Если страница реагирует с задержкой, пользователь может подумать, что она зависла.

Третья метрика — Cumulative Layout Shift (CLS) — измеряет стабильность вёрстки. Если элементы страницы смещаются во время загрузки (например, текст “прыгает” вниз, когда загружается картинка), это раздражает и мешает взаимодействию.

Почему синтетические тесты не совпадают с реальностью

Инструменты вроде Lighthouse или WebPageTest измеряют страницу в идеальных условиях: быстрый интернет, мощное устройство, отсутствие фоновых процессов. Они полезны для отладки, но не показывают, как страница ведёт себя у реальных пользователей.

В реальных сценариях:

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

Поэтому решающее значение имеют данные живых посетителей. Если синтетические тесты показывают хорошие результаты, но пользователи жалуются на медленную загрузку, проблема может быть в условиях, которые не учитывают лабораторные инструменты.

Как улучшить Largest Contentful Paint: порядок действий

LCP зависит от нескольких факторов, и оптимизировать их нужно последовательно. Если устранить самое узкое место, остальные улучшения дадут меньший эффект.

1. Время ответа сервера

Если сервер долго генерирует или отдаёт HTML, никакие клиентские оптимизации не помогут. Здесь важно:

• Уменьшить время генерации страницы на сервере (например, оптимизировать запросы к базе данных).
• Использовать кеширование, чтобы повторные запросы отдавались быстрее.
• Разместить сервер ближе к пользователям с помощью CDN или edge-сетей.

2. Размер и формат главной иллюстрации

Если самая крупная картинка на странице имеет большой размер, её загрузка может занимать значительную часть времени LCP. Оптимальные подходы:

• Использовать современные форматы сжатия (например, WebP или AVIF), которые обеспечивают лучшее соотношение качества и размера по сравнению с JPEG или PNG.
• Отдавать разные версии картинки в зависимости от размера экрана устройства.
• Задавать размеры картинки через атрибуты width и height, чтобы браузер заранее знал, сколько места она займёт.
• Применять ленивую загрузку для картинок, которые не видны сразу при открытии страницы.

3. Загрузка шрифтов

Если браузер ждёт загрузки кастомного шрифта, чтобы отрисовать текст, LCP задерживается. Решения:

• Использовать font-display: swap, чтобы сначала показывать текст системным шрифтом, а потом подменять его на кастомный.
• Предзагружать шрифты с помощью <link rel="preload">, чтобы они начинали загружаться раньше других ресурсов.

Как улучшить Interaction to Next Paint: основные причины задержек

INP страдает, когда главный поток браузера занят тяжёлыми задачами. Основные источники проблем:

1. Длинные задачи в главном потоке

Если JavaScript выполняет сложную операцию (например, парсинг большого JSON или рендеринг сложного интерфейса), браузер не может обработать пользовательский ввод. Решения:

• Разбивать задачи на части с помощью setTimeout или requestIdleCallback.
• Выносить тяжёлые вычисления в Web Workers, чтобы они не блокировали главный поток.

2. Сторонние скрипты

Рекламные блоки, аналитика, виджеты соцсетей могут блокировать главный поток. Их нужно:

• Загружать асинхронно с помощью async или defer.
• Откладывать загрузку до момента, когда они действительно нужны пользователю.

3. Перегруженные обработчики событий

Если обработчик клика одновременно обновляет DOM, делает запрос к API и запускает анимацию, браузер не успевает обработать другие действия. Решения:

• Разделять логику на несколько этапов.
• Использовать requestAnimationFrame для анимаций, чтобы они не блокировали главный поток.

Как улучшить Cumulative Layout Shift: предотвращение смещений

CLS возникает, когда элементы страницы смещаются во время загрузки. Основные причины и решения:

1. Незарезервированное место под медиа и рекламу

Если браузер не знает заранее размеры элемента, он сначала отрисовывает страницу без него, а потом сдвигает контент, когда элемент загрузится. Решения:

• Задавать размеры через атрибуты width и height.
• Использовать CSS-свойство aspect-ratio для элементов с неизвестными размерами.

2. Загрузка шрифтов

Если шрифт загружается позже основного контента, текст может “прыгать” при смене шрифта. Решения:

• Предзагружать шрифты.
• Использовать font-display: optional, чтобы браузер не ждал загрузки шрифта, если она занимает слишком много времени.

3. Динамические вставки контента

Баннеры, уведомления или реклама, которые появляются после загрузки страницы, могут сдвигать контент. Решения:

• Резервировать место заранее.
• Загружать такие элементы после основного контента.

Как измерять реальную производительность

Синтетические тесты полезны для отладки, но они не показывают полной картины. Чтобы понять, как страница ведёт себя в реальных условиях, нужно:

1. Собирать данные живых посетителей. Инструменты аналитики показывают, как страница работает для реальных пользователей. Если значительная часть из них сталкивается с медленной загрузкой, проблема требует внимания.
2. Сравнивать лабораторные и полевые данные. Если синтетические тесты показывают хорошие результаты, но реальные данные плохие, проблема может быть в условиях, которые не учитывают лабораторные инструменты (например, слабые устройства или медленное соединение).
3. Оптимизировать под реальные сценарии. Если большинство пользователей заходят с мобильных устройств, нужно тестировать на мобильных сетях и слабых процессорах.

Тупик: оптимизация ради оценки

Частая ошибка — гоняться за хорошими показателями в синтетических тестах, не понимая, что именно влияет на метрики. Например, можно уменьшить размер картинки до минимума, но если сервер отвечает медленно, LCP всё равно будет плохим.

Что делать вместо этого:

1. Определить реальные узкие места. Если LCP плохой, нужно понять, что именно задерживает отрисовку — сервер, картинка или шрифт.
2. Фокусироваться на том, что важно для пользователей. Если большинство посетителей заходят с мобильных устройств, оптимизировать нужно под них, а не под десктопные условия.
3. Не жертвовать функциональностью ради метрик. Например, можно убрать все шрифты, чтобы ускорить загрузку, но если текст станет нечитаемым, пользователи уйдут.

Позиция редакции

Core Web Vitals — это инструмент для улучшения пользовательского опыта, а не самоцель. Они помогают выявить слабые места страницы, но не заменяют здравый смысл. Если оптимизация метрик приводит к ухудшению других аспектов страницы (например, убирает важный контент или делает её неудобной), она не нужна.

Когда позиция неверна:

• Если метрики становятся главной целью, а не средством для улучшения пользовательского опыта. Например, когда команда фокусируется на достижении зелёных показателей, игнорируя реальные проблемы пользователей.
• Если оптимизация под метрики приводит к ухудшению доступности, функциональности или конверсии страницы. Например, если ради уменьшения CLS убираются важные элементы, которые появляются после загрузки, но нужны пользователям.