CLS: почему элементы страницы неожиданно сдвигаются

Что считается сдвигом и как читать число

Cumulative Layout Shift оценивает неожиданные изменения положения видимых элементов. Учитываются размер затронутой области и расстояние перемещения. Это безразмерное число: запись 0,1 не означает 100 мс или 10 процентов времени загрузки. Его нельзя напрямую сравнить с секундами LCP либо задержкой INP.

CLS не является простой суммой всех сдвигов за всё посещение. Сдвиги объединяют в окна: между соседними событиями проходит менее 1 секунды, а продолжительность окна ограничена 5 секундами. Значением метрики становится наибольшая сумма сдвигов в одном таком окне. Это важно при чтении длинной записи с несколькими отдельными эпизодами нестабильности.

Для полевых Core Web Vitals хорошим считается CLS не более 0,1 на 75-м перцентиле посещений. Значение свыше 0,1 до 0,25 требует улучшения, выше 0,25 считается плохим. Проверяют отдельно мобильные устройства и компьютеры. Порог относится к метрике, рассчитанной по правилам CLS, а не к ручной оценке «насколько сильно прыгнул блок».

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

Откуда берутся неожиданные перемещения

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

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

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

Почему лаборатория и CrUX расходятся

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

Если полевой результат относится ко всему origin, он не доказывает наличие одинаковой проблемы у каждого URL. CrUX и отчёты Search Console помогают выбрать направление проверки, а причину ищут на конкретных страницах. Отсутствие поля CLS не нужно заменять нулём: сначала выясните, почему измерение недоступно.

Как найти источник сдвига

1. Выберите страницу, размер экрана и сценарий. Запишите, когда возникает движение: при первом открытии, после ожидания, прокрутки или появления виджета.
2. Снимите профиль в Performance и найдите события сдвига. Посмотрите, какие элементы переместились и что появилось либо изменилось перед этим. Двигающийся блок не всегда сам создаёт проблему.
3. Повторите проверку с теми же условиями. Для изображений и шрифтов учитывайте кеш: уже загруженные ресурсы могут скрыть поведение первого посещения.
4. Сопоставьте события с разметкой и подключаемыми ресурсами. Для задачи сохраните кадр до и после сдвига, источник изменения и ожидаемое стабильное расположение.
5. После правки проверьте нужные ширины и поздние состояния. Убедитесь, что место зарезервировано корректно, а текст, кнопки и формы остаются доступными.

Какие изменения проверять

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

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

Как не получить формальное исправление

Низкий CLS после скрытия проблемного блока не доказывает, что страница стала лучше. Например, посетитель может потерять важное сообщение или кнопку. Оценивайте вместе стабильность, доступность содержимого и правильность пользовательского пути. Метрика помогает заметить проблему, но не выбирает за вас смысл интерфейса.

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

Как подтвердить изменение

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

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