За пару месяцев ведущему новостному сайту Великобритании удалось улучшить свой 75-й процентиль CLS на 250% с 0,25 до 0,1.
Проблема визуальной стабильности
Сдвиги макета могут быть очень разрушительными. В Telegraph Media Group (TMG) визуальная стабильность особенно важна, поскольку читатели преимущественно используют наши приложения для просмотра новостей. Если макет сместится во время чтения статьи, читатель, скорее всего, потеряет свое место. Это может быть разочаровывающим и отвлекающим опытом.
С инженерной точки зрения обеспечение того, чтобы страницы не смещались и не прерывали чтение, может быть сложной задачей, особенно когда области вашего приложения загружаются асинхронно и добавляются на страницу динамически.
В TMG есть несколько команд, которые пишут код на стороне клиента:
- Основная инженерия. Внедрение сторонних решений для таких областей, как рекомендации по контенту и комментирование.
- Маркетинг. Запуск A/B-тестов, чтобы оценить, как наши читатели взаимодействуют с новыми функциями или изменениями.
- Реклама. Управление запросами на рекламу и предварительные ставки на рекламу.
- Редакция. Встраивание кода в статьи, такие как твиты или видео, а также в пользовательские виджеты (например, средство отслеживания случаев коронавируса).
Обеспечение того, чтобы каждая из этих команд не вызывала тряску макета страницы, может оказаться сложной задачей. Используя показатель «Совокупное изменение макета» для измерения того, как часто это происходит с нашими читателями, команды получили более глубокое представление о реальном пользовательском опыте и четкую цель, к которой нужно стремиться. В результате наш 75-й процентиль CLS улучшился с 0,25 до 0,1, а показатель проходного сегмента увеличился с 57% до 72%.
250 %
Улучшение CLS на 75-й процентиль
15 %
Больше пользователей с хорошим рейтингом CLS
С чего мы начали
Используя информационные панели 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. Мы продолжим отслеживать и контролировать наши показатели с целью постоянного их улучшения и предоставления нашим читателям наилучшего пользовательского опыта.
,За пару месяцев ведущему новостному сайту Великобритании удалось улучшить свой 75-й процентиль CLS на 250% с 0,25 до 0,1.
Проблема визуальной стабильности
Сдвиги макета могут быть очень разрушительными. В Telegraph Media Group (TMG) визуальная стабильность особенно важна, поскольку читатели преимущественно используют наши приложения для просмотра новостей. Если макет сместится во время чтения статьи, читатель, скорее всего, потеряет свое место. Это может быть разочаровывающим и отвлекающим опытом.
С инженерной точки зрения обеспечение того, чтобы страницы не смещались и не прерывали чтение, может быть сложной задачей, особенно когда области вашего приложения загружаются асинхронно и добавляются на страницу динамически.
В TMG есть несколько команд, которые пишут код на стороне клиента:
- Основная инженерия. Внедрение сторонних решений для таких областей, как рекомендации по контенту и комментирование.
- Маркетинг. Запуск A/B-тестов, чтобы оценить, как наши читатели взаимодействуют с новыми функциями или изменениями.
- Реклама. Управление запросами на рекламу и предварительные ставки на рекламу.
- Редакция. Встраивание кода в статьи, такие как твиты или видео, а также в пользовательские виджеты (например, средство отслеживания случаев коронавируса).
Обеспечение того, чтобы каждая из этих команд не вызывала тряску макета страницы, может оказаться сложной задачей. Используя показатель «Совокупное изменение макета» для измерения того, как часто это происходит с нашими читателями, команды получили более глубокое представление о реальном пользовательском опыте и четкую цель, к которой нужно стремиться. В результате наш 75-й процентиль CLS улучшился с 0,25 до 0,1, а показатель проходного сегмента увеличился с 57% до 72%.
250 %
Улучшение CLS на 75-й процентиль
15 %
Больше пользователей с хорошим рейтингом CLS
С чего мы начали
Используя информационные панели 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. Мы продолжим отслеживать и контролировать наши показатели с целью постоянного их улучшения и предоставления нашим читателям наилучшего пользовательского опыта.
,За пару месяцев ведущему новостному сайту Великобритании удалось улучшить свой 75-й процентиль CLS на 250% с 0,25 до 0,1.
Проблема визуальной стабильности
Сдвиги макета могут быть очень разрушительными. В Telegraph Media Group (TMG) визуальная стабильность особенно важна, поскольку читатели преимущественно используют наши приложения для просмотра новостей. Если макет сместится во время чтения статьи, читатель, скорее всего, потеряет свое место. Это может быть разочаровывающим и отвлекающим опытом.
С инженерной точки зрения обеспечение того, чтобы страницы не смещались и не прерывали чтение, может быть сложной задачей, особенно когда области вашего приложения загружаются асинхронно и добавляются на страницу динамически.
В TMG есть несколько команд, которые пишут код на стороне клиента:
- Основная инженерия. Внедрение сторонних решений для таких областей, как рекомендации по контенту и комментирование.
- Маркетинг. Запуск A/B-тестов, чтобы оценить, как наши читатели взаимодействуют с новыми функциями или изменениями.
- Реклама. Управление запросами на рекламу и предварительные ставки на рекламу.
- Редакция. Встраивание кода в статьи, такие как твиты или видео, а также в пользовательские виджеты (например, средство отслеживания случаев коронавируса).
Обеспечение того, чтобы каждая из этих команд не вызывала тряску макета страницы, может оказаться сложной задачей. Используя показатель «Совокупное изменение макета» для измерения того, как часто это происходит с нашими читателями, команды получили более глубокое представление о реальном пользовательском опыте и четкую цель, к которой нужно стремиться. В результате наш 75-й процентиль CLS улучшился с 0,25 до 0,1, а показатель проходного сегмента увеличился с 57% до 72%.
250 %
Улучшение CLS на 75-й процентиль
15 %
Больше пользователей с хорошим рейтингом CLS
С чего мы начали
Используя информационные панели 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. Мы продолжим отслеживать и контролировать наши показатели с целью постоянного их улучшения и предоставления нашим читателям наилучшего пользовательского опыта.
,За пару месяцев ведущему новостному сайту Великобритании удалось улучшить свой 75-й процентиль CLS на 250% с 0,25 до 0,1.
Проблема визуальной стабильности
Сдвиги макета могут быть очень разрушительными. В Telegraph Media Group (TMG) визуальная стабильность особенно важна, поскольку читатели преимущественно используют наши приложения для просмотра новостей. Если макет сместится во время чтения статьи, читатель, скорее всего, потеряет свое место. Это может быть разочаровывающим и отвлекающим опытом.
С инженерной точки зрения обеспечение того, чтобы страницы не смещались и не прерывали чтение, может быть сложной задачей, особенно когда области вашего приложения загружаются асинхронно и добавляются на страницу динамически.
В TMG есть несколько команд, которые пишут код на стороне клиента:
- Основная инженерия. Внедрение сторонних решений для таких областей, как рекомендации по контенту и комментирование.
- Маркетинг. Запуск A/B-тестов, чтобы оценить, как наши читатели взаимодействуют с новыми функциями или изменениями.
- Реклама. Управление запросами на рекламу и предварительные ставки на рекламу.
- Редакция. Встроенный код в статьи, такие как твиты или видео, а также пользовательские виджеты (например, трекер корнавируса).
Обеспечение того, чтобы каждая из этих команд не приводит к тому, что макет страницы может быть затруднено. Используя метрику смены совокупного смены макета , чтобы измерить, как часто она встречается для наших читателей, команды получили большее понимание реального пользовательского опыта и четкой цели, к которой стремиться. Это привело к тому, что наш 75 -й процентиль CLS улучшился с 0,25 до 0,1, а наше проходящее ведро увеличилось с 57% до 72%.
250 %
Улучшение CLS 75 -й процентиль
15 %
Больше пользователей с хорошим результатом CLS
С чего мы начали
Используя Crux Dashboards, мы смогли установить, что наши страницы менялись больше, чем хотелось бы.
В идеале мы хотели, чтобы, по крайней мере, 75% наших читателей, чтобы получить «хороший» опыт, поэтому мы начали определять причины нестабильности макета.
Как мы измерили смены макета
Мы использовали комбинацию Chrome Devtools и WebPageTest , чтобы помочь распознать, что вызывает смену макета. В Devtools мы использовали раздел опыта вкладки Performance , чтобы выделить отдельные экземпляры смещения макета и того, как они внесли свой вклад в общий балл.
WebPageTest полезно подчеркивает, где происходит сдвиг макета в представлении временной шкалы, когда выбирается «выделение смены макета».
После рассмотрения каждой смены в наших самых посещаемых шаблонах мы придумали список идей о том, как мы могли бы улучшить.
Уменьшение сдвигов макета
Мы сосредоточились на четырех областях, где мы могли бы уменьшить смены макета: - Реклама - изображения - заголовки - вставки
Реклама
Реклама загружается после начальной краски через JavaScript. Некоторые из контейнеров, в которых они загрузили, не имели зарезервированной высоты на них.
Хотя мы не знаем точной высоты, мы можем зарезервировать пространство, используя наиболее распространенный размер рекламы, загруженный в слот.
В некоторых случаях мы неправильно оценили средний рост рекламы. Для читателей планшетов слот рухнул.
Мы пересмотрели слот и отрегулировали высоту, чтобы использовать наиболее распространенный размер.
Изображения
Многие изображения на веб -сайте ленивы загружены и зарезервируют их пространство.
Однако встроенные изображения в верхней части статей не имели места, зарезервированного на контейнере, и при этом у них не было атрибутов ширины и высоты, связанных с тегами. Это привело к сдвигу, когда они загружались.
Простое добавление атрибутов ширины и высоты к изображениям гарантировало, что макет не сдвинулся.
Заголовок
Заголовок был ниже контента в разметке и был расположен наверху с использованием CSS. Первоначальная идея заключалась в том, чтобы расставить приоритеты в загрузке контента перед навигацией, однако это привело к на мгновение сместить страницу.
Перемещение заголовка в верхнюю часть разметки позволило странице отображаться без этого сдвига.
Встраивания
Некоторые из часто используемых встраиваний имеют определенное соотношение сторон. Например, видео на YouTube. Пока игрок загружается, мы вытаскиваем миниатюру с YouTube и используем его в качестве заполнителя, пока видео загружается.
Измерение воздействия
Мы смогли измерить воздействие на уровне функций довольно легко, используя инструменты, упомянутые в начале статьи. Однако мы хотели измерить CLS как на уровне шаблона, так и на уровне сайта. Синтетически, мы использовали Speedcurve для проверки изменений как в предварительном производстве, так и в производстве.
Затем мы можем проверить результаты в наших данных RUM (предоставленные Mpulse ) после того, как код достиг производства.
Проверка данных о роме обеспечивает нам хороший уровень уверенности в том, что изменения, которые мы вносят, оказывают положительное влияние на наших читателей.
Окончательные номера, которые мы рассмотрели, предназначены для данных RUM Google. Это особенно актуально сейчас, так как они скоро окажут влияние на рейтинг страницы . Для начала мы использовали отчет Chrome UX , как в ежемесячных данных уровня происхождения, доступных через панель панели Crux , так и запрашивая BigQuery для получения исторических данных P75. Таким образом, мы легко смогли увидеть, что для всего трафика, измеренного CRUX, наши 75 -й процентиль CLS улучшились на 250% с 0,25 до 0,1, а наше проходящее ведро выросло с 57% до 72% .
Кроме того, мы смогли использовать API Chrome UX Report и создать некоторые внутренние панели панели на шаблоны.
Избегая регрессий CLS
Важным аспектом улучшения производительности является избегание регрессий. Мы установили некоторые базовые бюджеты эффективности для наших ключевых метрик и включили в них CLS.
Если тест превышает бюджет, он отправит сообщение на слабый канал, чтобы мы могли расследовать причину. Мы также создали еженедельные отчеты, так что даже если шаблоны остаются в бюджете, мы знаем о любых изменениях, которые оказали негативное влияние.
Мы также планируем расширить наши бюджеты для использования данных RUM, а также синтетических данных, используя MPULSE для установления как статических оповещений, так и потенциально обнаружения аномалий , что заставит нас осознать любые изменения, которые не являются обычными.
Для нас важно подходить к новым функциям с учетом CLS. Многие изменения, которые я упомянул, - это те, которые мы должны были исправить после того, как они были выпущены нашим читателям. Стабильность макета будет рассмотрено для разработки решения любой новой функции, которая может избежать любых неожиданных сдвигов макета с самого начала.
Заключение
Улучшения, которые мы сделали до сих пор, были довольно легко реализовать и оказали значительное влияние. Многие изменения, которые я обрисовал в этой статье, не заняло много времени, и они применялись ко всем наиболее часто используемым шаблонам, что означает, что они оказали широкое положительное влияние на наших читателей.
Есть еще области сайта, которые нам нужно улучшить. Мы исследуем способы, которыми мы могли бы сделать больше логического сервера на стороне нашего клиента, что еще больше улучшит CLS. Мы будем продолжать отслеживать и мониторировать наши метрики с целью постоянного улучшения их и предоставить нашим читателям максимально возможный опыт пользователя.