Узнайте о наших планах по улучшению показателя «Совокупное изменение макета» и поделитесь с нами своим мнением.
Совокупный сдвиг макета (CLS) — это показатель, измеряющий визуальную стабильность веб-страницы. Этот показатель называется совокупным сдвигом макета, поскольку оценка каждого отдельного сдвига суммируется на протяжении всего срока службы страницы.
Хотя все изменения макета неприятны для пользователей, они увеличиваются на страницах, которые открыты дольше. Вот почему команда Chrome Speed Metrics решила улучшить показатель CLS, чтобы он был более нейтральным к времени, проведенному на странице.
Важно, чтобы эта метрика учитывала взаимодействие с пользователем на протяжении всего времени существования страницы, поскольку мы обнаружили, что пользователи часто испытывают негативные впечатления после загрузки при прокрутке или навигации по страницам. Но мы слышали опасения по поводу того, как это влияет на долгоживущие страницы — страницы, которые пользователь обычно открывает в течение длительного времени. Существует несколько типов страниц, которые, как правило, остаются открытыми дольше; Одними из наиболее распространенных являются приложения для социальных сетей с бесконечной прокруткой и одностраничные приложения.
Внутренний анализ долгоживущих страниц с высокими показателями CLS показал, что большинство проблем вызвано следующими закономерностями:
- Бесконечные скроллеры, перемещающие контент по мере прокрутки пользователем.
- Обработчикам ввода требуется более 500 мс для обновления пользовательского интерфейса в ответ на взаимодействие с пользователем, без каких-либо шаблонов-заполнителей или скелетов.
Хотя мы призываем разработчиков улучшать взаимодействие с пользователем, мы также работаем над улучшением этого показателя и собираем отзывы о возможных подходах.
Как мы решим, что новая метрика лучше?
Прежде чем погрузиться в метрический дизайн, мы хотели убедиться, что мы оценили наши идеи на широком спектре реальных веб-страниц и вариантов использования. Для начала мы провели небольшое исследование пользователей.
Сначала мы записали видео и следы Chrome 34 посещений пользователей различными веб-сайтами. При выборе пользовательского пути мы ориентировались на несколько вещей:
- Множество различных типов сайтов, таких как новостные и торговые сайты.
- Разнообразные действия пользователя, такие как начальная загрузка страницы, прокрутка, навигация по одностраничным приложениям и взаимодействие с пользователем.
- Разнообразие как по количеству, так и по интенсивности смен индивидуальной планировки на сайтах.
- Небольшой негативный опыт работы с сайтами, если не считать изменений в макете.
Мы попросили 41 нашего коллегу посмотреть по два видео одновременно, оценивая, какой из пары лучше с точки зрения смены макета. На основе этих рейтингов мы создали идеализированный порядок ранжирования сайтов. Результаты рейтинга пользователей подтвердили наши подозрения, что наших коллег, как и большинство пользователей, действительно расстраивают изменения макета после загрузки, особенно во время прокрутки и навигации по одностраничным приложениям. Мы увидели, что некоторые сайты обеспечивают гораздо лучший пользовательский опыт во время этих действий, чем другие.
Поскольку мы записывали следы Chrome вместе с видео, у нас были все подробности отдельных изменений макета в каждом пути пользователя. Мы использовали их для расчета значений показателей для каждой идеи для каждого пользовательского пути. Это позволило нам увидеть, как каждый вариант метрики оценивал пути пользователя и насколько каждый из них отличался от идеального рейтинга.
Какие идеи метрик мы тестировали?
Стратегии окон
Часто страницы имеют несколько сдвигов макета, тесно связанных друг с другом, поскольку элементы могут меняться несколько раз по мере того, как новый контент поступает по частям. Это побудило нас опробовать методы группировки смен. Для этого мы рассмотрели три подхода к созданию окон:
- Переворачивающиеся окна
- Раздвижные окна
- Окна сеанса
В каждом из этих примеров страница имеет изменения макета разной степени тяжести с течением времени. Каждая синяя полоса представляет собой одно изменение макета, а длина представляет оценку этого изменения. Изображения иллюстрируют, как различные стратегии управления окнами группируют изменения макета с течением времени.
Переворачивающиеся окна
Самый простой подход — просто разбить страницу на окна одинакового размера. Это так называемые поворотные окна. Выше вы заметили, что четвертая панель действительно выглядит так, как будто ее следует сгруппировать во втором переворачивающемся окне, но поскольку все окна имеют фиксированный размер, вместо этого она находится в первом окне. Если есть небольшие различия во времени загрузки или взаимодействия пользователя на странице, одни и те же сдвиги макета могут приходиться на разные стороны границ окна.
Раздвижные окна
Подход, который позволяет нам видеть больше возможных группировок одинаковой длины, заключается в постоянном обновлении потенциального окна с течением времени. На изображении выше показано одно скользящее окно за раз, но мы могли бы просмотреть все возможные скользящие окна или их подмножество, чтобы создать метрику.
Окна сеанса
Если бы мы хотели сосредоточиться на выявлении областей страницы с резкими изменениями макета, мы могли бы начинать каждое окно со сдвигом и продолжать его увеличивать, пока не встретим разрыв заданного размера между изменениями макета. Этот подход группирует изменения макета вместе и игнорирует большую часть неменяющегося пользовательского опыта. Одна из потенциальных проблем заключается в том, что если в макете нет пробелов, метрика, основанная на окнах сеансов, может неограниченно расти, как и текущая метрика CLS. Поэтому мы опробовали это и с максимальным размером окна.
Размеры окон
Этот показатель может давать очень разные результаты в зависимости от размера окон, поэтому мы попробовали несколько разных размеров окон:
- Каждая смена как отдельное окно (без окон)
- 100 мс
- 300 мс
- 1 секунда
- 5 секунд
Подведение итогов
Мы попробовали множество способов суммировать различные окна.
процентили
Мы рассмотрели максимальное значение окна, а также 95-й процентиль, 75-й процентиль и медиану.
Средний
Мы посмотрели на среднее значение окна.
Бюджеты
Мы задались вопросом, может быть, существует какой-то минимальный показатель изменения макета, который пользователи не заметят, и мы могли бы просто посчитать сдвиги макета сверх этого «бюджета» в оценке. Итак, для различных потенциальных значений «бюджета» мы рассмотрели процент сдвигов сверх бюджета и общий балл сдвигов сверх бюджета.
Другие стратегии
Мы также рассмотрели множество стратегий, в которых не использовались окна, например общий сдвиг макета, разделенный на время на странице, и среднее значение N наихудших отдельных сдвигов.
Первые результаты
В целом мы протестировали 145 различных определений метрик , основанных на вариациях приведенных выше идей. Для каждой метрики мы ранжировали все действия пользователя по их баллам по метрике, а затем ранжировали метрики по тому, насколько они близки к идеальному рейтингу.
Чтобы получить базовый уровень, мы также ранжировали все сайты по их текущему баллу CLS. CLS заняла 32-е место вместе с 13 другими стратегиями, поэтому она была лучше, чем большинство вариантов стратегий, описанных выше. Чтобы результаты были значимыми, мы также добавили три случайных порядка. Как и ожидалось, случайный порядок показал худшие результаты, чем все протестированные стратегии.
Чтобы понять, не подгоняемся ли мы к набору данных, после анализа мы записали несколько новых видеороликов и трассировок смещения макета, проранжировали их вручную и увидели, что рейтинги метрик очень похожи для нового набора данных и исходного.
В рейтинге выделялись несколько различных стратегий.
Лучшие стратегии
Когда мы составили рейтинг стратегий, мы обнаружили, что три типа стратегий возглавляют список. Каждый из них имел примерно одинаковую производительность, поэтому мы планируем продолжить более глубокий анализ всех трех. Нам также хотелось бы услышать отзывы разработчиков, чтобы понять, есть ли какие-то факторы, не связанные с пользовательским опытом, которые нам следует учитывать при выборе между ними. (Информацию о том, как оставить отзыв, см. ниже.)
Высокие процентили длинных окон
Несколько стратегий работы с окнами хорошо работали с окнами больших размеров:
- 1-секундные раздвижные окна
- Окна сеанса ограничены 5 секундами с перерывом в 1 секунду.
- Окна сеансов не ограничены с интервалом в 1 секунду.
Все они получили очень хорошие оценки как в 95-м процентиле, так и в максимальном.
Но для таких больших размеров окон мы были обеспокоены использованием 95-го процентиля — часто мы рассматривали только 4-6 окон, а использование 95-го процентиля — это большая интерполяция. Неясно, что делает интерполяция с точки зрения значения метрики. Максимальное значение намного понятнее, поэтому мы решили продолжить проверку максимума.
Среднее значение окон сеансов с длинными перерывами
Усреднение оценок всех незакрытых окон сеанса с 5-секундными перерывами между ними показало очень хорошие результаты. Эта стратегия имеет несколько интересных особенностей:
- Если на странице нет промежутков между изменениями макета, она превращается в одно длинное окно сеанса с точно таким же рейтингом, что и текущий CLS.
- Эта метрика не учитывала время простоя напрямую; он смотрел только на сдвиги, происходящие на странице, а не на моменты времени, когда страница не смещалась.
Высокие процентили коротких окон
Максимальное скользящее окно в 300 мс получило очень высокий рейтинг, а также 95-й процентиль. Для окна меньшего размера процентильная интерполяция меньше, чем для окон большего размера, но нас также беспокоили «повторяющиеся» скользящие окна — если набор сдвигов макета происходит в течение двух кадров, существует несколько окон длительностью 300 мс, которые их включают. Взять максимум гораздо понятнее и проще, чем взять 95-й процентиль. Итак, мы снова решили продолжить проверку максимума.
Стратегии, которые не сработали
Стратегии, которые пытались оценить «средний» опыт времени, проведенного как без изменений макета, так и со сдвигами макета, показали очень плохие результаты. Ни одно из медианных или 75-процентных сводок какой-либо оконной стратегии не дало сайтам хорошего рейтинга. Сумма макетов также не изменилась с течением времени.
Мы оценили ряд различных «бюджетов» на предмет приемлемых изменений макета:
- Процент изменений макета, превышающих определенный бюджет. Для различных бюджетов все они имели довольно низкие оценки.
- Средний сдвиг планировки выше некоторого избытка. Большинство вариантов этой стратегии показали плохие результаты, но среднее превышение в течение длинной сессии с большим гэпом показало почти такой же результат, как и среднее значение для сессионных окон с длинными гэпами. Мы решили остановиться только на последнем варианте, потому что он проще.
Следующие шаги
Крупномасштабный анализ
Мы реализовали перечисленные выше основные стратегии в Chrome, чтобы иметь возможность получать данные о реальном использовании гораздо большего числа веб-сайтов. Мы планируем использовать аналогичный подход к ранжированию сайтов на основе их показателей для проведения более масштабного анализа:
- Ранжируйте все сайты по CLS и по каждому новому кандидату на метрику.
- Какие сайты оцениваются CLS и каждым кандидатом наиболее по-разному? Находим ли мы что-нибудь неожиданное, просматривая эти сайты?
- Каковы самые большие различия между новыми кандидатами на метрики? Являются ли какие-либо различия преимуществами или недостатками конкретного кандидата?
- Повторите приведенный выше анализ, но распределив по времени, затрачиваемому на загрузку каждой страницы. Видим ли мы ожидаемое улучшение длительной загрузки страниц с приемлемым сдвигом макета? Видим ли мы какие-либо неожиданные результаты для недолговечных страниц?
Отзывы о нашем подходе
Нам бы хотелось получить отзывы веб-разработчиков об этих подходах. Некоторые вещи, которые следует учитывать при рассмотрении новых подходов:
Что не меняется
Хотим уточнить, что с новым подходом многие вещи не изменятся:
- Ни одна из наших идей по метрике не меняет способ расчета показателей смещения макета для отдельных кадров , а только способ суммирования нескольких кадров. Это означает, что API JavaScript для смещения макета останется прежним, а базовые события в трассировках Chrome, которые используют инструменты разработчика, также останутся прежними, поэтому прямоугольники смещения макета в таких инструментах, как WebPageTest и Chrome DevTools, будут продолжать работать таким же образом.
- Мы продолжим усердно работать над тем, чтобы разработчикам было легко адаптировать метрики, включив их в библиотеку web-vitals , документируя на web.dev и сообщая о них в наших инструментах для разработчиков, таких как Lighthouse.
Компромиссы между метриками
Одна из лучших стратегий суммирует окна смены макета как среднее значение, а остальные сообщают о максимальном окне. Для страниц, которые открыты очень долгое время, среднее значение, вероятно, будет более репрезентативным, но в целом разработчикам, вероятно, будет проще действовать в одном окне — они могут регистрировать, когда это произошло, элементы, которые сместились, и скоро. Нам бы хотелось узнать, что важнее для разработчиков.
Вам легче понять скользящие или сеансовые окна? Важны ли для вас различия?
Как оставить отзыв
Вы можете опробовать новые метрики смещения макета на любом сайте, используя наши примеры реализации JavaScript или нашу вилку расширения Core Web Vitals .
Отправьте отзыв в нашу группу Google Web-vitals-feedback , указав в строке темы «[Layout Shift Metrics]». Мы очень ждем вашего мнения!