CLS: что это, почему возникает сдвиг макета и как его исправить

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

Именно такие неожиданные перемещения оценивает CLS — Cumulative Layout Shift, одна из трёх основных метрик Core Web Vitals наряду с LCP и INP. В отличие от LCP и INP, CLS измеряется не в секундах: это безразмерная оценка визуальной стабильности страницы.

Как CLS считает сдвиг макета

CLS учитывает не каждое изменение страницы. Важен неожиданный сдвиг уже видимого элемента между двумя отрисованными кадрами.

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

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

В расчёте одного сдвига учитываются две характеристики:

layout shift score = impact fraction × distance fraction

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

Современный CLS не просто складывает все подобные события за бесконечно долгий сеанс. Сдвиги объединяются в короткие группы — session windows. Итоговым CLS становится группа с наибольшей суммой неожиданных сдвигов.

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

Какой CLS считается хорошим

Для Core Web Vitals используется следующая шкала:

CLS	Оценка
≤ 0,10	хорошо
> 0,10 и ≤ 0,25	требуется улучшение
> 0,25	плохо

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

Поэтому цель «добить CLS до абсолютного нуля любой ценой» редко оправдана. Сначала стоит убрать крупные и массовые сдвиги и добиться стабильного результата не выше 0,1.

Почему PageSpeed и реальные пользователи могут показывать разный CLS

CLS удобно проверять в PageSpeed Insights, Chrome DevTools и отчёте Core Web Vitals в Search Console, но эти инструменты отвечают на разные вопросы.

PageSpeed Insights может одновременно показывать полевые и лабораторные данные. Полевые данные основаны на Chrome UX Report и отражают реальные посещения за предыдущий период. Лабораторная часть запускает Lighthouse в контролируемых условиях и полезна прежде всего для поиска технической причины.

Отсюда типичная ситуация: лабораторный CLS равен почти нулю, а реальные данные остаются плохими.

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

В Chrome DevTools полезно смотреть Performance и дорожку Layout shifts. Она позволяет увидеть конкретный момент смещения и элементы, которые изменили положение.

Что чаще всего заставляет страницу «прыгать»

Изображения и видео без заранее известного размера

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

Надёжнее сразу передавать размеры:

<img
  src="photo.webp"
  width="1200"
  height="800"
  alt="Описание изображения"
>

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

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

Браузер получает соотношение сторон из width и height и может зарезервировать пространство ещё до загрузки файла.

Баннеры, виджеты, реклама и формы

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

Если размер известен приблизительно, контейнеру можно заранее выделить место:

.promo-slot {
  min-height: 280px;
}

Точное значение зависит от реального блока. Универсальные 280px копировать во все проекты не нужно: резерв должен соответствовать фактической геометрии элемента на конкретном брейкпоинте.

Шрифты

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

Здесь важно не только быстрее загрузить файл шрифта, но и подобрать близкий fallback. Для более точной компенсации существуют CSS-параметры метрик шрифта, включая size-adjust, ascent-override, descent-override и line-gap-override.

Анимации

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

Исправлять нужно причину, а не цифру

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

В DevTools при прокрутке обнаруживается сдвиг: над списком товаров спустя секунду появляется промоблок. Его высота заранее не зарезервирована, поэтому вся сетка товаров перемещается вниз.

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

Правильная последовательность здесь другая:

1. Подтвердить, какой элемент вызывает крупный сдвиг.
2. Определить его реальную высоту на нужных разрешениях.
3. Зарезервировать место до появления содержимого либо изменить способ показа блока.
4. Повторить сценарий в DevTools, включая прокрутку и другие действия пользователя.
5. После публикации следить за полевыми данными, чтобы убедиться, что проблема исчезла у реальных посетителей.

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

Как CLS связан с SEO

Здесь важно отделять официальный факт от слишком смелых SEO-обещаний.

Core Web Vitals используются системами ранжирования Google как часть общей оценки удобства страницы. Поэтому плохую визуальную стабильность нельзя считать полностью нейтральной для поиска.

Но из этого не следует формула «уменьшили CLS с 0,3 до 0,05 — получили рост на десять позиций». Google прямо указывает, что хорошие Core Web Vitals не гарантируют верхних позиций. Релевантная и полезная страница может ранжироваться выше более быстрой и стабильной страницы, если лучше отвечает на запрос.

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

Поэтому техническая задача формулируется проще: убрать заметные сдвиги ради нормального пользовательского опыта и привести Core Web Vitals к хорошему диапазону, а не пытаться получить «SEO-бонус» за идеальные сотые доли показателя.

Что проверить после исправления

После изменения страницы полезно пройти короткую проверку:

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

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