Почему нестабильная верстка ухудшает позиции: как работает CLS в Яндексе?

История появления и развитие метрики CLS

CLS (Cumulative Layout Shift) — это метрика визуальной стабильности страницы, которая измеряет, насколько сильно элементы смещаются в процессе загрузки. Чем выше значение, тем хуже пользовательский опыт: кнопки «прыгают», текст съезжает, пользователь нажимает не туда.

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

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

CLS появился как часть инициативы Core Web Vitals, которую Google анонсировал в 2020 году. Идея была в том, чтобы дать разработчикам и SEO-специалистам конкретные, измеримые ориентиры качества страницы — не абстрактное «сайт должен быть удобным», а три числа с порогами. CLS стал одним из трёх ключевых показателей наряду с метриками скорости загрузки и отзывчивости интерфейса. Согласно документации web.dev, хорошим считается значение CLS не выше 0,10; результат выше 0,25 расценивается как неудовлетворительный web.dev — документация по метрике CLS, 2024.

С момента появления метрика прошла несколько уточнений. Первоначальная формула суммировала все сдвиги за весь жизненный цикл страницы — это создавало проблему для длинных сессий: пользователь читает статью 10 минут, прокручивает страницу, и каждое небольшое смещение накапливается. В результате длинные страницы с хорошей версткой получали высокие (плохие) значения CLS просто из-за продолжительности сессии. Формулу пересмотрели: теперь учитываются только смещения в пределах отдельных «окон» активности, что делает показатель справедливее для многостраничных материалов и интернет-магазинов с бесконечной прокруткой.

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

На практике появление CLS изменило приоритеты фронтенд-разработки: резервирование места под изображения, явные размеры для рекламных блоков, контроль за шрифтами, которые подгружаются асинхронно и сдвигают текст — всё это из «хорошего тона» превратилось в измеримое требование с конкретным числовым порогом.

Как работает CLS: технический разбор механики

CLS (кумулятивный сдвиг макета, Cumulative Layout Shift) считается не как одиночное событие, а как сумма всех неожиданных смещений элементов за время жизни страницы. Каждый сдвиг — это произведение двух величин: доли видимой области, которую занимал элемент до смещения, и расстояния, на которое он переместился относительно высоты вьюпорта. Результат суммируется по всем сдвигам — отсюда и «кумулятивный».

Пример: баннер занимает 40% высоты экрана и при загрузке изображения сдвигается вниз на 25% высоты вьюпорта. Один сдвиг даёт 0.40 × 0.25 = 0.10. Если таких сдвигов несколько — они суммируются. Порог «хорошо» — 0.1 и ниже, порог «плохо» — выше 0.25 web.dev — документация по метрике CLS, 2024 год.

На практике сдвиги провоцируют четыре класса элементов. Изображения без явно заданных атрибутов width и height: браузер не резервирует место под них, и при загрузке они «раздвигают» контент ниже. Рекламные блоки, которые вставляются в DOM после первого рендера и занимают место, которого не было в исходной вёрстке. Шрифты, подключаемые через @font-face без font-display: swap или optional: когда кастомный шрифт загружается, текст перерисовывается и смещает соседние блоки. Наконец, динамические блоки — всплывающие уведомления, чаты, куки-баннеры — которые появляются поверх уже отрисованного контента.

Мобильные устройства дают более высокий CLS по той же вёрстке — и это не баг, а следствие физики. Вьюпорт на смартфоне уже и короче: тот же баннер занимает большую долю экрана, и его смещение на то же абсолютное расстояние в пикселях даёт пропорционально больший вклад в итоговый score. Кроме того, мобильные соединения медленнее загружают шрифты и изображения, растягивая временное окно, в котором сдвиги могут произойти. Десктоп с широким экраном и быстрым интернетом часто показывает CLS ниже 0.1 при том же коде, тогда как мобильная версия того же сайта — выше 0.25.

CLS не изолирован от остальных метрик Core Web Vitals. Долгий LCP (отрисовка крупнейшего элемента) означает, что страница дольше находится в состоянии «неполной загрузки» — и за это время успевают произойти дополнительные сдвиги. Высокий INP (задержка реакции на ввод) часто сопровождается тяжёлыми скриптами, которые блокируют рендер и откладывают окончательную отрисовку блоков — снова окно для сдвигов. На практике сайт с плохим LCP почти всегда имеет проблемный CLS: оба симптома указывают на одну причину — неоптимизированную загрузку ресурсов.

Ключевые факторы и параметры, влияющие на CLS

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

• Изображения и медиафайлы без явных размеров. Браузер не знает, сколько места зарезервировать под картинку, пока она не загрузится. В результате текст и кнопки ниже сдвигаются вниз в момент, когда изображение наконец появляется. Решение прямолинейное: атрибуты width и height в теге <img> или CSS-свойство aspect-ratio для контейнера. Браузер резервирует место заранее — сдвига нет.
• Асинхронно загружаемый контент без зарезервированного места. Баннеры, рекламные блоки, виджеты обратного звонка, чаты поддержки — всё это загружается после основного HTML. Если под них не выделено фиксированное пространство в вёрстке, они буквально «вдавливают» уже отрисованный контент. Особенно критична реклама: рекламная сеть возвращает блок с размером, который заранее неизвестен странице. Фиксированный контейнер-плейсхолдер с минимальной высотой устраняет этот класс сдвигов.
• Веб-шрифты и FOUT/FOIT. Когда браузер загружает кастомный шрифт, он сначала рендерит текст системным шрифтом (или скрывает его), а после загрузки переключается. Разница в метриках шрифтов — другая высота строки, другая ширина символов — смещает весь текстовый блок. Директива font-display: optional или swap в сочетании с предзагрузкой (<link rel="preload">) сокращает время переключения до минимума. Ещё лучше — использовать size-adjust для системного fallback-шрифта, чтобы метрики совпадали.
• Динамически внедряемые элементы над существующим контентом. Это куки-баннеры, уведомления о скидках, поп-апы с подпиской, которые появляются поверх или внутри потока документа. Если элемент появляется в DOM после первой отрисовки и занимает место в потоке — он толкает всё нижестоящее. Элементы, позиционированные через position: fixed или position: absolute, из потока выбиваются и на CLS не влияют — это принципиальное различие.
• Сторонние скрипты и виджеты. Виджеты соцсетей, карты, формы, счётчики — они загружаются из внешних доменов со своей задержкой. Размер итогового блока зависит от ответа внешнего сервера. Контейнер с фиксированными размерами и overflow: hidden — минимальная защита. Если виджет не критичен для первого экрана, его загрузку стоит отложить через loading="lazy" или IntersectionObserver.

Отдельная история — анимации и CSS-трансформации. Свойства transform и opacity не вызывают сдвигов макета: браузер обрабатывает их на уровне композитора, не перерисовывая поток. Анимации через top, left, margin или width — вызывают. Это разграничение нетривиально: внешне анимация выглядит одинаково, но одна портит CLS, другая нет.

Порог оценки зафиксирован в документации: значение до 0.1 считается хорошим, выше 0.25 — плохим web.dev — CLS (2024). Всё между этими значениями требует улучшения. На практике сайты с высоким CLS чаще всего грешат сразу несколькими факторами из списка выше — баннером без плейсхолдера плюс шрифтом без предзагрузки плюс виджетом чата в потоке документа.

Как проверить и измерить CLS: инструменты и методы

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

• PageSpeed Insights. Главный инструмент для быстрой диагностики. Вводите URL — получаете и лабораторный результат (через Lighthouse), и полевые данные из реальных сессий пользователей (Chrome UX Report). Порог «хорошо» по CLS — 0.1 и ниже, «плохо» — выше 0.25 web.dev — CLS, 2024. Если полевые данные хуже лабораторных, значит проблема проявляется только в реальных условиях — например, при медленном соединении или на мобильных устройствах.
• Lighthouse в браузере. Откройте Chrome DevTools → вкладка Lighthouse → запустите аудит. Инструмент покажет итоговый CLS-балл и список элементов, которые смещались в процессе загрузки. Удобен для локальной отладки: можно сразу видеть, какой именно блок вызывает сдвиг, и проверять исправление прямо в браузере.
• Яндекс.Метрика → Вебвизор. Полевые данные в российском контексте — Метрика. Вебвизор записывает реальные сессии пользователей, и в записях видно, как страница «прыгает» в момент загрузки. Это не числовой CLS-балл, но визуальное подтверждение проблемы, которое убеждает убедительнее любой цифры. Путь: Яндекс.Метрика → Вебвизор → фильтр по устройству «мобильный» → просматривайте сессии на страницах с высоким показателем отказов.
• Яндекс Вебмастер → Качество сайта. Раздел отображает сигналы о пользовательском опыте, которые Яндекс учитывает при ранжировании. Прямого CLS-балла там нет, но аномалии в поведенческих показателях — высокий отказ, короткое время на странице — косвенно указывают на страницы с нестабильной вёрсткой.
• Screaming Frog SEO Spider. Полезен для массовой диагностики: краулер собирает список страниц, которые можно затем пакетно прогнать через PageSpeed Insights API. Это рабочий способ приоритизировать аудит на крупном сайте — сначала проверить страницы с наибольшим трафиком или коммерческие разделы.

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

При интерпретации данных обращайте внимание не только на итоговый балл, но и на конкретные элементы в отчёте Lighthouse — раздел «Избегайте больших сдвигов макета». Там перечислены конкретные DOM-элементы с вкладом в итоговый CLS. Элемент с наибольшим вкладом — первая точка входа для исправления. Нередко один блок — например, баннер без зарезервированной высоты — даёт большую часть итогового балла.

Реальные примеры влияния CLS на позиции в Яндексе

Прямой корреляции «CLS вырос → позиции упали на N строк» в Яндексе нет: поисковик не публикует алгоритмические веса отдельных сигналов. Однако механизм влияния прослеживается через поведенческие факторы — и он достаточно конкретный, чтобы его зафиксировать на практике.

Когда кнопка «Купить» сдвигается в момент тапа, пользователь либо случайно нажимает не туда, либо уходит. Оба сценария дают Яндексу поведенческий сигнал: страница не отвечает ожиданиям. Высокий показатель отказов, короткое время на сайте, возврат в выдачу — всё это Яндекс учитывает при ранжировании, и нестабильная верстка систематически ухудшает эти метрики.

Порог, ниже которого CLS считается приемлемым — 0.1. Значения выше 0.25 — явная проблема, которая видна пользователям невооружённым глазом web.dev — статья о метрике CLS, 2024 год. На практике большинство сайтов с CLS выше 0.25 имеют заметные смещения на мобильных устройствах — именно там, где Яндекс оценивает поведение основной части аудитории.

Разберём, как нестабильная верстка проявляется в разных типах сайтов и какие последствия это создаёт для позиций:

Картина меняется, если сравнить два похожих сайта в одной нише — с CLS 0.05 и CLS 0.31. При прочих равных (схожая ссылочная масса, сопоставимый контент) сайт с нестабильной версткой стабильно проигрывает в поведенческих метриках: пользователи возвращаются в выдачу быстрее, и Яндекс со временем перераспределяет трафик в пользу более «удобного» конкурента. Это не мгновенный эффект — просадка накапливается за недели.

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

Частые ошибки и подводные камни при оптимизации CLS

Оптимизация CLS — одна из тех задач, где ошибки совершают не новички, а опытные разработчики, которые «знают, как это работает». Проблема не в незнании инструментов, а в неочевидных ловушках, которые стандартные чек-листы не покрывают.

• Изображения с атрибутами width/height, но без aspect-ratio в CSS. Разработчик добавляет width="800" height="600" в HTML — и думает, что задача решена. Браузер действительно резервирует место. Однако если CSS-правило позже перезаписывает размеры (например, img { width: 100%; height: auto; } без явного aspect-ratio), резервирование ломается на мобильных экранах. Картинка отображается с другим соотношением сторон, и контент ниже сдвигается. Решение: явный aspect-ratio: 4/3 в CSS вместе с атрибутами в HTML — тогда браузер корректно рассчитает высоту при любой ширине контейнера.
• Сторонние скрипты и рекламные блоки без зарезервированного места. Рекламный блок загружается асинхронно — это правильно с точки зрения производительности. Но если под него не зарезервировано место через min-height или фиксированный контейнер, он появляется поверх контента и толкает всё вниз. Та же история с виджетами чатов, всплывающими баннерами и динамическими блоками отзывов. Частый сценарий: баннер появляется через 2-3 секунды после загрузки страницы, когда пользователь уже начал читать — CLS фиксирует максимальный сдвиг именно в этот момент.
• Недооценка разрыва между мобильной и десктопной версией. Лабораторный тест в PageSpeed Insights показывает хороший результат на десктопе — и оптимизацию закрывают. На мобильных устройствах картина другая: шрифты загружаются медленнее, контейнеры перестраиваются под узкий экран, а скрипты выполняются дольше из-за слабого процессора. CLS на мобильных стабильно выше, чем на десктопе, — и именно мобильный трафик составляет большую часть аудитории большинства сайтов. Проверяйте оба варианта отдельно, не переносите десктопный результат на мобильный автоматически.
• Неправильная интерпретация данных инструментов. PageSpeed Insights показывает отличный CLS — а реальные пользователи жалуются на прыгающий интерфейс. Причина: лабораторный тест не воспроизводит все пользовательские сценарии. Сдвиги, которые происходят при скролле, после взаимодействия с элементом или при медленном соединении, в синтетическом тесте не видны. Согласно документации web.dev — Cumulative Layout Shift, хорошим считается CLS не выше 0.1, плохим — выше 0.25. Но эти пороги — ориентир для полевых данных, а не для единичного лабораторного замера. Если лабораторный тест даёт 0.05, а реальные данные — 0.18, доверяйте реальным данным. Для их сбора подходит Яндекс.Метрика с записью сессий: тепловые карты (Heatmap) и вебвизор покажут, где пользователи теряются из-за сдвигов.
• Исправление CLS только на главной странице. Аудит часто начинается и заканчивается главной. Между тем карточки товаров в интернет-магазине, страницы статей с динамически подгружаемыми блоками и лендинги с тяжёлыми медиаблоками дают CLS не хуже, а иногда хуже главной. Проверяйте шаблоны, а не отдельные URL: если проблема в шаблоне карточки — она воспроизводится на тысячах страниц одновременно.

Пошаговый план по улучшению CLS на сайте

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

1. Измерьте текущее состояние — отдельно лабораторные и полевые данные. Запустите PageSpeed Insights для двух-трёх ключевых страниц: главной, типовой карточки товара и одной посадочной. Зафиксируйте значение CLS для каждой. Хороший порог — не выше 0,1; при значении выше 0,25 сдвиги уже ощутимы для пользователя web.dev — Cumulative Layout Shift (2024). Параллельно откройте Яндекс.Метрику → «Вебвизор»: запись реальных сессий покажет, на каком шаге пользователь сталкивается с прыжком контента. Это разные данные — не подменяйте одно другим.
2. Проставьте явные размеры всем изображениям и видео. Пройдитесь по шаблонам через Screaming Frog: фильтр «Images» → колонки «Missing Alt Text» и «Missing Width/Height». Все теги <img> без атрибутов width и height — потенциальные источники CLS. После добавления размеров добавьте в CSS правило aspect-ratio для адаптивных изображений: это страхует от ситуации, когда HTML-атрибуты есть, но CSS их перекрывает через width: 100% без сохранения пропорций.
3. Оптимизируйте загрузку шрифтов. Подключите шрифты через font-display: swap или optional — браузер сначала покажет системный шрифт, а потом заменит его без сдвига контента. Если используете Google Fonts или другой внешний хостинг шрифтов, перенесите файлы на собственный сервер: внешний запрос добавляет задержку и увеличивает вероятность FOUT (мигания текста), что провоцирует сдвиг.
4. Вынесите критические стили в <head>, отложите некритические. Стили, влияющие на контент первого экрана (высота хедера, размеры баннера, отступы блоков), должны загружаться синхронно. Всё остальное — через rel="preload" или media-атрибут. Если CSS подгружается асинхронно и применяется после отрисовки — браузер перерисовывает блоки, и CLS растёт.
5. Изолируйте сторонние виджеты и рекламные блоки. Баннеры, чат-виджеты и блоки рекомендаций — главные источники непредсказуемых сдвигов, потому что загружаются асинхронно и меняют размер после отрисовки страницы. Зарезервируйте под каждый блок фиксированный контейнер с минимальной высотой через CSS (min-height). Для рекламных блоков выделяйте место заранее контейнером-плейсхолдером — даже если блок не загрузился, пространство остаётся зарезервированным.
6. Повторно измерьте CLS после каждого изменения. Не вносите все правки разом и не проверяйте результат в конце. После каждого блока изменений — новый прогон PageSpeed Insights и сравнение с базовым замером. Это позволяет точно установить, какое именно изменение дало эффект, и не тратить время на откат пакетных правок. Если CLS остался выше 0,1 после исправления изображений и шрифтов — причина, скорее всего, в динамически вставляемом контенте: баннерах, попапах или lazy-loaded блоках, которые появляются через JavaScript после первой отрисовки.

Заключение

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

Устранение визуальной нестабильности — задача с конечным списком причин: изображения без размеров, шрифты без font-display, баннеры без зарезервированного блока. Последовательный технический аудит сайта закрывает их системно, а не точечно.