Оптимизация совокупного смещения макета

Узнайте, как избежать резких изменений в расположении элементов, чтобы улучшить пользовательский опыт.

Addy Osmani

Barry Pollard

Опубликовано: 5 мая 2020 г., Последнее обновление: 7 февраля 2025 г.

Накопленное смещение макета (Cumulative Layout Shift, CLS) — одна из трех метрик Core Web Vitals . Она измеряет нестабильность контента, суммируя величину смещения видимого контента в области просмотра с расстоянием, на которое переместились затронутые элементы.

Изменения в расположении элементов могут отвлекать пользователей. Представьте, что вы начали читать статью, и вдруг элементы на странице смещаются, сбивая вас с толку и заставляя заново искать нужное место. Это очень распространенное явление в интернете, в том числе при чтении новостей или попытке нажать кнопки «Поиск» или «Добавить в корзину». Такие ситуации визуально неприятны и раздражают. Часто они возникают, когда видимые элементы вынуждены перемещаться из-за внезапного добавления или изменения размера другого элемента на странице.

Для обеспечения хорошего пользовательского опыта сайты должны стремиться к тому, чтобы показатель CLS составлял 0,1 или меньше как минимум для 75% посещений страниц.

В отличие от других показателей Core Web Vitals, которые представляют собой значения, зависящие от времени и измеряемые в секундах или миллисекундах, показатель CLS является безразмерной величиной, основанной на расчете того, насколько и насколько изменяется контент.

В этом руководстве мы рассмотрим оптимизацию распространенных причин смещения компоновки.

Наиболее распространенные причины низкого уровня CLS:

• Изображения без указания размеров.
• Реклама, встроенные элементы и iframe без указания размеров.
• Динамически внедряемый контент, такой как реклама, встроенные элементы и iframe без указания размеров.
• Веб-шрифты.

Разберитесь в причинах изменений планировки.

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

CLS в лабораторных условиях по сравнению с полевыми условиями

Часто можно услышать, как разработчики считают, что показатель CLS, измеренный в отчете Chrome UX Report (CrUX), неверен, поскольку он не совпадает с показателем CLS, измеренным с помощью Chrome DevTools или других инструментов для тестирования производительности веб-сайтов. Инструменты для тестирования производительности веб-сайтов, такие как Lighthouse, могут не отображать полный показатель CLS страницы, поскольку обычно они выполняют базовую загрузку страницы для измерения некоторых показателей производительности веб-сайта и предоставления некоторых рекомендаций (хотя пользовательские сценарии Lighthouse позволяют измерять показатели, выходящие за рамки стандартного аудита загрузки страницы).

CrUX — это набор данных Google для программы Web Vitals, и для него показатель CLS измеряется на протяжении всего жизненного цикла страницы, а не только во время первоначальной загрузки, как это обычно делают лабораторные инструменты.

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

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

В разделе «Узнайте, с чем сталкиваются ваши реальные пользователи» PageSpeed ​​Insights отображает как воспринимаемый пользователями показатель CLS для конкретного URL-адреса, так и показатель CLS, полученный в ходе лабораторной загрузки, в разделе «Диагностика проблем с производительностью». Различия между этими значениями, вероятно, являются результатом показателя CLS после загрузки.

Выявление проблем с CLS нагрузки

Когда показатели CLS от CrUX и Lighthouse в PageSpeed ​​Insights в целом совпадают, это обычно указывает на проблему с загрузкой CLS, обнаруженную Lighthouse. В этом случае Lighthouse поможет провести два аудита, чтобы предоставить дополнительную информацию об изображениях, вызывающих CLS из-за отсутствия ширины и высоты, а также перечислит все элементы, которые сместились при загрузке страницы, вместе с их вкладом в CLS. Вы можете просмотреть эти аудиты, отфильтровав их по аудитам CLS:

Панель «Производительность» в инструментах разработчика предоставляет обширную информацию об изменениях в расположении элементов:

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

При нажатии на элемент, находящийся в состоянии сдвига, появляется всплывающее окно с анимацией этого сдвига, при этом элемент, находящийся в состоянии сдвига, выделяется фиолетовым цветом.

Кроме того, в сводном представлении для записи Layout Shift отображается время начала, оценка смены, а также перемещенные элементы. Это особенно полезно для получения более подробной информации о проблемах с CLS при загрузке, поскольку это легко воспроизвести с помощью профиля производительности перезагрузки.

Это также связано с информацией о причинах изменения планировки, отображаемой на панели «Аналитика» слева, где вверху показан общий показатель CLS, а также возможные причины изменения планировки.

Выявление проблем CLS после загрузки

Расхождение между оценками CLS, полученными с помощью CrUX и Lighthouse, часто указывает на CLS после загрузки. Отследить эти изменения без полевых данных может быть сложно. Информацию о сборе полевых данных см. в разделе «Измерение элементов CLS в полевых условиях» .

В панели «Производительность» в режиме реального времени отображаются метрики, позволяющие взаимодействовать со страницей и отслеживать показатель CLS для выявления взаимодействий, вызывающих значительные изменения макета.

В качестве альтернативы использованию инструментов разработчика вы можете просматривать свою веб-страницу, одновременно отслеживая изменения макета, с помощью инструмента Performance Observer, вставленного в консоль.

После настройки мониторинга сдвигов вы можете попытаться воспроизвести любые проблемы с задержкой загрузки контента (CLS). Задержка загрузки контента часто происходит во время прокрутки страницы пользователем, когда отложенная загрузка контента происходит полностью без зарезервированного для него места. Сдвиг контента при наведении указателя мыши — еще одна распространенная причина задержки загрузки контента. Любой сдвиг контента во время любого из этих взаимодействий считается неожиданным, даже если он происходит в течение 500 миллисекунд.

Для получения дополнительной информации см. раздел «Отладка смещений компоновки» .

После выявления распространенных причин CLS можно также использовать режим анализа пользовательских потоков Lighthouse, позволяющий избежать регрессии типичных пользовательских сценариев за счет внесения изменений в макет.

Измерение элементов CLS в полевых условиях.

Мониторинг CLS в полевых условиях может быть бесценен для определения обстоятельств возникновения CLS и сужения круга возможных причин. Как и большинство лабораторных инструментов, полевые инструменты измеряют только те элементы, которые сместились, но этого обычно достаточно для выявления причины. Вы также можете использовать полевые измерения CLS для определения того, какие проблемы требуют первоочередного решения.

Библиотека web-vitals содержит функции атрибуции , позволяющие собирать эту дополнительную информацию. Для получения более подробной информации см. раздел «Отладка производительности в полевых условиях» . Другие поставщики RUM также начали собирать и представлять эти данные аналогичным образом.

Распространенные причины CLS

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

Изображения без размеров

Всегда добавляйте атрибуты width и height к вашим изображениям и видеоэлементам. В качестве альтернативы, зарезервируйте необходимое пространство с помощью CSS- aspect-ratio или аналогичного. Такой подход гарантирует, что браузер сможет выделить правильное количество места в документе во время загрузки изображения.

История изменения атрибутов width и height изображений.

На заре веб-разработки разработчики добавляли атрибуты width и height к своим тегам <img> , чтобы обеспечить достаточное пространство на странице до того, как браузер начнет загрузку изображений. Это позволяло минимизировать перерисовку и изменение макета.

<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

В этом примере width и height не указаны в единицах измерения. Эти размеры в пикселях гарантируют, что браузер зарезервирует область 640x360 в макете страницы. Изображение будет растягиваться, чтобы соответствовать этому пространству, независимо от того, соответствуют ли ему фактические размеры.

С появлением адаптивного веб-дизайна разработчики стали отказываться от указания width и height и вместо этого стали использовать CSS для изменения размера изображений:

img {
  width: 100%; /* or max-width: 100%; */
  height: auto;
}

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

Здесь вступает в дело соотношение сторон. Соотношение сторон изображения — это отношение его ширины к высоте. Обычно оно выражается двумя числами, разделенными двоеточием (например, 16:9 или 4:3). При соотношении сторон x:y изображение имеет ширину x единиц и высоту y единиц.

Это означает, что если нам известен один из параметров, то можно определить и другой. Для соотношения сторон 16:9:

• Если высота изображения puppy.jpg составляет 360 пикселей, то ширина равна 360 x (16 / 9) = 640 пикселей.
• Если ширина изображения puppy.jpg составляет 640 пикселей, то высота равна 640 x (9 / 16) = 360 пикселей.

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

Современные передовые методы установки размеров изображений.

Поскольку современные браузеры устанавливают стандартное соотношение сторон изображений на основе атрибутов width и height изображения, вы можете предотвратить смещение макета, задав эти атрибуты для изображения и включив соответствующий CSS-код в свою таблицу стилей.

<!-- set a 640:360 i.e a 16:9 aspect ratio -->
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

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

Эта функция вычисляет соотношение сторон на основе атрибутов width и height до загрузки изображения. Она предоставляет эту информацию в самом начале расчета компоновки. Как только изображению задается определенная ширина (например width: 100% ), соотношение сторон используется для расчета высоты.

Значение aspect-ratio вычисляется основными браузерами в процессе обработки HTML-кода, а не с помощью стандартной таблицы стилей User Agent ( подробнее об этом см. в этой статье ), поэтому значение отображается несколько иначе. Например, Chrome отображает его в разделе «Стили» панели «Элемент» следующим образом:

img[Attributes Style] {
  aspect-ratio: auto 640 / 360;
}

Safari ведет себя аналогично, используя HTML-атрибуты в качестве источника стиля. Firefox вообще не отображает это вычисленное aspect-ratio в панели инспектора , но использует его для компоновки.

Часть кода, отвечающая за параметр auto , важна, поскольку она приводит к тому, что размеры изображения переопределяют соотношение сторон по умолчанию после загрузки изображения. Если размеры изображения отличаются, это все равно вызывает некоторое смещение макета после загрузки изображения, но это гарантирует, что соотношение сторон изображения будет использоваться, когда оно станет доступно, в случае, если HTML-код некорректен. Даже если фактическое соотношение сторон отличается от значения по умолчанию, это все равно вызывает меньшее смещение макета, чем размер изображения по умолчанию 0x0, для которого не указаны размеры.

Для более подробного изучения соотношения сторон и дальнейших размышлений об адаптивных изображениях, см. статью «Бесперебойная загрузка страниц с использованием соотношения сторон медиафайлов» .

Если ваше изображение находится в контейнере, вы можете использовать CSS для изменения размера изображения в соответствии с шириной контейнера. Мы установили height: auto; чтобы избежать использования фиксированного значения для высоты изображения.

img {
  height: auto;
  width: 100%;
}

А как насчет адаптивных изображений?

При работе с адаптивными изображениями srcset определяет, какие изображения браузер может выбирать, и какой размер имеет каждое изображение. Чтобы гарантировать возможность установки атрибутов ширины и высоты <img> , каждое изображение должно использовать одинаковое соотношение сторон.

<img
  width="1000"
  height="1000"
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"
  alt="Puppy with balloons"
/>

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

<picture>
  <source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" />
  <source media="(min-width: 800px)" srcset="puppy-800w.jpg" />
  <img src="puppy-800w.jpg" alt="Puppy with balloons" />
</picture>

Теперь Chrome, Firefox и Safari поддерживают установку width и height для элементов <source> внутри заданного элемента <picture> :

<picture>
  <source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" width="480" height="400" />
  <source media="(min-width: 800px)" srcset="puppy-800w.jpg" width="800" height="400" />
  <img src="puppy-800w.jpg" alt="Puppy with balloons" width="800" height="400" />
</picture>

Реклама, встроенные элементы и другой контент, загружаемый с задержкой.

Изображения — не единственный тип контента, который может вызывать смещение макета. Реклама, встроенные элементы, iframe и другой динамически внедряемый контент могут приводить к смещению контента, отображаемого после них, вниз, увеличивая показатель CLS (количество кликов в секунду).

Реклама является одним из основных факторов, влияющих на изменение макета веб-страниц. Рекламные сети и издатели часто поддерживают динамические размеры рекламы. Увеличение размеров рекламы повышает эффективность и доход за счет более высоких показателей кликов и большего количества объявлений, конкурирующих на аукционе. К сожалению, это может привести к ухудшению пользовательского опыта, поскольку реклама смещает видимый контент вниз по странице.

Встраиваемые виджеты позволяют добавлять на страницу портативный веб-контент, например, видео с YouTube, карты Google Maps и публикации из социальных сетей. Однако эти виджеты часто не знают размер своего содержимого до загрузки. В результате платформы, предлагающие встраивание, не всегда резервируют место для своих виджетов, что приводит к смещению макета при их загрузке.

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

Зарезервируйте место для контента, загружаемого с задержкой.

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

Один из подходов — добавить правило CSS ` min-height для резервирования пространства или — для адаптивного контента, например, рекламы — использовать свойство CSS ` aspect-ratio аналогично тому, как браузеры автоматически используют его для изображений с заданными размерами.

Возможно, вам потребуется учесть незначительные различия в размерах рекламных объявлений или заполнителей в зависимости от форм-фактора, используя медиа-запросы.

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

Вместо этого вы можете установить начальный размер на самый маленький размер, который будет использоваться, и допустить некоторое смещение для более крупного контента. Использование min-height , как предлагалось ранее, позволяет родительскому элементу увеличиваться по мере необходимости, уменьшая при этом влияние смещений макета по сравнению с размером пустого элемента по умолчанию, равным 0px.

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

Размещайте контент, загружаемый с задержкой, ниже в области просмотра.

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

Избегайте добавления нового контента без взаимодействия с пользователем.

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

Если вам необходимо отображать подобные элементы пользовательского интерфейса, заранее зарезервируйте для них достаточно места в области просмотра (например, используя плейсхолдер или каркас интерфейса), чтобы при загрузке содержимое страницы неожиданно не смещалось. В качестве альтернативы, убедитесь, что элемент не является частью потока документа, наложив на него содержимое там, где это имеет смысл. Дополнительные рекомендации по таким компонентам см. в статье «Рекомендации по использованию уведомлений о файлах cookie» .

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

• Замените старый контент новым в контейнере фиксированного размера или используйте карусель и удалите старый контент после завершения перехода. Не забудьте отключить все ссылки и элементы управления до завершения перехода, чтобы предотвратить случайные клики или касания во время загрузки нового контента.
• Предложите пользователю инициировать загрузку нового контента, чтобы он не был застигнут врасплох изменением (например, с помощью кнопок «Загрузить ещё» или «Обновить»). Рекомендуется предварительно загрузить контент до взаимодействия с пользователем, чтобы он отобразился немедленно. Напоминаем, что изменения макета, происходящие в течение 500 миллисекунд после ввода пользователя, не учитываются в CLS.
• Загружайте контент за пределы экрана и отображайте пользователю уведомление о его доступности (например, с помощью кнопки «Прокрутить вверх»).

Анимации

Изменения значений свойств CSS могут потребовать от браузера реакции на эти изменения. Некоторые значения, такие как box-shadow и box-sizing , запускают перекомпоновку, отрисовку и компоновку. Изменение свойств top и left также вызывает сдвиги компоновки, даже если перемещаемый элемент находится на отдельном слое. Избегайте анимации с использованием этих свойств.

Другие свойства CSS можно изменять без перекомпоновки. К ним относятся использование анимации transform для перемещения, масштабирования, вращения или искажения элементов.

Композитные анимации с использованием translate не могут влиять на другие элементы и, следовательно, не учитываются в CLS. Некомпозитные анимации также не вызывают перекомпоновки. Чтобы узнать больше о том, какие свойства CSS вызывают сдвиги компоновки, см. раздел «Высокопроизводительные анимации» .

Веб-шрифты

Загрузка и отображение веб-шрифтов обычно осуществляется одним из двух способов до загрузки самого шрифта:

• В качестве резервного шрифта используется веб-шрифт, что приводит к появлению «вспышки нестилизованного текста» (Flash of Unstyled Text, FOUT).
• «Невидимый» текст отображается с использованием резервного шрифта до тех пор, пока не станет доступен веб-шрифт и текст не станет видимым (FOIT — вспышка невидимого текста).

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

Следующие инструменты помогут вам свести к минимуму смещение текста:

• font-display: optional позволяет избежать переразметки, поскольку веб-шрифт используется только в том случае, если он доступен на момент первоначальной разметки.
• Убедитесь, что используется соответствующий резервный шрифт. Например, использование font-family: "Google Sans", sans-serif; гарантирует использование резервного шрифта sans-serif браузера, пока загружается "Google Sans" . Если не указать резервный шрифт, используя только font-family: "Google Sans" будет использоваться шрифт по умолчанию, который в Chrome — "Times" — шрифт с засечками, который хуже подходит, чем шрифт sans-serif по умолчанию.
• Сведите к минимуму разницу в размерах между резервным шрифтом и веб-шрифтом, используя новые API-функции size-adjust , ascent-override , descent-override и line-gap-override , как подробно описано в статье «Улучшенные резервные шрифты» .
• API загрузки шрифтов может сократить время, необходимое для получения необходимых шрифтов.
• Загружайте критически важные веб-шрифты как можно раньше, используя <link rel=preload> . Предварительно загруженный шрифт имеет больше шансов быть перерисованным первым, в этом случае смещения макета не произойдет.

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

Снизьте количество записей в кэше (CLS), убедившись, что страницы подходят для кэширования bfcache.

Одним из высокоэффективных способов поддержания низкого уровня CLS является обеспечение возможности использования кэша "назад/вперед" (bfcache) для ваших веб-страниц.

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

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

На многих сайтах часто используются функции «назад» и «вперед». Например, для возврата на страницу содержания, страницу категории или страницу результатов поиска.

После внедрения этой функции в Chrome мы заметили существенные улучшения в работе CLS .

BF-кэш используется по умолчанию всеми браузерами, но некоторые сайты не могут его использовать по разным причинам. Для получения более подробной информации о том, как проверить и выявить любые проблемы, препятствующие использованию BF-кэша, и убедиться, что вы используете эту функцию в полной мере, это поможет улучшить общий показатель CLS вашего сайта, ознакомьтесь с руководством по BF-кэшу .

Заключение

Существует ряд методов выявления и улучшения показателей CLS, как подробно описано ранее в этом руководстве. В Core Web Vitals заложены определенные ограничения, поэтому даже если вы не можете полностью устранить CLS, использование некоторых из этих методов должно позволить вам уменьшить его влияние. Это, будем надеяться, позволит вам оставаться в пределах установленных лимитов, создавая более удобный интерфейс для пользователей вашего веб-сайта.