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

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

Addy Osmani

Barry Pollard

Совокупный сдвиг макета (CLS) — это один из трех показателей Core Web Vitals . Он измеряет нестабильность контента путем объединения того, насколько видимый контент сместился в области просмотра, с расстоянием, на которое переместились затронутые элементы.

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

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

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

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

Наиболее распространенными причинами плохого CLS являются:

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

Понять причины изменений макета

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные сведения см. в разделе Отладка изменений макета .

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

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

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

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

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

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

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

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

История атрибутов 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:

• Если щенок.jpg имеет высоту 360 пикселей, ширина равна 360 x (16/9) = 640 пикселей.
• Если щенок.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 , как предлагалось ранее, позволяет родительскому элементу увеличиваться по мере необходимости, одновременно уменьшая влияние сдвигов макета по сравнению с размером пустого элемента по умолчанию 0 пикселей.

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

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

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

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

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

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

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

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

Анимации

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

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

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

Веб-шрифты

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

• Резервный шрифт заменяется веб-шрифтом, вызывая мигание нестилизованного текста (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 .

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

Заключение

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