Узнайте, как избежать внезапных изменений макета, чтобы улучшить взаимодействие с пользователем.
Опубликовано: 5 мая 2020 г., Последнее обновление: 7 февраля 2025 г.
Совокупный сдвиг макета (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 после загрузки.
![PageSpeed Insights показывает данные на уровне URL-адресов, подчеркивающие реальный пользовательский CLS, который значительно больше, чем Lighthouse CLS.](https://web.developers.google.cn/static/articles/optimize-cls/image/screenshot-pagespeed-ins-1b9715cccc402.png?hl=ru)
Выявление проблем с загрузкой CLS
Когда оценки CrUX и Lighthouse CLS в PageSpeed Insights в целом совпадают, это обычно указывает на проблему с загрузкой CLS, обнаруженную Lighthouse. В этом случае Lighthouse поможет провести два аудита, чтобы предоставить дополнительную информацию об изображениях, вызывающих CLS из-за отсутствия ширины и высоты, а также перечислить все элементы, которые сместились при загрузке страницы, вместе с их вкладом в CLS. Вы можете увидеть эти аудиты, отфильтровав аудиты CLS:
![Снимок экрана Lighthouse, на котором показаны аудиты CLS, предоставляющие дополнительную информацию, которая поможет вам выявить и устранить проблемы CLS.](https://web.developers.google.cn/static/articles/optimize-cls/image/lighthouse-screenshot-sho-1c6eeefdc4b1b.png?hl=ru)
Панель «Производительность» в DevTools предоставляет массу информации об изменениях макета:
![Записи Layout Shift отображаются на панели производительности Chrome DevTools.](https://web.developers.google.cn/static/articles/optimize-cls/image/devtools-cls-debugging.png?hl=ru)
Layout Shift
. При нажатии на ромбы отображается анимация сдвига и подробные сведения на панели «Сводка» .Сдвиги макета выделяются на дорожке «Сдвиги макета» . Группы фиолетовых линий смещаются в кластеры сдвигов, а ромбы показывают отдельные сдвиги в этом кластере. Размер ромба пропорционален размеру смены, что позволяет вам отточить самые большие смены.
При нажатии на сдвиг отображается всплывающее окно с анимацией сдвига и выделение элемента фиолетовым цветом.
Кроме того, представление «Сводка» для записи Layout Shift
включает время начала, оценку сдвига, а также сдвинутые элементы. Это особенно полезно для получения более подробной информации о проблемах CLS при загрузке, поскольку это легко воспроизводится с помощью профиля производительности перезагрузки.
Это также связано с информацией о виновниках смещения макета, отображаемой на панели Insights слева, которая показывает общий CLS вверху, а также возможные причины смещения макета.
Выявление проблем CLS после загрузки
Расхождение между оценками CrUX и Lighthouse CLS часто указывает на CLS после нагрузки. Эти изменения сложно отследить без полевых данных. Информацию о сборе полевых данных см. в разделе Измерение элементов CLS в поле .
Представление показателей в реальном времени на панели производительности позволяет вам взаимодействовать со страницей и отслеживать оценку CLS, чтобы выявлять взаимодействия, вызывающие большие сдвиги макета.
![Записи Layout Shift отображаются на экране показателей в реальном времени панели производительности Chrome DevTools.](https://web.developers.google.cn/static/articles/optimize-cls/image/live-metrics-cls.png?hl=ru)
В качестве альтернативы использованию DevTools вы можете просматривать веб-страницу, записывая изменения макета, с помощью Performance Observer, вставленного в консоль.
После настройки мониторинга смены вы можете попытаться воспроизвести любые проблемы CLS после загрузки. CLS часто происходит, когда пользователь прокручивает страницу, когда лениво загруженный контент загружается полностью без отведенного для него места. Смещение контента, когда пользователь удерживает на нем указатель, является еще одной распространенной причиной CLS после загрузки. Любое изменение контента во время любого из этих взаимодействий считается неожиданным, даже если оно происходит в течение 500 миллисекунд.
Дополнительные сведения см. в разделе Отладка изменений макета .
После того, как вы определили какие-либо распространенные причины CLS, режим потока пользователей Lighthouse также можно использовать, чтобы гарантировать, что типичные потоки пользователей не регрессируют за счет внесения изменений в макет.
Измерьте элементы CLS в полевых условиях
Мониторинг CLS в полевых условиях может иметь неоценимое значение для определения обстоятельств, при которых происходит CLS, и выявления возможных причин. Как и большинство лабораторных инструментов, полевые инструменты измеряют только те элементы, которые сместились, но обычно дают достаточно информации для выявления причины. Вы также можете использовать полевые измерения CLS, чтобы определить, какие проблемы являются наиболее приоритетными для устранения.
Библиотека web-vitals
имеет функции атрибуции , которые позволяют собирать дополнительную информацию. Дополнительные сведения см. в разделе Отладка производительности в поле . Другие провайдеры RUM также начали собирать и представлять эти данные аналогичным образом.
Распространенные причины CLS
После того, как вы определили причины CLS, вы можете начать работу над устранением проблем. В этом разделе мы покажем некоторые из наиболее распространенных причин CLS и то, что вы можете сделать, чтобы их избежать.
Изображения без размеров
Всегда включайте атрибуты размера width
и height
в изображения и видеоэлементы. Альтернативно, зарезервируйте необходимое пространство с помощью aspect-ratio
CSS или чего-то подобного. Такой подход гарантирует, что браузер сможет выделить правильное количество места в документе во время загрузки изображения.
![Отчет Lighthouse, показывающий влияние совокупного смещения макета до/после после установки размеров изображений.](https://web.developers.google.cn/static/articles/optimize-cls/image/lighthouse-report-showing-9556bbb060b37.png?hl=ru)
История атрибутов 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.
- Легко загружайте контент за кадром и накладывайте пользователю уведомление о его доступности (например, с помощью кнопки «Прокрутить вверх»).
![Примеры динамической загрузки контента без неожиданных изменений макета в Twitter и на веб-сайте Chloé.](https://web.developers.google.cn/static/articles/optimize-cls/image/examples-dynamic-content-4d11ddda2fa94.png?hl=ru)
Анимации
Изменения значений свойств 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 для получения более подробной информации о том, как тестировать и выявлять любые проблемы, препятствующие использованию bfcache, чтобы убедиться, что вы в полной мере используете эту функцию, чтобы повысить общий балл CLS для вашего сайта.
Заключение
Существует ряд методов выявления и улучшения CLS, которые подробно описаны ранее в этом руководстве. В Core Web Vitals предусмотрены допуски, поэтому даже если вы не можете полностью исключить CLS, использование некоторых из этих методов должно позволить вам уменьшить влияние. Мы надеемся, что это позволит вам оставаться в этих пределах, создавая лучший опыт для пользователей вашего веб-сайта.
,Узнайте, как избежать внезапных изменений макета, чтобы улучшить взаимодействие с пользователем.
Опубликовано: 5 мая 2020 г., Последнее обновление: 7 февраля 2025 г.
Совокупный сдвиг макета (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 после загрузки.
![PageSpeed Insights показывает данные на уровне URL-адресов, подчеркивающие реальный пользовательский CLS, который значительно больше, чем Lighthouse CLS.](https://web.developers.google.cn/static/articles/optimize-cls/image/screenshot-pagespeed-ins-1b9715cccc402.png?hl=ru)
Выявление проблем с загрузкой CLS
Когда оценки CrUX и Lighthouse CLS в PageSpeed Insights в целом совпадают, это обычно указывает на проблему с загрузкой CLS, обнаруженную Lighthouse. В этом случае Lighthouse поможет провести два аудита, чтобы предоставить дополнительную информацию об изображениях, вызывающих CLS из-за отсутствия ширины и высоты, а также перечислить все элементы, которые сместились при загрузке страницы, вместе с их вкладом в CLS. Вы можете увидеть эти аудиты, отфильтровав аудиты CLS:
![Снимок экрана Lighthouse, на котором показаны аудиты CLS, предоставляющие дополнительную информацию, которая поможет вам выявить и устранить проблемы CLS.](https://web.developers.google.cn/static/articles/optimize-cls/image/lighthouse-screenshot-sho-1c6eeefdc4b1b.png?hl=ru)
Панель «Производительность» в DevTools предоставляет массу информации об изменениях макета:
![Записи Layout Shift отображаются на панели производительности Chrome DevTools.](https://web.developers.google.cn/static/articles/optimize-cls/image/devtools-cls-debugging.png?hl=ru)
Layout Shift
. При нажатии на ромбы отображается анимация сдвига и подробные сведения на панели «Сводка» .Сдвиги макета выделяются на дорожке «Сдвиги макета» . Группы фиолетовых линий смещаются в кластеры сдвигов, а ромбы показывают отдельные сдвиги в этом кластере. Размер ромба пропорционален размеру смены, что позволяет вам отточить самые большие смены.
При нажатии на сдвиг отображается всплывающее окно с анимацией сдвига и выделение элемента фиолетовым цветом.
Кроме того, представление «Сводка» для записи Layout Shift
включает время начала, оценку сдвига, а также сдвинутые элементы. Это особенно полезно для получения более подробной информации о проблемах CLS при загрузке, поскольку это легко воспроизводится с помощью профиля производительности перезагрузки.
Это также ссылается на проницательность виновников смены макета, отображаемой на панели Insights слева, которая показывает общее количество CLS вверху, а также возможные причины сдвигов макета.
Определить проблемы CLS после нагрузки
Разногласия между баллами CLS CRUX и Lighthouse часто указывают на CLS после получения нагрузки. Эти сдвиги могут быть сложными для отслеживания без полевых данных. Информацию о сборе данных полевых данных см. В полевых элементах CLS Elements .
Вид в живых метрик на панели производительности позволяет вам взаимодействовать со страницей и отслеживать оценку CLS, чтобы идентифицировать взаимодействия, вызывая большие макет.
![Записи смены макета отображаются на экране Live Metrics of Chrome Devtools Performance Panel.](https://web.developers.google.cn/static/articles/optimize-cls/image/live-metrics-cls.png?hl=ru)
В качестве альтернативы использованию DevTools вы можете просмотреть свою веб -страницу, когда записывая смены макета, используя наблюдатель производительности, вставленную в консоль.
После установки мониторинга смены вы можете попытаться воспроизвести любые проблемы CLS после загрузки. CLS часто случается, пока пользователь прокручивается через страницу, когда ленивый загруженный контент полностью загружается без зарезервированного места для нее. Сдвиг контента, когда пользователь удерживает указатель на него, является еще одной общей причиной CLS после загрузки. Любое сдвиг контента во время любого из этих взаимодействий считается неожиданным, даже если это происходит в течение 500 миллисекунд.
Для получения дополнительной информации см. Смена макета отладки .
После того, как вы определили любые общие причины CLS, режим пользовательского потока TimesPans также может использоваться для обеспечения того, чтобы типичные пользовательские потоки не регрессировали, внедряя сдвиги макета.
Измерить элементы CLS в поле
Мониторинг CLS в полевых условиях может быть неоценимым при определении того, в каких обстоятельствах возникает CLS, и сузить возможные причины. Как и большинство лабораторных инструментов, полевые инструменты измеряют только те элементы, которые смещались, но обычно предоставляет достаточно информации для определения причины. Вы также можете использовать полевые измерения CLS, чтобы определить, какие проблемы являются самым высоким приоритетом для исправления.
Библиотека web-vitals
имеет функции атрибуции , которые позволяют вам собирать эту дополнительную информацию. Для получения дополнительной информации см. Производительность отладки в этой области . Другие поставщики рома также начали собирать и представлять эти данные аналогично.
Общие причины CLS
После того, как вы определили причины CLS, вы можете начать работу над решением проблем. В этом разделе мы покажем некоторые из наиболее распространенных причин для CLS и того, что вы можете сделать, чтобы избежать их.
Изображения без измерений
Всегда включайте атрибуты width
и размера height
на ваши изображения и элементы видео. В качестве альтернативы оставьте необходимое пространство с помощью CSS aspect-ratio
или аналогичного. Этот подход гарантирует, что браузер может выделить правильное количество места в документе, когда изображение загружается.
![Отчет Маяка, показывающий, что до/после удара на совокупный сдвиг макета после установки размеров на изображениях](https://web.developers.google.cn/static/articles/optimize-cls/image/lighthouse-report-showing-9556bbb060b37.png?hl=ru)
История 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 имеет высоту 360px, ширина составляет 360 x (16/9) = 640px
- Если Puppy.jpg имеет ширину 640px, высота составляет 640 x (9/16) = 360px
Знание соотношения сторон для изображения позволяет браузеру рассчитать и зарезервировать достаточно места для высоты и связанной области.
Современная лучшая практика для установки размеров изображений
Поскольку современные браузеры устанавливают соотношение сторон по умолчанию изображений на основе 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 обрабатывается, а не с листом стиля пользовательского агента по умолчанию (см. Этот пост для глубокого погружения в почему ), поэтому значение отображается немного по-другому. Например, Chrome отображает его в разделе «Стили» панели элемента:
img[Attributes Style] {
aspect-ratio: auto 640 / 360;
}
Safari ведет себя так же, используя источник стиля атрибутов HTML . Firefox вообще не отображает этот расчетный aspect-ratio
на панели инспектора , но использует его для макета.
auto
часть предыдущего кода важна, потому что она заставляет измерения изображения переопределить соотношение сторон по умолчанию после загрузки изображения. Если размеры изображения различны, это все еще вызывает некоторое сдвиг макета после загрузки изображения, но это гарантирует, что соотношение сторон изображения все еще используется, когда оно становится доступным, если HTML неверен. Даже если фактическое соотношение сторон отличается от по умолчанию, оно все равно вызывает меньшее сдвиг макета, чем размер по умолчанию 0x0 изображения без предоставленных измерений.
Для фантастического глубокого соотношения аспектов с дальнейшим размышлением о адаптивных изображениях см. В загрузке страницы без jank с помощью соотношений СМИ .
Если ваше изображение находится в контейнере, вы можете использовать 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>
Реклама, встраиваемые и другие поздние загруженные контенты
Изображения - не единственный тип контента, который может вызвать сдвиги макета. Объявления, вставки, iframes и другие динамически инъецированные контент могут привести к появлению контента, появляющегося после них, сдвигается вниз, увеличивая ваши CLS.
Объявления являются одним из крупнейших участников смены макета в Интернете. Сетевые сети и издатели часто поддерживают динамические размеры рекламы. Размеры рекламы повышают производительность и доход из -за более высоких показателей кликов и большего количества рекламы, конкурирующих на аукционе. К сожалению, это может привести к неоптимальному пользовательскому опыту из -за рекламы, выдвигающих видимый контент, который вы просматриваете на странице.
Встроенные виджеты позволяют включать портативный веб -контент на вашу страницу, такие как видео с YouTube, карты из карт Google и посты в социальных сетях. Тем не менее, эти виджеты часто не знают о том, насколько велик их содержимое, прежде чем они загружаются. В результате платформы, предлагающие встраиваемые, не всегда оставляют место для их виджетов, что вызывает сдвиги планировки, когда они наконец загружаются.
Методы для работы с ними похожи. Основными различиями в том, сколько у вас контроля над контентом, который будет вставлен. Если это вставлено сторонним партнером, такими как рекламный партнер, вы можете не знать точный размер содержания, который будет вставлен, и не сможет контролировать какие-либо сдвиги макета, происходящие во вставках.
Резервировать место для поздней загрузки
При размещении контента поздней загрузки в потоке контента можно избежать смены макета, оставляя их пространство в начальном макете.
Одним из подходов является добавление правила CSS min-height
чтобы резервировать пространство или, например, отзывчивый контент, такой как реклама,-использовать свойство CSS aspect-ratio
аналогично тому, как браузеры автоматически используют это для изображений с предоставленными размерами.
Вам может потребоваться учесть тонкие различия в размерах AD или заполнителей между форм -факторами, используя медиа -запросы.
Для контента, который может не иметь фиксированной высоты, например, реклама, вы не сможете зарезервировать точное количество места, необходимое для полного устранения сдвига макета. Если подается меньшая реклама, издатель может призвать более крупный контейнер, чтобы избежать сдвигов макета, или выбрать наиболее вероятный размер для слота AD на основе исторических данных. Недостатком этого подхода является то, что он увеличивает количество пустого места на странице.
Вместо этого вы можете установить начальный размер на самый маленький размер, который будет использоваться, и принять некоторый уровень сдвига для более крупного содержания. Использование min-height
, как предполагалось ранее, позволяет родительскому элементу расти по мере необходимости, уменьшая воздействие сдвигов макета по сравнению с размером по умолчанию в 0PX пустого элемента.
Старайтесь избегать разрушения зарезервированного пространства, показывая заполнителя, если, например, реклама не возвращается. Удаление пространства, выделенного для элементов, может привести к тому, что CLS может привести к тому, что вставка контента.
Поместите контент с поздним загрузкой ниже в просмотре
Динамически впрыскиваемый контент ближе к верхней части видового тома обычно вызывает большие сдвиги макета, чем содержание, введенное ниже в точке зрения. Тем не менее, инъекция контента в любом месте просмотра по -прежнему вызывает некоторую смену. Если вы не можете зарезервировать пространство для инъецированного контента, мы рекомендуем разместить его позже на странице, чтобы уменьшить влияние на его CLS.
Избегайте вставки нового контента без взаимодействия с пользователем
Вы, вероятно, испытали сдвиги макета из-за пользовательского интерфейса, который заскочил вверху или внизу видового порта, когда вы пытаетесь загрузить сайт. Похоже на рекламу, это часто случается с баннерами и формами, которые сдвигают остальную часть контента страницы:
Если вам нужно отобразить эти типы доступных возможностей, заранее зарезервируйте достаточно места в просмотре (например, используя пользовательский интерфейс заполнителя или скелета), чтобы при загрузке он не заставляет контент на странице на удивление сдвинуто. В качестве альтернативы, убедитесь, что элемент не является частью потока документов, накладывая контент, где это имеет смысл. Посмотрите на лучшие практики для уведомлений о cookie post для получения дополнительных рекомендаций по этим типам компонентов.
В некоторых случаях динамическое добавление контента является важной частью пользовательского опыта. Например, при загрузке большего количества продуктов в список элементов или при обновлении контента в прямом эфире. Есть несколько способов избежать неожиданных сдвигов макета в этих случаях:
- Замените старый контент новым контентом в контейнере с фиксированным размером или используйте карусель и удалите старый контент после перехода. Не забудьте отключить любые ссылки и элементы управления, пока переход не будет завершен, чтобы предотвратить случайные клики или краны, пока появится новый контент.
- Попросите пользователя инициировать нагрузку нового контента, чтобы он не удивлен сдвигом (например, кнопкой «загружать больше» или «обновление»). Рекомендуется предварительно переподтировать контент перед взаимодействием с пользователем, чтобы он отображался немедленно. В качестве напоминания, сдвиги макета, которые происходят в пределах 500 миллисекунд после пользовательского ввода, не учитываются в отношении CLS.
- Бесполезно загрузите контент за пределами экрана и накладывайте уведомление пользователю, что оно доступно (например, кнопкой «Свитка к верхней»).
![Примеры динамической загрузки контента, не вызывая неожиданные смены макета из Twitter и веб -сайта Chloé](https://web.developers.google.cn/static/articles/optimize-cls/image/examples-dynamic-content-4d11ddda2fa94.png?hl=ru)
Анимации
Изменения в значениях свойств 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
Sharkback, когда загружается"Google Sans"
. Не указывая шрифт с использованиемfont-family: "Google Sans"
будет означать, что используется шрифт по умолчанию, который на Chrome-«Times»-шрифт Serif, который является худшим совпадением, чем шрифтsans-serif
. - Минимизируйте различия в размерах между шрифтом запасного и веб-шрифтом, используя новую апонтику
size-adjust
,ascent-override
,descent-override
line-gap-override
, как подробно описано в улучшенном посте запасных шрифтов . - API загрузки шрифта может сократить время, необходимое для получения необходимых шрифтов.
- Загрузите критические веб -шрифты как можно раньше, используя
<link rel=preload>
. Предварительно загруженный шрифт будет иметь более высокий шанс встретиться с первой краской, и в этом случае не изменяется макет.
Прочитайте лучшие практики для шрифтов для других лучших практик шрифта.
Уменьшите CL, обеспечивая, чтобы страницы имели право на BFCACHE
Высокоэффективный метод для поддержания низких показателей CLS - гарантировать, что ваши веб -страницы имеют право на обратный/вперед кэш (BFCACHE).
BFCache сохраняет страницы в памяти браузеров в течение короткого периода после того, как вы уходите, поэтому, если вы вернетесь к ним, то они будут восстановлены точно так же, как вы их оставили. Это означает, что полностью загруженная страница мгновенно доступна - без каких -либо изменений, которые обычно можно увидеть во время нагрузки по любой из причин, приведенных ранее.
Хотя это потенциально все еще означает, что начальные сдвиги нагрузки на странице сдвигаются, когда пользователь возвращается через страницы, он не видит одинаковые сдвиги макета неоднократно. Вы всегда должны стремиться избежать сдвигов даже при начальной нагрузке, но где это более сложно полностью разрешить, вы можете, по крайней мере, уменьшить влияние, избегая их на любых навигациях BFCache.
Навигации назад и вперед распространены на многих сайтах. Например, возвращение на страницу содержимого или страницу категории или результаты поиска.
Когда это было развернуто в Chrome , мы увидели заметные улучшения в CLS .
BFCache используется по умолчанию всеми браузерами, но некоторые сайты не имеют права на BFCACHE по разным причинам. Прочитайте Руководство BFCache для получения более подробной информации о том, как проверить и определить любые проблемы, предотвращая использование BFCache, чтобы убедиться, что вы в полной мере используете эту функцию, чтобы помочь вашему общему баллу CLS для вашего сайта.
Заключение
Существует ряд методов для выявления и улучшения CLS, как подробно описано ранее в этом руководстве. Существуют пособия, встроенные в основные веб -жизненные силы, поэтому даже если вы не можете полностью устранить CLS, использование некоторых из этих методов должно позволить вам уменьшить воздействие. Надеемся, что это позволит вам оставаться в этих пределах, создавая лучший опыт для пользователей вашего сайта.
,Узнайте, как избежать внезапных сдвигов макета, чтобы улучшить пользовательский опыт
Опубликовано: 5 мая 2020 года, последний обновлен: 7 февраля 2025 г.
Совокупный сдвиг макета (CLS) является одним из трех основных метрик веб -Vitals . Он измеряет нестабильность контента, объединив, сколько видимого контента сместилось в просмотре с расстоянием, которое перемещались затронутые элементы.
Сдвиги макета могут отвлекаться от пользователей. Представьте, что вы начали читать статью, когда внезапные элементы смещаются вокруг страницы, отбросив вас и требуя, чтобы вы снова нашли свое место. Это очень распространено в Интернете, в том числе при чтении новостей или попытке нажать эти кнопки «Поиск» или «Добавить в корзину». Такой опыт визуально раздражает и разочаровывает. Они часто вызываются, когда видимые элементы вынуждены двигаться, потому что другой элемент был внезапно добавлен на страницу или изменялся.
Чтобы обеспечить хороший пользовательский опыт, сайты должны стремиться иметь CLS 0,1 или менее как минимум для 75% посещений страниц.
В отличие от других основных веб-жизнеспособников, которые представляют собой значения, основанные на времени, измеренные за секунды или миллисекунд, оценка CLS является без единичного значения, основанного на расчете того, сколько контента смещается и как далеко.
В этом руководстве мы рассмотрим оптимизацию общих причин сменов макета.
Наиболее распространенными причинами бедных CL являются:
- Изображения без измерений.
- Реклама, встраивания и iframes без измерений.
- Динамически инъецированный контент, такой как реклама, встраиваемые и iframes без измерений.
- Веб -шрифты.
Понять причины смены макета
Прежде чем вы начнете искать решения для общих проблем CLS, важно понять ваш счет CLS и откуда, откуда приходят сдвиги.
CLS в лабораторных инструментах по сравнению с поле
Обычно разработчики считают, что CLS, измеренные с помощью Chrome UX Report (CRUX), неверно, поскольку он не соответствует CLS, который они измеряют, используя Chrome Devtools или другие лабораторные инструменты. Лабораторные инструменты Web Performance, такие как Lighthouse, могут не показывать полную CLS страницы, поскольку они обычно выполняют базовую нагрузку страницы для измерения некоторых показателей веб -производительности и предоставления некоторого руководства (хотя потоки пользователей Lighthouse позволяют измерять вас за пределы страницы по умолчанию).
CRUX - это официальный набор данных программы Web Vitals, и для этого CLS измеряется на протяжении всего срока службы страницы, а не только во время начальной загрузки страницы, которые обычно измеряют лабораторные инструменты.
Сдвиги макета очень распространены во время загрузки страницы, так как все необходимые ресурсы извлекаются для первоначального отображения страницы, но сдвиги макета также могут произойти после начальной нагрузки. Многие сдвиги после нагрузки могут произойти в результате взаимодействия с пользователем и, следовательно, будут исключены из баллов CLS, поскольку они ожидаются смены-если они происходят в течение 500 миллисекунд от этого взаимодействия.
Тем не менее, другие сдвиги после нагрузки, которые неожиданны пользователем, могут быть включены, если не было квалификационного взаимодействия, например, если вы прокручиваете дальше по странице, а содержание с ленивым загруженным загружается, и это вызывает сдвиги. Другие общие причины пост-нагрузки CLS связаны с взаимодействием переходов, например, в приложениях для одностраничных, которые занимают больше времени, чем 500 миллисекундного льготного периода.
PageSpeed Insights показывает как воспринимаемые пользователя CLS из URL в своем разделе «обнаружить, что испытывают ваши реальные пользователи», так и в разделе Lab Lab Lab Load в своем разделе «Проблемы с диагностикой». Различия между этими значениями, вероятно, являются результатом пост-нагрузки CLS.
![PageSpeed Insights, показывающие данные на уровне URL, выделяющие реального пользователя CLS, который значительно больше, чем у маяка CLS](https://web.developers.google.cn/static/articles/optimize-cls/image/screenshot-pagespeed-ins-1b9715cccc402.png?hl=ru)
Определите проблемы с нагрузкой CLS
Когда CLS CLS CRUX и Lighthouse в целом выровняются, это обычно указывает на то, что нагрузка CLS была обнаружена, которая была обнаружена маяком. В этом случае Lighthouse поможет с двумя аудитами, чтобы предоставить больше информации об изображениях, вызывающих CLS из -за отсутствующей ширины и высоты, а также перечислит все элементы, которые сдвинулись для загрузки страницы вместе с их вкладом CLS. Вы можете увидеть эти аудиты, фильтраруя на аудитах CLS:
![Скриншот маяка, показывающий аудиты CLS, предоставляющие больше информации, чтобы помочь вам определить и решить проблемы CLS](https://web.developers.google.cn/static/articles/optimize-cls/image/lighthouse-screenshot-sho-1c6eeefdc4b1b.png?hl=ru)
Панель Performance в Devtools предоставляет огромную информацию о сдвигах макета:
![Записи смены макета отображаются на панели Performance Chrome Devtools.](https://web.developers.google.cn/static/articles/optimize-cls/image/devtools-cls-debugging.png?hl=ru)
Layout Shift
. Нажатие Diamonds показывает анимацию сдвига и детали на сводной панели.Сдвиги макета выделены в треке смены макета . Группы фиолетовых линий превращаются в кластеры смены с бриллиантами, показывающими индивидуальные сдвиги в этом кластере. Размер алмаза пропорционален размеру сдвига, что позволяет оттачивать самые большие сдвиги.
Нажатие на смену показывает всплывающее окно с анимацией сдвига и выделяет элементы смены в фиолетовом виде.
Кроме того, сводное представление для записи Layout Shift
включает в себя время начала, оценку сдвига, а также элементы сдвинулись. Это особенно полезно, чтобы получить более подробную информацию о проблемах нагрузки CLS, поскольку это легко воспроизводить с помощью профиля производительности перезагрузки.
Это также ссылается на проницательность виновников смены макета, отображаемой на панели Insights слева, которая показывает общее количество CLS вверху, а также возможные причины сдвигов макета.
Определить проблемы CLS после нагрузки
Разногласия между баллами CLS CRUX и Lighthouse часто указывают на CLS после получения нагрузки. Эти сдвиги могут быть сложными для отслеживания без полевых данных. Информацию о сборе данных полевых данных см. В полевых элементах CLS Elements .
Вид в живых метрик на панели производительности позволяет вам взаимодействовать со страницей и отслеживать оценку CLS, чтобы идентифицировать взаимодействия, вызывая большие макет.
![Записи смены макета отображаются на экране Live Metrics of Chrome Devtools Performance Panel.](https://web.developers.google.cn/static/articles/optimize-cls/image/live-metrics-cls.png?hl=ru)
В качестве альтернативы использованию DevTools вы можете просмотреть свою веб -страницу, когда записывая смены макета, используя наблюдатель производительности, вставленную в консоль.
После установки мониторинга смены вы можете попытаться воспроизвести любые проблемы CLS после загрузки. CLS часто случается, пока пользователь прокручивается через страницу, когда ленивый загруженный контент полностью загружается без зарезервированного места для нее. Сдвиг контента, когда пользователь удерживает указатель на него, является еще одной общей причиной CLS после загрузки. Любое сдвиг контента во время любого из этих взаимодействий считается неожиданным, даже если это происходит в течение 500 миллисекунд.
Для получения дополнительной информации см. Смена макета отладки .
После того, как вы определили любые общие причины CLS, режим пользовательского потока TimesPans также может использоваться для обеспечения того, чтобы типичные пользовательские потоки не регрессировали, внедряя сдвиги макета.
Измерить элементы CLS в поле
Мониторинг CLS в полевых условиях может быть неоценимым при определении того, в каких обстоятельствах возникает CLS, и сузить возможные причины. Как и большинство лабораторных инструментов, полевые инструменты измеряют только те элементы, которые смещались, но обычно предоставляет достаточно информации для определения причины. Вы также можете использовать полевые измерения CLS, чтобы определить, какие проблемы являются самым высоким приоритетом для исправления.
Библиотека web-vitals
имеет функции атрибуции , которые позволяют вам собирать эту дополнительную информацию. Для получения дополнительной информации см. Производительность отладки в этой области . Другие поставщики рома также начали собирать и представлять эти данные аналогично.
Общие причины CLS
После того, как вы определили причины CLS, вы можете начать работу над решением проблем. В этом разделе мы покажем некоторые из наиболее распространенных причин для CLS и того, что вы можете сделать, чтобы избежать их.
Изображения без измерений
Всегда включайте атрибуты width
и размера height
на ваши изображения и элементы видео. В качестве альтернативы оставьте необходимое пространство с помощью CSS aspect-ratio
или аналогичного. Этот подход гарантирует, что браузер может выделить правильное количество места в документе, когда изображение загружается.
![Отчет Маяка, показывающий, что до/после удара на совокупный сдвиг макета после установки размеров на изображениях](https://web.developers.google.cn/static/articles/optimize-cls/image/lighthouse-report-showing-9556bbb060b37.png?hl=ru)
История 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 имеет высоту 360px, ширина составляет 360 x (16/9) = 640px
- Если Puppy.jpg имеет ширину 640px, высота составляет 640 x (9/16) = 360px
Знание соотношения сторон для изображения позволяет браузеру рассчитать и зарезервировать достаточно места для высоты и связанной области.
Современная лучшая практика для установки размеров изображений
Поскольку современные браузеры устанавливают соотношение сторон по умолчанию изображений на основе 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 обрабатывается, а не с листом стиля пользовательского агента по умолчанию (см. Этот пост для глубокого погружения в почему ), поэтому значение отображается немного по-другому. Например, Chrome отображает его в разделе «Стили» панели элемента:
img[Attributes Style] {
aspect-ratio: auto 640 / 360;
}
Safari ведет себя так же, используя источник стиля атрибутов HTML . Firefox вообще не отображает этот расчетный aspect-ratio
на панели инспектора , но использует его для макета.
auto
часть предыдущего кода важна, потому что она заставляет измерения изображения переопределить соотношение сторон по умолчанию после загрузки изображения. If the image dimensions are different, this still causes some layout shift after the image loads, but this ensures the image aspect ratio is still used when it becomes available, in case the HTML is incorrect. Even if the actual aspect ratio is different from the default, it still causes less layout shift than the 0x0 default size of an image with no dimensions provided.
For a fantastic deep-dive into aspect ratio with further thinking around responsive images, see jank-free page loading with media aspect ratios .
If your image is in a container, you can use CSS to resize the image to the width of the container. We set height: auto;
to avoid using a fixed value for the image height.
img {
height: auto;
width: 100%;
}
What about responsive images?
When working with responsive images , srcset
defines the images you allow the browser to select between and what size each image is. To ensure <img>
width and height attributes can be set, each image should use the same aspect ratio.
<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"
/>
Your images' aspect ratios can also change depending on your art direction . For example, you may want to include a cropped shot of an image for narrow viewports, and display the full image on desktop:
<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, and Safari now support setting width
and height
on the <source>
elements within a given <picture>
element:
<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>
Ads, embeds, and other late-loaded content
Images aren't the only type of content that can cause layout shifts. Ads, embeds, iframes, and other dynamically injected content can all cause content appearing after them to shift down, increasing your CLS.
Ads are one of the largest contributors to layout shifts on the web. Ad networks and publishers often support dynamic ad sizes. Ad sizes increase performance and revenue due to higher click rates and more ads competing in the auction. Unfortunately, this can lead to a suboptimal user experience due to ads pushing visible content you're viewing down the page.
Embeddable widgets allow you to include portable web content on your page, such as videos from YouTube, maps from Google Maps, and social media posts. However, these widgets often aren't aware of how large their contents are before they load. As a result, platforms offering embeds don't always reserve space for their widgets, which causes layout shifts when they finally load.
The techniques for dealing with these are all similar. The major differences are how much control you have over the content that will be inserted. If this is inserted by a third-party like an ad partner, you may not know the exact size of content that will be inserted, nor be able to control any layout shifts happening within those embeds.
Reserve space for late-loading content
When placing late-loading content in the content flow, layout shifts can be avoided by reserving the space for them in the initial layout.
One approach is to add a min-height
CSS rule to reserve space or—for responsive content such as ads, for example—use the aspect-ratio
CSS property in a similar manner to the way browsers automatically use this for images with dimensions provided.
You may need to account for subtle differences in ad or placeholder sizes across form factors using media queries.
For content that may not have a fixed height, like ads, you might not be able to reserve the exact amount of space needed to eliminate the layout shift entirely. If a smaller ad is served, a publisher can style a larger container to avoid layout shifts, or choose the most likely size for the ad slot based on historical data. The downside to this approach is that it increases the amount of blank space on the page.
You can instead set the initial size to the smallest size that will be used, and accept some level of shift for larger content. Using min-height
, as suggested previously, allows the parent element to grow as necessary while reducing the impact of layout shifts, compared to the 0px default size of an empty element.
Try to avoid collapsing the reserved space by showing a placeholder if, for example, no ad is returned. Removing the space set aside for elements can cause just as much CLS as inserting content.
Place late-loading content lower in the viewport
Dynamically injected content closer to the top of the viewport usually causes greater layout shifts than content injected lower in the viewport. However, injecting content anywhere in the viewport still causes some shift. If you can't reserve space for injected content, we recommend placing it later on the page to reduce the impact on its CLS.
Avoid inserting new content without a user interaction
You've probably experienced layout shifts due to UI that pops-in at the top or bottom of the viewport when you're trying to load a site. Similar to ads, this often happens with banners and forms that shift the rest of the page's content:
If you need to display these types of UI affordances, reserve sufficient space in the viewport for it in advance (for example, using a placeholder or skeleton UI) so that when it loads, it does not cause content in the page to surprisingly shift around. Alternatively, ensure the element is not part of the document flow by overlaying the content where this makes sense. See the Best practices for cookie notices post for more recommendations on these types of components.
In some cases adding content dynamically is an important part of user experience. For example, when loading more products to a list of items or when updating live feed content. There are several ways to avoid unexpected layout shifts in those cases:
- Replace the old content with the new content within a fixed size container or use a carousel and remove the old content after the transition. Remember to disable any links and controls until the transition has completed to prevent accidental clicks or taps while the new content is coming in.
- Have the user initiate the load of new content, so they are not surprised by the shift (for example with a "Load more" or "Refresh" button). It's recommended to prefetch the content before the user interaction so that it shows up immediately. As a reminder, layout shifts that occur within 500 milliseconds of user input are not counted towards CLS.
- Seamlessly load the content offscreen and overlay a notice to the user that it's available (for example, with a "Scroll to top" button).
![Examples of dynamic content loading without causing unexpected layout shifts from Twitter and the Chloé website](https://web.developers.google.cn/static/articles/optimize-cls/image/examples-dynamic-content-4d11ddda2fa94.png?hl=ru)
Анимации
Changes to CSS property values can require the browser to react to these changes. Some values, such as box-shadow
and box-sizing
, trigger re-layout, paint, and composite. Changing the top
and left
properties also cause layout shifts, even when the element being moved is on its own layer. Avoid animating using these properties.
Other CSS properties can be changed without triggering re-layouts. These include using transform
animations to translate, scale, rotate, or skew elements.
Composited animations using translate
can't impact other elements, and so don't count toward CLS. Non-composited animations also don't cause re-layout. To learn more about which CSS properties trigger layout shifts, see High-performance animations .
Web fonts
Downloading and rendering web fonts is typically handled in one of two ways before the web font is downloaded:
- The fallback font is swapped with the web font, incurring a Flash of Unstyled Text (FOUT).
- "Invisible" text is displayed using the fallback font until a web font is available and the text is made visible (FOIT—flash of invisible text).
Both approaches can cause layout shifts . Even if the text is invisible, it's still laid out using the fallback font, so when the web font loads, the text block and the surrounding content shift in the same way as for the visible font.
The following tools can help you minimize shifting of text:
-
font-display: optional
can avoid a re-layout as the web font is only used if it is available by the time of initial layout. - Ensure the appropriate fallback font is used. For example, using
font-family: "Google Sans", sans-serif;
will ensure the browser'ssans-serif
fallback font is used while"Google Sans"
is loaded. Not specifying a fallback font using justfont-family: "Google Sans"
will mean the default font is used, which on Chrome is "Times"—a serif font which is a worse match than the defaultsans-serif
font. - Minimize the size differences between the fallback font and the web font using the new
size-adjust
,ascent-override
,descent-override
, andline-gap-override
APIs as detailed in the Improved font fallbacks post. - The Font Loading API can reduce the time it takes to get necessary fonts.
- Load critical web fonts as early as possible using
<link rel=preload>
. A preloaded font will have a higher chance to meet the first paint, in which case there's no layout shifting.
Read Best practices for fonts for other font best practices.
Reduce CLS by ensuring pages are eligible for the bfcache
A highly effective technique for keeping CLS scores low is to ensure your web pages are eligible for the back/forward cache (bfcache).
The bfcache keeps pages in browsers memory for a short period after you navigate away so if you return to them, then they will be restored exactly as you left them. This means the fully loaded page is instantly available—without any shifts which may be normally seen during load due to any of the reasons given earlier.
While this does potentially still mean the initial page load encounters layout shifts, when a user goes back through pages they are not seeing the same layout shifts repeatedly. You should always aim to avoid the shifts even on the initial load, but where that is more tricky to resolve fully, you can at least reduce the impact by avoiding them on any bfcache navigations.
Back and forward navigations are common on many sites. For example, returning to a contents page, or a category page, or search results.
When this was rolled out to Chrome , we saw noticeable improvements in CLS .
The bfcache is used by default by all browsers, but some sites are ineligible for the bfcache due to a variety of reasons. Read the bfcache guide for more details on how to test and identify any issues preventing bfcache usage to ensure you are making full use of this feature to help your overall CLS score for your site.
Заключение
There are a number of techniques to identify and improve CLS as detailed earlier in this guide. There are allowances built into Core Web Vitals, so even if you cannot eliminate CLS completely, using some of these techniques should allow you to reduce the impact. This will hopefully allow you to stay within those limits, creating a better experience for your website's users.