Улучшение совокупного изменения макета в Telegraph Media Group

За пару месяцев ведущему новостному сайту Великобритании удалось улучшить свой 75-й процентиль CLS на 250% с 0,25 до 0,1.

Chris Boakes

Проблема визуальной стабильности

Сдвиги макета могут быть очень разрушительными. В Telegraph Media Group (TMG) визуальная стабильность особенно важна, поскольку читатели преимущественно используют наши приложения для просмотра новостей. Если макет сместится во время чтения статьи, читатель, скорее всего, потеряет свое место. Это может быть разочаровывающим и отвлекающим опытом.

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

В TMG есть несколько команд, которые пишут код на стороне клиента:

• Основная инженерия. Внедрение сторонних решений для таких областей, как рекомендации по контенту и комментирование.
• Маркетинг. Запуск A/B-тестов, чтобы оценить, как наши читатели взаимодействуют с новыми функциями или изменениями.
• Реклама. Управление запросами на рекламу и предварительные ставки на рекламу.
• Редакция. Встраивание кода в статьи, такие как твиты или видео, а также в пользовательские виджеты (например, средство отслеживания случаев коронавируса).

Обеспечение того, чтобы каждая из этих команд не вызывала тряску макета страницы, может оказаться сложной задачей. Используя показатель «Совокупное изменение макета» для измерения того, как часто это происходит с нашими читателями, команды получили более глубокое представление о реальном пользовательском опыте и четкую цель, к которой нужно стремиться. В результате наш 75-й процентиль CLS улучшился с 0,25 до 0,1, а показатель проходного сегмента увеличился с 57% до 72%.

С чего мы начали

Используя информационные панели CrUX , мы смогли установить, что наши страницы смещались больше, чем нам хотелось бы.

В идеале мы хотели, чтобы как минимум 75% наших читателей получили «хороший» опыт, поэтому мы начали выявлять причины нестабильности макета.

Как мы измеряли изменения макета

Мы использовали комбинацию Chrome DevTools и WebPageTest , чтобы определить причину смещения макета. В DevTools мы использовали раздел «Опыт» на вкладке «Производительность» , чтобы выделить отдельные случаи изменения макета и то, как они повлияли на общую оценку.

WebPageTest показывает, где происходит сдвиг макета на временной шкале, когда выбран параметр «Выделить сдвиги макета».

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

Уменьшение сдвигов макета

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

Объявления

Рекламные объявления загружаются после первоначальной отрисовки с помощью JavaScript. Некоторые из контейнеров, в которые они загружались, не имели зарезервированной высоты.

Хотя мы не знаем точную высоту, мы можем зарезервировать место, используя наиболее распространенный размер рекламы, загруженной в слот.

В некоторых случаях мы неправильно оценили среднюю высоту рекламы. У планшетных ридеров слот разваливался.

Мы вернулись к слоту и отрегулировали высоту, чтобы использовать наиболее распространенный размер.

Изображений

Многие изображения на сайте загружаются отложенно, и для них зарезервировано место.

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

Простое добавление атрибутов ширины и высоты к изображениям гарантировало, что макет не сместится.

Заголовок

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

Перемещение заголовка в верхнюю часть разметки позволило странице отображаться без этого смещения.

Встраивает

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

Измерение воздействия

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

Затем мы сможем проверить результаты в наших данных RUM (предоставленных mPulse ), как только код достигнет рабочей среды.

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

Последние цифры, которые мы рассмотрели, относятся к данным RUM, которые собирает Google. Это особенно актуально сейчас, поскольку вскоре они окажут влияние на рейтинг страниц . Для начала мы использовали отчет Chrome UX Report как в ежемесячных данных уровня происхождения, доступных через панель управления CrUX , так и путем запроса BigQuery для получения исторических данных p75. Таким образом, мы легко смогли увидеть, что для всего трафика, измеренного CrUX, наш 75-й процентиль CLS улучшился на 250 % с 0,25 до 0,1, а наш проходной сегмент вырос с 57 % до 72 % .

Кроме того, мы смогли использовать API отчетов Chrome UX и создать несколько внутренних панелей мониторинга, разделенных на шаблоны.

Как избежать регрессии CLS

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

Если тест превысит бюджет, он отправит сообщение на канал Slack, чтобы мы могли выяснить причину. Мы также настроили еженедельные отчеты, поэтому, даже если шаблоны остаются в бюджете, мы знаем о любых изменениях, которые оказали негативное влияние.

Мы также планируем расширить наши бюджеты, чтобы использовать данные RUM, а также синтетические данные, используя mPulse для установки как статических предупреждений , так и потенциального обнаружения аномалий , которые информировали бы нас о любых необычных изменениях.

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

Заключение

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

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