cumulative layout shift как исправить
Почему у вас проблемы от высокого CLS и как их исправить
Почему у вас проблемы от высокого CLS и как их исправить
Проблемы с CLS могут повлечь за собой просадку сайта в поисковой выдаче Google. Почему? Дело в том, что Cumulative Layout Shift или совокупный сдвиг вёрстки — одна из ключевых метрик оценки технической оптимизации сайтов в Google.
Суть в том, что любые элементы на странице не должны произвольно менять своё положение в процессе загрузки. Это выглядит не очень красиво и посетитель может промахнуться по кнопке, как на видео ниже.
Чем больше суммарная площадь таких «прыгающих» элементов и чем дальше они «прыгают», тем хуже будет метрика CLS. В идеале она должна быть равна нулю.
В сентябре 2020 года наша команда разработки окончательно победила Cumulative Layout Shift — контент больше не смещается при загрузке. Некоторые проблемы с CLS всё ещё остались, но 75-й перцентиль за 7 дней нулевой:
KPI команды разработки Tproger по Core Web Vitals — данные по внутренней аналитической системе Tproger
По таблице видно, что у нас завышена задержка первого ввода (First Input Delay) на мобильных и опасный тренд по времени отрисовки контента (Largest Contentful Paint) — над этим мы поработаем. Google, однако, считает, что проблем нет уже сейчас:
Ключевые показатели скорости загрузки сайта tproger.ru на мобильных по данным Google PSI
Ключевые показатели скорости загрузки сайта tproger.ru на десктопе по данным Google PSI
Поделюсь ключевыми приёмами по работе над избавлением от сдвигов контента. В нашем случае 90% проблем решилось довольно просто и свелось к трём правилам.
Приём для решения проблем с CLS #1
Если размеры элемента известны заранее, то их надо прописать явно. Например, блок счётчика комментариев, закладок и лайков у нас подгружается динамически, но высота иконок известна заранее и её можно прямо задать в CSS. 
Приём для решения проблем с CLS #2
Если вы загружаете контент после «скелета» страницы, то вставляйте на место контента плейсхолдер с высотой 100vh, который будет удерживать подвал вне экрана. Когда контент подтянется, удалите плейсхолдер. Пример: страница вакансий.
Приём для решения проблем с CLS #3
Отображайте динамически подгружаемые блоки в том порядке, в котором они не смещают другие блоки. Либо дождитесь загрузки всех блоков и покажите их одновременно. Пример: у нас на главной в правом сайдбаре на десктопе.
18 сентября в 10:00, Онлайн, Беcплатно
Для диагностики удобно использовать DevTools в Google Chrome. Установите эмуляцию медленного Интернет-соединения и поставьте галку Layout Shift Regions на вкладке Rendereing. Либо используйте отладчик Performance, недавно он научился выделять области со сдвигами контента.
Как оптимизировать CLS: сдвиги макета страницы, которые мешают пользователям
В статье:
Представьте, что вы читаете статью онлайн, но на странице что-то внезапно меняется и вы теряете место, на котором остановились. Или еще хуже — хотите нажать на кнопку и отказаться от предложения, как страница сама сдвигается и вы попадаете на кнопку «Скачать».
Из-за сместившихся кнопок пользователь промахнулся
В большинстве случаев это раздражает, а в некоторых может и нанести ущерб — к примеру, если из-за сдвига кнопки вы соглашаетесь что-то купить или оформить ненужную подписку.
Такой нестабильный сайт может потерять часть пользователей, потому что с ним невозможно удобно работать. И, к сожалению, это частая проблема сайтов. Разберемся, как ее решать.
Причины внезапных сдвигов на странице
Неожиданные сдвиги содержимого обычно случаются из-за асинхронной загрузки ресурсов или динамического добавления элементов DOM над существующими на странице элементами.
Если добавить до расположения контента, который смотрит пользователь, асинхронно загружающееся видео, изображение, шрифт, который отображается больше или меньше, чем его запасной вариант, или сторонний виджет, меняющий размер, при загрузке этих элементов контент ниже может сдвинуться.
Дело в том, что функционирование сайта в процессе разработки отличается от того, что в итоге воспринимают пользователи. Персонализированный и сторонний контент часто ведет себя по-разному. При разработке тестовые изображения часто уже находятся в кэше браузера разработчика, а локальные вызовы API выполняются быстро и задержки незаметны.
Решить проблему поможет измерение того, как часто сдвиги макета происходят у реальных пользователей.
CLS — показатель визуальной стабильности сайта
Сдвиг макета происходит каждый раз, когда видимый элемент изменяет свое положение от одного визуализируемого кадра к другому.
Визуальная стабильность сайта количественно измеряется показателем Cumulative Layout Shift. CLS — это совокупный сдвиг макета. Показатель входит в перечень трех главных метрик оценки пользовательского опыта — Core Web Vitals.
CLS помогает оценить, как часто пользователи сталкиваются с неожиданными сдвигами. Он измеряет общую сумму всех индивидуальных оценок сдвига макета для каждого неожиданного сдвига, который происходит в течение всего срока службы страницы.
Чем ниже показатель CLS, тем лучше.
Сайты должны стремиться к тому, чтобы CLS не превышал значение 0,1. Хороший показатель, если не меньше 75% сессий, сегментированных по мобильным и настольным устройствам, не превышают это значение.
Шкала CLS
Как измерить CLS
Инструмент Chrome User Experience Report собирает данные по пользователям для метрик Core Web Vitals, включая CLS. Эти данные используют два инструмента, которые доступны рядовому пользователю:
Есть еще вариант — проверить скорость сайта в инструменте от PR-CY. Он проанализирует процесс загрузки, разложит его по этапам и даст советы по улучшению каждого. Работает бесплатно онлайн.
Фрагмент результатов
Не все сдвиги макета — это плохо
На сайтах и в приложениях элементы меняются в зависимости от действий пользователя. Он ввел данные в поисковую строку и появились подсказки, кликнул по ссылке в названии и подгрузилась карточка с описанием, щелкнул по кнопке и появилась дополнительная кнопка для окончательного согласия. Если ожидаемые пользователей окна и кнопки появляются сразу в ответ на действие — сдвиг макета допустим.
Если действие пользователя запускает какой-то сетевой запрос, требующий времени на загрузку, лучше освободить место под элементы, которые должны появиться, и отобразить значок загрузки. Так пользователь поймет, что сейчас что-то появится, и не будет пытаться кликать куда-то еще во время ожидания.
Как отобразить новые элементы и не сбить с толку пользователя
Контент, который резко и неожиданно появляется на странице, может сбить с толку, ведь пользователь уже решил куда-то кликнуть. Анимация и переходы — хороший способ отобразить новые элементы на странице так, чтобы пользователь понял, что происходит, и был к ним готов.
Свойство CSS позволяет анимировать элементы, не вызывая сдвигов макета:
Что делать, чтобы улучшить CLS и избавиться от внезапных сдвигов
На большинстве сайтов можно избежать всех неожиданных сдвигов макета благодаря этим правилам:
Расскажите в комментариях, о чем еще вам было бы интересно почитать в блоге по теме навигации и юзабилити или по другим темам о развитии сайтов.
Как оптимизировать показатель LCP — ускоряем загрузку контента для пользователей
В статье:
В мае Google определил новый способ оценки пользовательского опыта. Показатель называется Google Core Vitals, он связан со скоростью загрузки сайта и появления на нем контента.
Google Core Vitals состоит из трех метрик:
Про CLS у нас есть подробный материал «Как оптимизировать CLS: сдвиги макета страницы, которые мешают пользователям», в этой статье поговорим о показателе LCP и способах его улучшить.
Что такое LCP — показатель Largest Contentful Paint
Largest Contentful Paint — время рендеринга самого большого элемента, видимого в области просмотра пользователем — изображения, текстового блока, видео или другого контента. Учитываются те размеры элементов, которые видны пользователю. Если элемент частично скрыт за областью просмотра, эти невидимые части не берутся в расчет.
Самый аккуратный способ определить время отображения основного содержимого страницы — использовать API Largest Contentful Paint (LCP).
Как это происходит:
При загрузке страницы контент может меняться, поэтому каждый раз, когда появляется новый большой элемент, браузер отправляет PerformanceEntry c типом largest-contentful-paint. Когда пользователь начинает взаимодействовать со страницей, отправка метрики прекращается. Нужное значение — время самого последнего отправленного события.
Отрисовка самого большого элемента может происходить и до полной загрузки страницы. К примеру, логотип Instagram — самый большой элемент, он загружается относительно рано и остается самым большим элементом, пока постепенно отображается остальной контент.
Самый большой элемент загрузился до конца загрузки остального контента
В следующем примере самый большой элемент изменяется по мере загрузки содержимого — сначала им был текст, потом самым большим объектом стала картинка.
Самый большой элемент менялся по мере загрузки
Как измерить LCP: инструменты веб-мастера
Инструменты, которые позволяют измерить показатель LCP:
Проверка скорости сайта от PR-CY бесплатно анализирует загрузку страницы по ключевым параметрам, проверяет десктопное и мобильное отображение. Сервис дает рекомендации и прикидывает, сколько можно сэкономить, если их внедрить на сайте.
Интерфейс проверки скорости сайта
Какой показатель LCP считается хорошим
Нужно стремиться, чтобы отрисовка самого большого контента происходила не дольше, чем за 2,5 секунды после начала загрузки страницы. Тогда пользователям будет удобно работать на сайте.
Инструменты для измерения показывают сводный показатель LCP для 75 % посещений URL.
Как улучшить показатель LCP
На LCP влияют четыре фактора:
Рассмотрим эти факторы, сопутствующие им проблемы и способы оптимизировать показатели.
Медленный ответ сервера
Чем быстрее браузер получает контент с сервера, тем быстрее загрузка страницы и тем лучше показатель LCP.
Вы можете улучшить TTFB — время до первого байта. Какие есть способы:
Другой вариант — dns-prefetch для ускорения поиска DNS, подходит для браузеров, которые не поддерживают preconnect.
Можно использовать оба варианта для разных браузеров.
Блокировка рендеринга JavaScript и CSS
Браузер преобразовывает разметку HTML в дерево DOM, а потом уже отображает контент. Он не сможет продолжать работу, если обнаружит ресурсы, блокирующие рендеринг: внешние таблицы стилей link rel=»stylesheet» и сценарии JavaScript script src=»https://pr-cy.ru/news/p/main.js». Чтобы ускорить загрузку содержимого страницы, нужно отложить все некритические JavaScript и CSS.
Неиспользуемый JavaScript и CSS можно найти с помощью Chrome DevTools на вкладке Coverage.
Поиск неиспользуемого CSS и JavaScript
Найденный неиспользуемый CSS можно вообще удалить или переместить в другую таблицу стилей, если он нужен на других страницах сайта.
Если CSS не нужен для начального рендеринга, можно использовать loadCSS для асинхронной загрузки файлов, который использует rel=»preload» и onload.
Как улучшилось LCP после откладывания некритического CSS
Критический CSS можно включить в head, если он нужен для верхней части страницы. Встраивание стилей таким образом позволит не делать двусторонний запрос для получения критического CSS.
Как автоматизировать добавление встроенных стилей на сайт:
Для JavaScript также можно использовать асинхронную загрузку.
Еще полезна минификация или минимизация кода CSS и JavaScript — удаление символов, которые не нужны браузеру для чтения кода. Минификаторы удаляют отступы, интервалы, разделители и комментарии, файл по сути не меняется, но становится легче.
Список бесплатных инструментов для минимизации CSS, JS, HTML-файлов есть в статье.
Как улучшилось LCP после минификации CSS
Долгая загрузка ресурсов
Время, которое требуется контенту для загрузки, влияет на LCP, так что имеет смысл поработать с элементами на странице.
Рендеринг на стороне клиента
Есть сайты, которые работают через рендеринг на стороне клиента (CSR) — то есть рендеринг страниц происходит в браузере с использованием JavaScript, все обрабатывается на стороне клиента, а не на сервере.
Основной недостаток такого подхода в том, что по мере роста сайта, добавления новых библиотек и кода начинает страдать скорость загрузки и отображения контента для пользователя.
В некоторых случаях можно использовать предварительный рендеринг. В таком способе рендер выполняется в headless браузере типа Chrome, который генерирует статические файлы HTML, а их уже подставляют в ответ сервера.
Предварительный рендеринг не нагружает реальный сервер и позволяет улучшить показатель LCP, но не подходит для страниц с изменяемым или с введенным пользователем контентом.
Как улучшилось LCP после предварительного рендеринга
Скорость загрузки ресурса на компьютере и мобильных устройствах можно проверить в Анализе сайта от PR-CY. Он проверяет сайт по 70+ параметрам, включая скорость загрузки и отображения контента, анализирует, что реализовано на сайте для ускорения, и дает советы, что еще можно улучшить.
Проверка скорости в Анализе сайта
Некоторые подробные тесты и графики, а также проверка внутренних страниц и отслеживание позиций доступны на платных тарифах. Но мы даем новым пользователям неделю на бесплатный тест сервиса — оставайтесь, если понравится!
В комментариях напишите, о чем еще вам было бы интересно почитать по теме оптимизации и работы с техническими характеристиками сайта.
Cumulative Layout Shift (CLS)
Накопительный сдвиг макета (Cumulative Layout Shift, далее — CLS) — важный, ориентированный на пользователя, показатель для измерения его визуальной стабильности, он помогает количественно оценить, как часто пользователи сталкиваются с неожиданными сдвигами макета. Низкий уровень CLS говорит о том, что страница выглядит восхитительно.
Вы когда-нибудь читали онлайн-статью, когда на странице что-то внезапно меняется? Без предупреждения текст перемещается и вы теряете это место. Или, что ещё хуже: собираетесь нажать на ссылку или кнопку, но за мгновение до того, как ваш палец или курсор мыши приземлится — БУМ — ссылка перемещается, и вы в конечном итоге нажимаете что-то другое!
В большинстве случаев подобные вещи вызывают раздражение, но иногда они могут нанести реальный ущерб.
Видео, демонстрирующее, негативные последствия нестабильности макета.
Неожиданное перемещение содержимого страницы обычно происходит из-за асинхронной загрузки ресурсов или динамического добавления DOM-элементов на страницу над уже существующим содержимым. Причиной может быть изображение или видео с неизвестными размерами, шрифт, который отображается крупнее или меньше, чем его запасной вариант, сторонние объявления или виджеты, которые динамически изменяют размер.
Ещё сильнее эта проблема усугубляется тем, что функционирование сайта в процессе разработки может сильно отличаться от того, как его воспринимают пользователи. Персонализированный или сторонний контент часто ведёт себя иначе, чем при разработке, например: тестовые изображения обычно уже находятся в кэше браузера разработчика, а вызовы API, которые выполняются локально, получают ответ сервера слишком быстро и возможные задержки не заметны.
Показатель накопительного сдвига макета (CLS — Cumulative Layout Shift) помогает решить эту проблему, измеряя, как часто это происходит у реальных пользователей.
Что такое CLS?
Cumulative Layout Shift измеряет общую сумму всех индивидуальных оценок сдвига макета для каждого неожиданного сдвига макета, который происходит в течение всего времени жизни страницы.
Сдвиг макета происходит каждый раз, когда видимый элемент изменяет свое положение от одного кадра отрисовки к другому (см. ниже подробности о том, как рассчитываются индивидуальные оценки сдвига макета).
Что для CLS — хороший результат?
Чтобы обеспечить комфорт для пользователей, сайты должны стремиться к тому, чтобы показатель CLS не превышал 0.1. Чтобы убедиться в достижении этой цели для большинства пользователей, хорошим порогом для измерения будет 75-й перцентиль загрузки страниц, сегментированный по мобильным и настольным устройствам.
Подробности о сдвигах макета
Сдвиги макета определяются Layout Instability API (API нестабильности макета), который возвращает записи layout-shift о сдвиге макета каждый раз, когда элемент, видимый в области просмотра, меняет своё положение (например, его верхнюю и левую координаты для writing mode по умолчанию) между двумя кадрами. Такие элементы считаются нестабильными.
Обратите внимание, что сдвиги макета происходят только тогда, когда существующие элементы меняют своё положение. Если новый элемент добавляется в DOM-модель или существующий элемент меняет размер — это не будет считаться сдвигом макета до тех пор, пока изменения не заставляет другие видимые элементы менять своё положение.
Оценка сдвига макета
Чтобы вычислить оценку сдвига макета, браузер смотрит на размеры области просмотра (viewport) и перемещение нестабильных элементов в ней между двумя визуализированными кадрами. Оценка сдвига макета будет продуктом двух показателей этого движения: доля воздействия и доля расстояние (оба определены ниже).
Доля воздействия
Доля воздействия (impact fraction) измеряет, как нестабильные элементы влияют на область просмотра между двумя кадрами.
Объединение видимых областей всех нестабильных элементов для предыдущего кадра и текущего кадра, в виде доли от общей площади области просмотра, будет долей воздействия для текущего кадра.
Доля расстояния
Другая часть выражения оценки сдвига макета измеряет расстояние, на которое нестабильные элементы переместились относительно области просмотра. Доля расстояния — это наибольшее расстояние, на которое любой нестабильный элемент переместился в кадре (по горизонтали или вертикали), деленное на наибольший размер окна просмотра (ширина или высота, в зависимости от того, что больше).
Первоначально оценка сдвига макета рассчитывалась только на основе доли воздействия. Доля расстояния была введена, чтобы избежать чрезмерного результата, когда большие элементы смещаются на небольшую величину.
В следующем примере показано, как добавление содержимого к существующему элементу влияет на оценку сдвига макета:
Кнопка «Click Me!» добавляется в нижнюю часть серого поля с черным текстом, который толкает зеленое поле с белым текстом вниз (и частично за пределы области просмотра).
В этом примере серый прямоугольник меняет размер, но его начальное положение не меняется, поэтому он не будет нестабильным элементом.
Кнопки «Click Me!» ранее не было в DOM, поэтому ее исходное положение также не изменится.
Этот пример иллюстрирует несколько нестабильных элементов:
В первом кадре на картинке выше представлены четыре результата запроса к API для животных, отсортированных в алфавитном порядке. Во втором кадре в отсортированный список добавляется еще несколько результатов.
Первый элемент в списке («Cat») не меняет своё начальное положение между кадрами, поэтому он стабилен. Точно так же новые элементы, добавленные в список, ранее не были в DOM, поэтому их начальное положение также не меняется. Остальные элементы «Dog», «Horse» и «Zebra» меняют свои исходные позиции, что делает их нестабильными элементами.
Опять же, красные пунктирные прямоугольники представляют собой объединение этих трех нестабильных элементов до и после областей, которые в этом случае составляют около 38% площади области просмотра (доля воздействия 0.38 ).
Ожидаемые и неожиданные сдвиги макета
Не все сдвиги в макете — это плохо. Фактически, многие динамические веб-приложения часто меняют начальное положение элементов на странице.
Изменения макета по инициативе пользователя
Сдвиг макета плох только в случае, когда пользователь этого не ожидает. С другой стороны, сдвиги макета, которые происходят в ответ на действия пользователя (клик по ссылке, нажатие кнопки, ввод в поле поиска и т.д.), как правило, допустимы, если сдвиг происходит настолько близко к взаимодействию, что взаимосвязь будет понятна для пользователя.
Например, если взаимодействие с пользователем запускает сетевой запрос, выполнение которого может занять некоторое время, лучше сразу освободить место и показать индикатор загрузки, чтобы избежать неприятного сдвига макета после завершения запроса. Если пользователь не понимает, что что-то загружается, или не знает, когда ресурс будет готов, он может попытаться кликнуть что-нибудь ещё во время ожидания.
Внимание! Флаг hadRecentInput будет возвращать значение только для дискретных событий: касание, клик или нажатие клавиши. Непрерывные взаимодействия: прокрутка, перетаскивание или жесты сжатия и масштабирования — не считаются «недавним вводом». Дополнительные сведения см. в спецификации Layout Instability.
Анимации и переходы
Если всё сделано правильно, анимация и переходы будут отличным способом обновить контент на странице, не вызывая негативные реакции у пользователя. Контент, который резко и неожиданно перемещается на странице, почти всегда создает неудобства для пользователей. Но контент, который постепенно и естественно перемещается из одной позиции в другую, часто может помочь пользователю лучше понять: что происходит и что делать между изменениями состояния.
CSS-свойство transform позволяет анимировать элементы, не вызывая сдвигов макета:
Как измерить CLS
CLS можно измерять в лабораторных условиях с использованием инструментов для имитации загрузки страницы в согласованной контролируемой среде или в полевых на реальных пользователях, которые по-честному загружают страницу и взаимодействуют с ней.
Тестирование производительности в лабораторных условиях имеет важное значение при разработке новых функций. До того, как они будут выпущены в производство, не получится измерить их характеристики на реальных пользователях. Поэтому тестирование этих функций при разработке, перед выпуском в прод — лучший способ обнаружить и предотвратить снижение производительности.
С другой стороны, хотя лабораторное тестирование является разумным показателем производительности, оно не обязательно отражает то, как разные пользователи будут воспринимать сайт вживую. Производительность сайта может сильно различаться в зависимости от возможностей устройства пользователя и условий работы его сети, а также варьироваться в зависимости от того, взаимодействует ли (или как) пользователь со страницей.
Более того, загрузка страниц не может быть детерминированной. Например, сайты, загружающие персонализированный контент или рекламу, могут иметь совершенно разные характеристики производительности от пользователя к пользователю. Лабораторный тест не выявит этих различий.
Единственный способ по-настоящему узнать, как сайт работает для пользователей — это измерять производительность в реальных условиях, когда живые пользователи его загружают и взаимодействуют с ним. Этот тип измерения обычно называется мониторингом реального пользователя (Real User Monitoring).
Инструменты
В полевых условиях
В лабораторных условиях
Измерение CLS с помощью JavaScript
Предупреждение: этот код показывает, как регистрировать и накапливать записи о неожиданных сдвигах макета. Измерить CLS в JavaScript несколько сложнее. Подробности см. ниже.
Далее будут перечислены различия между тем, что сообщает API, и тем, как рассчитывается метрика.
Различия между метрикой и API
В дополнение к этим исключениям, CLS имеет дополнительную сложность из-за того, что он ведет измерения весь срок жизни страницы:
Чтобы справиться с такими случаями, CLS следует сообщать каждый раз, когда страница находится в фоновом режиме, в дополнение к любому времени, когда она выгружается (события visibilitychange достаточно на оба этих сценария). А аналитическим системам, получающим эти данные, необходимо будет вычислить окончательное значение CLS на бэкэнде.
Вместо того, чтобы запоминать и самостоятельно разбираться со всеми этими случаями, разработчики могут использовать JavaScript-библиотеку web-vitals для измерения CLS, которая учитывает всё, что упомянуто выше:
Как улучшить CLS
Для большинства веб-сайтов можно избежать всех неожиданных сдвигов в макете, придерживаясь нескольких руководящих принципов: