Кейс об изменениях, внесенных веб-командой YouTube для повышения производительности, увеличения количества сдач Core Web Vitals и повышения ключевых бизнес-показателей.

Команда Chrome часто говорит о создании лучшего Интернета, но что это значит? Веб-интерфейс должен быть быстрым, доступным и использовать возможности устройства в тот момент, когда пользователи больше всего в этом нуждаются. Пробная проверка — часть культуры Google, поэтому команда Chrome сотрудничает с YouTube, чтобы делиться опытом, полученным при создании более быстрого веб-интерфейса.

Создание более быстрой сети

На YouTube производительность связана с тем, насколько быстро видео и другой контент (например, рекомендации и комментарии) загружаются на веб-страницы. Производительность также измеряется тем, насколько быстро YouTube реагирует на действия пользователя. такие как поиск, управление игроком, лайки и акции.

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

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

Улучшение основных веб-показателей

Чтобы определить области для улучшения, команда YouTube использовала Отчет об опыте использования Chrome (CrUX), чтобы увидеть, как реальные пользователи воспринимают страницы просмотра видео и результатов поиска на мобильных устройствах в поле. Они поняли, что их метрика Core Web Vitals имеет много возможностей для улучшения, а их метрика Largest Contentful Paint (LCP) в некоторых случаях достигала 4–6 секунд. Это было значительно выше, чем их цель в 2,5 секунды.

Чтобы определить области для улучшения, они обратились к Маяку для аудита страниц просмотра YouTube, выявив низкий балл Маяка (лаборатория) с первой отрисовкой контента (FCP) 3,5 секунды и LCP 8,5 секунды.

Чтобы оптимизировать FCP и LCP, команда YouTube провела несколько экспериментов, в результате которых были сделаны два больших открытия.

  1. Первое открытие заключалось в том, что они могли повысить производительность, переместив HTML-код для видеопроигрывателя над сценарием, который делает видеопроигрыватель интерактивным. Лабораторные тесты показали, что это может улучшить как FCP, так и LCP с 4,4 до 1,1 секунды.
  2. Вторым открытием стало то, что LCP учитывает только &LTvideo> элементы афиши, а не кадры из самого видеопотока. YouTube традиционно оптимизировал максимально быстрое время до начала воспроизведения видео, поэтому для улучшения LCP команда также начала оптимизировать скорость доставки постера. Они поэкспериментировали с несколькими вариантами постеров и выбрали тот, который показал лучшие результаты в пользовательском тестировании. В результате этой работы как FCP, так и LCP показали заметное улучшение, при этом LCP в полевых условиях улучшился с 4,6 до 2,0 секунд.

Внося эти оптимизации на все платформы, YouTube также воспользовался новым атрибутом fetchpriority, который мы используем с <link rel=preload>, чтобы определить приоритет раннего обнаружения и загрузки изображения постера:

<link as="image" rel="preload" href="poster.jpg" fetchpriority="high">

Хотя эти оптимизации действительно улучшили LCP, команда посчитала, что текущее определение метрики LCP не полностью отражает с точки зрения пользователя момент загрузки «основного контента» страницы, что и является целью LCP.

Чтобы решить эти проблемы, члены команды YouTube объединились с членами команды Chrome, чтобы изучить способы улучшения показателя LCP для решения их задач. После рассмотрения осуществимости и влияния нескольких вариантов команды пришли к предложению рассмотреть время отрисовки первого кадра видеоэлемента в качестве кандидата на LCP.

Как только это изменение появится в Chrome, команда YouTube будет рада продолжить свою работу по оптимизации LCP. И обновленная версия метрики будет означать, что эти оптимизации будут иметь более прямое влияние на реальный пользовательский опыт.

Страницы YouTube содержали множество модулей, которые жадно загружались. Чтобы оптимизировать отрисовку более 50 компонентов, команда создала карту компонентов для JS-модулей, которая сообщает клиенту, какие модули загружать. Помечая компоненты как ленивые, модули JS будут загружаться позже, уменьшая время первоначальной загрузки страницы и количество неиспользуемого Javascript, отправляемого клиенту.

Однако после того, как была реализована ленивая загрузка, команда заметила эффект водопада, когда лениво загруженные компоненты и их зависимости загружались в неоптимальное время.

Чтобы решить эту проблему, команда определила минимальный набор компонентов, необходимых для представления, и объединила их в одном сетевом запросе. В результате улучшилась скорость страницы, сократилось время анализа JavaScript и, в конечном счете, улучшилось время начального рендеринга.

Управление состоянием компонентов

YouTube испытывал проблемы с производительностью из-за элементов управления проигрывателем, особенно на старых устройствах. Анализ кода показал, что проигрыватель, который позволяет пользователям управлять такими функциями, как скорость воспроизведения и прогресс, со временем стал слишком многокомпонентным.

Каждое событие touch-move индикатора выполнения запускало два дополнительных пересчета стиля и занимало 21,17 мс во время тестов производительности в лаборатории. По мере того как со временем добавлялись новые элементы управления, шаблон децентрализованного управления часто приводил к циклическим зависимостям и утечкам памяти, что негативно влияло на производительность страницы просмотра.

Чтобы устранить проблемы, связанные с децентрализованным управлением, команда обновила пользовательский интерфейс проигрывателя, чтобы синхронизировать все обновления, по существу рефакторинг проигрывателя в один компонент верхнего уровня, который будет передавать данные своим дочерним элементам. Это гарантировало только один цикл обновления (рендеринга) пользовательского интерфейса для любого изменения состояния, исключая цепочку обновлений. Событие touch-move на полосе прогресса нового игрока не имеет пересчета стиля во время выполнения JavaScript и теперь требует только 25% времени старого игрока.

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

Заключение

Успех

76 % мобильных веб-URL-адресов YouTube теперь соответствуют показателям Core Web Vitals, в результате чего улучшились такие бизнес-показатели, как время просмотра.

В результате инвестиций YouTube в производительность страницы просмотра загружаются намного быстрее: 76% URL-адресов мобильных веб-сайтов YouTube теперь соответствуют пороговым значениям показателей Core Web Vitals в этой области.

На настольных компьютерах лабораторная LCP для страницы просмотра была сокращена примерно с 4,6 до 1,6 секунд. Взаимодействие и производительность рендеринга сайта, особенно в видеоплеере YouTube, тратят на выполнение JavaScript на 75 % меньше времени, чем раньше.

Выражаем особую благодарность Гилберто Кокки, Лорен Усуи, Бенджи Беару, Бо Айе, Богдану Баласу, Кенни Трану, Мэтью Смиту, Филу Харнишу, Лине Сахони, Джереми Вагнеру, Филипу Уолтону, Харлин Батра, а также командам YouTube и Chrome за их вклад в эту работу.

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

Первоначально опубликовано на https://web.dev Адди Османи и Шрирамом Кришнаном