Страница чаще всего прыгает, когда браузер уже показал контент, а затем получил изображение, шрифт, виджет или данные, которые изменили занятую область. Исправление начинают не с случайных правок CSS, а с записи момента сдвига и поиска элемента, после появления которого макет перестроился.
Короткий порядок такой: воспроизведите проблему в том же размере окна, запишите загрузку в Chrome DevTools, откройте самый заметный кластер Layout shifts, найдите затронутые элементы и проверьте, что появилось непосредственно перед сдвигом. Затем исправьте одну причину и повторите запись в тех же условиях.
Что показывает CLS и почему одного числа мало
CLS — безразмерная оценка неожиданных перемещений видимого контента. Хорошим ориентиром считается значение не выше 0,1, но само число не объясняет, какой блок виноват и почему он изменил положение.
Низкий результат в одном локальном запуске тоже не доказывает стабильность страницы у посетителей. Сдвиг может зависеть от ширины экрана, холодного кеша, скорости сети, доступности шрифта, рекламного ответа, авторизации или действий после загрузки. Поэтому сначала фиксируют сценарий, а уже затем сравнивают измерения.
Запишите перед проверкой:
- точный URL и размер окна;
- устройство или режим эмуляции;
- состояние кеша и авторизации;
- действие, после которого страница прыгает;
- какой блок сместился и что появилось перед ним.
Как найти элемент, который вызывает сдвиг
1. Воспроизведите проблему управляемо
Откройте страницу в отдельном окне и выберите один сценарий: первая загрузка, прокрутка, открытие меню или появление асинхронного блока. Не смешивайте несколько действий в одной проверке — иначе будет трудно связать изменение с причиной.
Если прыжок заметен только при первой загрузке, включите отключение кеша в DevTools и перезагрузите страницу. Если он появляется позже, начните запись, повторите нужное действие и остановите её после сдвига.
2. Запишите трассировку в панели Performance
В Chrome DevTools откройте Performance и запишите проблемный сценарий. На дорожке Layout shifts отдельные сдвиги отмечаются ромбами и объединяются в кластеры. Начните с кластера с наибольшим вкладом, а не с первого события на шкале.
Нажмите на кластер или отдельный сдвиг. В сводке будут видны время, оценка, затронутые элементы и возможные виновники. Наведение на событие помогает сопоставить запись с тем, что двигалось на экране.
Важно: затронутый элемент не всегда является причиной. Например, заголовок уехал вниз не из-за собственных стилей, а потому что над ним поздно появился баннер. Проверяйте соседние блоки, родительский контейнер и изменения DOM непосредственно перед событием.
3. Определите класс причины
Идите по наблюдаемому признаку, а не по списку популярных советов.
| Что видно в записи | Что проверить | Как подтвердить | |---|---|---| | После загрузки картинки текст уезжает вниз | Есть ли у изображения заранее известные размеры | Временно задайте width, height или aspect-ratio и повторите запись | | Над контентом появляется баннер, форма или виджет | Было ли зарезервировано место | Подставьте контейнер ожидаемого размера до загрузки данных | | После смены шрифта меняются переносы строк | Совпадают ли метрики резервного и веб-шрифта | Заблокируйте смену шрифта для теста и сравните трассировку | | Блок перестраивается после ответа API | Равен ли каркас итоговому содержимому | Сравните размеры состояния загрузки и готового блока | | Элемент движется во время анимации | Меняются ли свойства, влияющие на раскладку | Замените тестово движение на transform и сравните результат |
Такой тест должен быть временным и изолированным. Если сдвиг исчез, гипотеза подтверждена; после этого выбирайте устойчивое исправление для реальной вёрстки.
Частые причины и точечные исправления
Изображения, видео и iframe без размеров
Браузеру нужно знать будущую область медиа до загрузки файла. Укажите корректные атрибуты размеров или соотношение сторон, чтобы место было зарезервировано заранее. Для адаптивного изображения размеры должны задавать пропорцию, а CSS уже может уменьшать его по ширине контейнера.
Не ставьте одинаковую фиксированную высоту всем изображениям: это маскирует один сдвиг и создаёт обрезку или пустое место на других экранах.
Баннеры, реклама и сторонние виджеты
Если блок должен появиться внутри потока страницы, подготовьте для него контейнер до ответа внешнего сервиса. Когда итоговый размер заранее неизвестен, используйте обоснованный минимальный размер для конкретного места и проверьте крайние варианты содержимого.
Не вставляйте поздний блок над тем, что пользователь уже читает или собирается нажать. Для необязательного уведомления иногда безопаснее слой поверх страницы, но он не должен перекрывать управление и нарушать доступность.
Шрифты и переносы текста
При подмене системного шрифта веб-шрифтом строки могут стать длиннее или короче, а соседние блоки — сместиться. Сначала проверьте, действительно ли смена шрифта совпадает со сдвигом. Затем подберите близкий резервный шрифт, настройте загрузку критического файла и при необходимости выровняйте метрики шрифтов.
Одна только предзагрузка не гарантирует исправления: при медленной сети подмена всё равно может произойти позже, а слишком много предварительно загружаемых файлов конкурируют с важными ресурсами.
Асинхронный контент и клиентский JavaScript
Каркас загрузки должен занимать примерно ту же область, что и готовый блок. Если сначала выводится пустое состояние, а затем список добавляется перед основным контентом, сдвиг заложен в сам сценарий рендера.
Проверьте, какие классы, атрибуты и узлы меняются после ответа API. Полезно временно отключать по одному виджету: cookie-баннер, рекомендации, чат, рекламный слот. Так причина находится быстрее, чем при одновременной правке всех компонентов.
Анимации, меняющие раскладку
Анимация top, left, width, height или отступов может заставлять браузер заново рассчитывать расположение соседей. Для визуального перемещения обычно безопаснее transform, а для появления — opacity, если структура страницы уже занимает нужное место.
Это не универсальная замена: интерактивный блок всё равно должен оставаться доступным, не перекрывать элементы и корректно работать без анимации.
Как проверить исправление
Повторите тот же сценарий с тем же размером окна, состоянием кеша и ограничением сети. Сравните не только итоговый CLS, но и дорожку сдвигов: исчез ли нужный кластер, не появился ли новый и сохранилось ли поведение блока.
Сделайте несколько запусков для мобильной и широкой вёрстки. Затем проверьте страницу на реальных данных: локальная трассировка показывает конкретное воспроизведение, а полевые данные объединяют разные устройства и условия и не называют точный DOM-элемент.
Не считайте задачу закрытой, если сдвиг лишь стал незаметнее на вашем компьютере. Исправление должно заранее резервировать место или исключать неожиданное изменение раскладки в исходном сценарии.
Что делать после исправления CLS
Стабильность макета и доступность сайта — разные задачи. Трассировка браузера помогает найти визуальный сдвиг, а регулярная внешняя проверка нужна, чтобы заметить, когда критический URL вообще перестал отвечать.
Если после исправления вы хотите отдельно контролировать доступность страницы, добавьте её в мониторинг Web-Puls и настройте уведомления. Для CLS продолжайте использовать браузерную трассировку и полевые данные: один мониторинг HTTP не заменяет проверку поведения интерфейса.