Cumulative layout shift: зачем нужно, как проверить и настроить для SEO

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

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

Что именно измеряет Cumulative Layout Shift

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

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

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

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

Как CLS связан с SEO, а как — нет

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

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

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

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

Сначала найдите источник сдвига, а не гонитесь за цифрой

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

Поэтому диагностику удобнее делить на два уровня.

Полевые данные показывают, что происходило у реальных пользователей. Их можно смотреть в отчёте Core Web Vitals Search Console и в пользовательских данных PageSpeed Insights. Именно здесь важен 75-й перцентиль.

Лабораторная диагностика нужна уже для поиска причины. В Chrome DevTools можно записать загрузку или взаимодействие со страницей и посмотреть события Layout Shift, затронутые элементы и возможные причины.

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

Что чаще всего ломает визуальную стабильность

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

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

У изображения стоит указывать размеры, сохраняя адаптивное масштабирование:

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

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

Размеры здесь нужны не для жёсткой фиксации изображения в 1200×675 пикселей, а чтобы браузер знал его пропорции ещё до загрузки файла.

Баннеры, формы, реклама и встроенные блоки

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

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

Веб-шрифты

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

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

Анимации

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

Практический сценарий: CLS плохой только у реальных посетителей

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

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

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

1. заранее выделить место под форму либо изменить способ её появления так, чтобы она не сдвигала основной поток;
2. передавать браузеру размеры или пропорции изображения;
3. повторить сценарий на мобильной ширине, включая прокрутку;
4. после публикации отслеживать реальные данные, а не считать один успешный лабораторный тест окончательным доказательством.

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

Как понять, что работа действительно закончена

Не требуется добиваться математического нуля на каждой странице. Целевой ориентир Core Web Vitals — не выше 0,1 на 75-м перцентиле посещений.

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

Если CLS уже находится в хорошем диапазоне, пользователь не сталкивается с заметными скачками, а единственная цель дальнейшей работы — превратить 0,05 в 0,00 ради красивого отчёта, приоритет обычно стоит отдать более существенной проблеме сайта.

Cumulative Layout Shift полезен именно как диагностическая метрика: он заставляет смотреть не на абстрактную «скорость», а на устойчивость интерфейса глазами реального пользователя. Для SEO разумная задача — устранить заметные неожиданные сдвиги и добиться хорошего диапазона Core Web Vitals, не превращая одну техническую цифру в обещание роста позиций.