Объяснение Core Web Vitals для инженеров

Что обычно считается элементом LCP

В качестве кандидатов в LCP обычно выбираются:

• Блочные текстовые элементы: <h1>, <h2>, <p> и др.
• Изображения: <img>, фоновые изображения на блочных элементах, постеры в <video>.
• Блочные контейнеры с фоновыми изображениями.

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

Как стратегия рендеринга влияет на LCP

Стратегия рендеринга существенно влияет на то, как быстро появляется элемент LCP:

• Традиционный CSR (Client-Side Rendering): Браузер получает в основном пустую HTML-оболочку, загружает JS, парсит, компилирует и выполняет его для получения DOM. LCP задерживается до гидратации, которая должна быть достаточно завершена для рендеринга основного содержимого.
• SSR (Server-Side Rendering): Сервер отправляет HTML с уже отрендеренным содержимым. Элемент LCP может появиться значительно раньше, часто ограничен доставкой HTML, CSS и критическими изображениями.
• SSR + гидрация: HTML быстро виден (улучшая LCP), но JS все еще должен быть загружен и гидратирован для интерактивности компонентов. Сам процесс гидрации не влияет напрямую на LCP, но блокирующие ресурсы во время гидрации могут.
• Streaming SSR / React Server Components / HTML streaming: Позволяет раньше появиться шапке и начальному каркасу страницы, а также вывести элемент LCP как только он станет готов.

С точки зрения LCP, SSR (или статическая генерация) с минимальным критическим путем часто является наиболее эффективной стратегией. Архитектуры, ориентированные на CSR, требуют агрессивной оптимизации (разделение кода, приоритетные чанки, предзагрузка) для достижения схожих показателей LCP.

Загрузка ресурсов и LCP

LCP очень чувствителен к тому, что блокирует рендеринг основного содержимого:

• Критический CSS:
  • CSS, блокирующий рендеринг в заголовке, задерживает первичный рендер и, следовательно, LCP.
  • Встраивание CSS, необходимого для "above-the-fold", или использование разделения кода для CSS обеспечивает раннюю доступность ключевых стилей.
  • Избегайте больших монотонных CSS-бандлов для всех маршрутов, когда нужен только небольшой набор стилей для "above-the-fold".
• JavaScript:
  • JS, блокирующий рендеринг (синхронные скрипты без defer или async), задерживает LCP.
  • Сильно большие бандлы увеличивают TTFB до LCP, особенно на мобильных CPU.
  • Некритические скрипты должны быть отложены, загружаться ассинхронно или динамически импортированы после LCP.
• Изображения:
  • Главное изображение часто является элементом LCP; его размер, формат и доставка важны.
  • Используйте изображения подходящего размера (без излишнего увеличения), современные форматы (WebP, AVIF) — при возможности.
  • Используйте <link rel="preload" as="image"> для hero-изображений и fetchpriority="high" — при поддержке.
  • Настраивайте CDN рядом с пользователями для снижения задержки.
• Шрифты:
  • Задержка с загрузкой шрифтов и сдвиги макета из-за поздней загрузки шрифтов могут задержать окончательный вид текста.
  • Используйте font-display: swap или optional, чтобы избежать блокировки рендеринга.

В целом, LCP улучшается, когда сетевые и вычислительные расходы минимальны для отображения основного содержимого.

Решения по макету и LCP

Хотя LCP в основном связан с временем, дизайн макета и компонентов все равно важны:

• Плотность "above-the-fold": Если верх страницы загружен множеством больших элементов, "самый крупный" блок содержимого может быть тяжелее (например, карусель) и дольше рендериться.
• Условный контент: Если изначально отображать небольшой заполнитель и затем заменять его на большой компонент после загрузки данных, элемент LCP может быть отсрочен до этого момента.
• Герой-карусели и сложные компоненты героя: Часто задерживают LCP из-за тяжелой JS-инициализации или больших изображений; предпочтительнее простые статичные элементы для повышения производительности.

Проектирование более простых, статичных макетов "above-the-fold" с минимальной логикой выполнения помогает обеспечить, что элемент LCP будет дешев в рендеринге.

Что вызывает сдвиги макета

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

• Изображения или видео без фиксированных размеров.
• Рекламные объявления, вставки или iframe, добавленные поздно в DOM.
• Переключение шрифтов с запасных на финальный, изменение метрик текста.
• Динамически добавляемые компоненты (баннеры, запросы согласия), опускающие контент вниз.
• Клиентская гидрация, вставляющая содержимое поверх существующего после загрузки данных.

CLS наказывает за неожиданные сдвиги, вызванные действиями пользователя; он игнорирует перемещения, связанные с коротким окном после ввода, если они явно связаны.

Стратегия рендеринга и CLS

SSR vs CSR может влиять на количество перерасчетов макета при появлении данных:

• SSR / статический HTML: Если HTML, сгенерированный на сервере, уже содержит правильный макет с устойчивыми размерами, то меньшая часть сдвигов будет при гидратации. Однако несоответствия гидратации или изменения только на клиенте все равно могут вызывать сдвиги.
• CSR с каркасами: Часто используют заглушки для содержимого. Если размеры каркаса не соответствуют финальному содержимому, CLS может быть высоким через расширение/сжатие элементов.
• Streaming / прогрессивное рендеринг: Частичные шаблоны могут изначально использовать заглушки; снова, несовпадение между заглушкой и реальным размером может вызвать сдвиги.

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

Загрузка ресурсов и CLS

Как и когда загружаются ресурсы, может инициировать перерасчеты:

• Изображения и видео:
  • Всегда указывайте ширину и высоту (или соотношение сторон) в CSS или HTML-атрибутах.
  • Отзывчивые изображения должны сохранять пропорции, например, с помощью CSS aspect-ratio или контейнеров с отступами.
  • Избегайте, чтобы изображения \"толкали\" содержимое во время загрузки; резервируйте пространство.
• Объявления и вставки:
  • Резервируйте статические слоты с фиксированными размерами или максимальными границами.
  • Загружайте сторонний контент в эти слоты; не позволяйте им управлять макетом динамически.
• Шрифты:
  • Поздняя загрузка шрифтов может вызвать перерасчет текста, особенно если запасные шрифты отличаются по метрикам.
  • Используйте font-display: swap с совместимыми по метрикам запасными шрифтами или font-display: optional, если допустимо сохранить запасной.
• Асинхронные виджеты (чаты, аналитика, окна согласия):
  • Встраивайте их в зарезервированные области или поверхневые слои, а не вставляйте, чтобы не сдвигать основной контент.

Решения по макету и CLS

CLS очень чувствителен к CSS и структуре компонентов:

• Устойчивые контейнеры: Проектируйте компоненты так, чтобы их внешний контейнер имел предсказуемую высоту, даже прежде чем данные придут (например, карточки с минимальной высотой или постоянным соотношением сторон изображений).
• Макет "above-the-fold": Поскольку ранние сдвиги наиболее заметны, убедитесь, что секция героя, навигация и немедленное содержимое ниже полностью стабильны.
• Ленивая загрузка: Ленивая загрузка содержимого ниже "above-the-fold". Если вы лениво загружаете содержимое в зоне "above-the-fold", запасайте точное пространство, которое оно займёт.
• Переходы и анимации: Анимируйте трансформы (например, transform: translateY), а не свойства, влияющие на макет, такие как top, height, margin за пределами области взаимодействия пользователя. CLS игнорирует анимации, вызванные пользовательским вводом и явно ожидаемые, но произвольные автоматические анимации макета могут создавать ощущение резкости.

Внедрение строгих CSS-контрактов (например, всегда известные размеры, согласованный масштаб типографики) — один из наиболее эффективных способов устранить или снизить CLS.

Разбор INP по этапам

Для каждого взаимодействия INP разбивается на три этапа:

1. Задержка ввода: Время между взаимодействием и началом выполнения обработчика события. Высокая задержка ввода указывает на блокировку основного потока (например, долгие задачи).
2. Время обработки: Время, проведенное внутри обработчиков и связанной логики. Тяжелая работа JS увеличивает INP напрямую.
3. Задержка отображения: Время от завершения обработчиков до следующей отрисовки. В это время происходят перерасчеты макета, стили и实际 окраска.

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

Стратегия рендеринга и INP

Стратегия рендеринга влияет на нагрузку основного потока и, следовательно, на то, как часто он блокируется:

• CSR с тяжелой гидратацией: Начальная гидратация может создавать долгие задачи (50мс+), блокируя обработку ввода и увеличивая INP, особенно на слабых устройствах. Взаимодействия во время гидратации особенно уязвимы.
• SSR с частичной / выборочной гидратацией: Может значительно уменьшить JS, выполняемый при загрузке, оставляя больше резервов для отзывчивых взаимодействий.
• Архитектура "островов" / гидратация на уровне компонентов: Только интерактивные острова гидратируются, уменьшая глобальную нагрузку JS и конфликт основного потока.
• Серверные компоненты / тонкие клиенты: Перенос логики на сервер и легкий клиентский компонент снижают вычисления на стороне клиента за взаимодействие, улучшая INP.

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

Загрузка ресурсов и INP

Решения, связанные с ресурсами, влияют как на начальную стоимость JS, так и на отзывчивость во время выполнения:

• Размер и состав JS-бандла:
  • Большие гидрационные бандлы или монолитные фреймворки могут захватывать основной поток.
  • Используйте агрессивное tree-shaking и избегайте ненужных полифиллов или библиотек.
  • Разделяйте код по маршрутам и компонентам; лениво загружайте не-критические функции по мере необходимости.
• Планирование и управление задачами:
  • Разделяйте длинные задачи на меньшие части с помощью requestIdleCallback, setTimeout или API планировщика.
  • Отложите несрочную работу (аналитику, логирование, тяжелые вычисления) на периоды простоя.
• Сторонние скрипты:
  • Реклама, аналитика, чат-виджеты, менеджеры тегов могут вставлять тяжелый JS во время взаимодействий.
  • Изолируйте их там, где возможно (например, через web-воркеры или iframe) и загружайте лениво.

Более легкий в выполнении JS и разумное планирование задач — ключи к улучшению INP.

Решения по макету и INP

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

• Размер DOM:
  • Очень большие деревья DOM увеличивают стоимость перерасчета макета и стилей при каждом изменении.
  • Виртуализация (виртуальные списки, ленивое рендеринг внеэкранных компонентов) уменьшает работу.
• Сложные макеты:
  • Глубокие вложенные flexbox или grid макеты увеличивают вычисления макета.
  • Очень динамичные макеты, где взаимодействия изменяют множество контейнеров, могут быть дорогими.
• Анимации, связанные с взаимодействиями:
  • Аппаратно-ускоренные анимации (transform, opacity) дешевле, чем те, что влияют на макет.
  • Сложные JS-основные анимации могут добавлять накладные расходы; предпочтительнее CSS-переходы, где возможно.
• Поведение компонентов:
  • Один клик, вызывающий множественные обновления состояния по всему дереву, ведет к множественным перерисовкам.
  • Минимизируйте глобальные обновления состояния; ограничивайте их локальными компонентами или мемоизацией.

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

Для LCP

• Используйте SSR или статическую генерацию для страниц с критическими требованиями по LCP.
• Инлайните минимальный критический CSS; лениво загружайте остальное.
• Отложите или асинхронно загрузите не-критический JS; избегайте скриптов, блокирующих рендеринг.
• Предзагружайте hero-изображение и важные шрифты; используйте CDN и современные форматы.
• Держите верхнюю часть страницы простой и минимизируйте тяжелые компоненты.

Для CLS

• Задавайте фиксированные размеры или соотношение сторон для всех изображений и видео.
• Резервируйте место для рекламы, вставок и поздней подгрузки компонентов.
• Используйте font-display с метриками, совместимыми с запасными шрифтами; избегайте смещений из-за FOIT/FOUT.
• Проектируйте стабильные скелеты, соответствующие финальному контенту.
• Избегайте вставки компонентов поверх уже существующего контента после загрузки; используйте наложения.

Для INP

• Уменьшайте размер JS-бандлов через разделение кода и tree-shaking.
• Разделяйте длинные задачи; переносите тяжелую работу в web-воркеры или периоды простоя.
• Используйте виртуализацию больших списков и сложных компонентов; избегайте огромных деревьев DOM.
• Ограничивайте обновление состояния; минимизируйте перерисовки по одному действию.
• Отдавайте предпочтение CSS-переходам (transform/opacity) в анимациях взаимодействий.