Пример изменений, которые веб-команда YouTube внесла для повышения производительности, повышения показателей прохождения основных веб-показателей и ключевых бизнес-показателей.
Команда Chrome часто говорит о «создании лучшего Интернета», но что это значит? Веб-интерфейс должен быть быстрым , доступным и использовать возможности устройства в тот момент, когда пользователям это нужно больше всего. Тестирование является частью культуры Google, поэтому команда Chrome объединилась с YouTube, чтобы поделиться уроками, полученными за время работы, в новой серии под названием «Создание лучшего Интернета». Первая часть серии посвящена тому, как YouTube обеспечил более быструю работу в Интернете.
Создание более быстрого Интернета
На YouTube производительность связана с тем, насколько быстро видео и другой контент, например рекомендации и комментарии, загружаются на веб-страницах. Производительность также измеряется тем, насколько быстро YouTube реагирует на действия пользователя, такие как поиск, управление проигрывателем, лайки и публикации.
Растущие развивающиеся рынки, такие как Бразилия, Индия и Индонезия, важны для мобильного Интернета YouTube. Поскольку многие пользователи в этих регионах имеют более медленные устройства и ограниченную пропускную способность сети, обеспечение быстрой и бесперебойной работы является критически важной целью.
Чтобы обеспечить инклюзивный опыт для всех пользователей, YouTube решил улучшить показатели производительности, такие как Core Web Vitals, за счет отложенной загрузки и модернизации кода.
Улучшение основных веб-показателей
Чтобы определить области улучшения, команда YouTube использовала отчет об опыте пользователей Chrome (CrUX) , чтобы увидеть, как реальные пользователи воспринимают просмотр видео и страницы результатов поиска на мобильных устройствах в полевых условиях . Они поняли, что их метрики Core Web Vitals имеют много возможностей для улучшения: их метрика Largest Contentful Paint (LCP) в некоторых случаях составляет 4–6 секунд. Это было существенно выше запланированного показателя в 2,5 секунды.
Чтобы определить области, требующие улучшения, они обратились к Lighthouse для аудита страниц просмотра YouTube и выявили низкую оценку Lighthouse ( lab ) с первой содержательной отрисовкой (FCP) 3,5 секунды и LCP 8,5 секунды.
Чтобы оптимизировать FCP и LCP, команда YouTube провела несколько экспериментов, в результате которых было сделано два важных открытия.
Первым открытием стало то, что можно повысить производительность, переместив HTML-код видеоплеера над сценарием, который делает видеоплеер интерактивным. Лабораторные тесты показали, что это может улучшить как FCP, так и LCP с 4,4 секунды до 1,1 секунды.
Вторым открытием стало то, что LCP учитывает только постеры элемента
<video>, а не кадры самого видеопотока. YouTube традиционно оптимизировал максимально быстрое время до начала воспроизведения видео, поэтому для улучшения LCP команда начала также оптимизировать скорость доставки изображения постера. Они поэкспериментировали с несколькими вариантами изображений постеров и выбрали тот, который получил лучшие результаты в пользовательском тестировании. В результате этой работы как FCP, так и LCP показали заметное улучшение, при этом поле LCP улучшилось с 4,6 секунды до 2,0 секунды.
Хотя эти оптимизации действительно улучшили LCP, команда почувствовала, что текущее определение метрики LCP не полностью фиксирует, с точки зрения пользователя, момент загрузки «основного контента» страницы, что и является целью LCP.
Чтобы решить эти проблемы, члены команды YouTube объединились с членами команды Chrome, чтобы изучить способы улучшения показателя LCP для решения их вариантов использования. Рассмотрев осуществимость и влияние нескольких вариантов, команды пришли к предложению рассматривать время отрисовки первого кадра видеоэлемента в качестве кандидата на LCP.
Как только это изменение появится в Chrome, команда YouTube будет рада продолжить работу по оптимизации для LCP. А обновленная версия показателя будет означать, что эти оптимизации окажут более непосредственное влияние на опыт реальных пользователей.
Модуляризация с отложенной загрузкой
Страницы YouTube содержали множество модулей, которые охотно загружались. Чтобы оптимизировать отрисовку более 50 компонентов, команда создала карту компонентов для модулей JS, которая сообщала клиенту, какие модули загружать. Помечая компоненты как ленивые, модули JS будут загружаться позже, что сокращает начальное время загрузки страницы и количество неиспользуемого Javascript, отправляемого клиенту.
Однако после внедрения отложенной загрузки команда заметила эффект водопада, при котором отложенно загружаемые компоненты и их зависимости загружались в неоптимальное время.
Чтобы решить эту проблему, команда определила минимальный набор компонентов, необходимых для представления, и объединила их в одном сетевом запросе. В результате увеличилась скорость страницы, сократилось время анализа JavaScript и, в конечном итоге, улучшилось время начального рендеринга.
Управление состоянием компонентов
У YouTube возникали проблемы с производительностью из-за элементов управления проигрывателем, особенно на старых устройствах. Анализ кода показал, что проигрыватель, который позволяет пользователям контролировать такие функции, как скорость воспроизведения и прогресс, со временем стал чрезмерно компонентизованным.
Каждое событие касания и перемещения индикатора выполнения вызывало два дополнительных перерасчета стиля и занимало 21,17 мс во время тестов производительности в лаборатории. Поскольку со временем добавлялись новые элементы управления, модель децентрализованного управления часто вызывала циклические зависимости и утечки памяти, что отрицательно влияло на производительность страницы просмотра.
Чтобы устранить проблемы, возникающие из-за децентрализованного управления, команда обновила пользовательский интерфейс плеера, чтобы синхронизировать все обновления, по сути рефакторинг плеера до одного компонента верхнего уровня, который будет передавать данные своим дочерним элементам. Это обеспечивало только один цикл обновления (рендеринга) пользовательского интерфейса для любого изменения состояния, устраняя цепочки обновлений. Событие касания-перемещения индикатора выполнения нового игрока не требует пересчета стиля во время выполнения JavaScript и теперь требует только 25% времени старого игрока.
Эта модернизация кода также привела к дополнительным улучшениям производительности, таким как сокращение времени загрузки просмотра на старых устройствах, меньшее количество прерванных воспроизведений и уменьшение количества нефатальных ошибок.
Заключение
В результате инвестиций YouTube в производительность страницы просмотра загружаются намного быстрее: 76% URL-адресов мобильных веб-сайтов YouTube теперь соответствуют пороговым значениям показателей Core Web Vitals в этой области. На настольном компьютере время лабораторного LCP для страницы просмотра было уменьшено примерно с 4,6 секунды до 1,6 секунды. Производительность взаимодействия и рендеринга сайта, особенно в видеоплеере YouTube, теперь тратит на выполнение JavaScript на 75 % меньше времени, чем раньше.
Улучшение производительности веб-сайта YouTube за последний год также привело к улучшению бизнес-показателей, включая время просмотра и ежедневную активность пользователей. Основываясь на успехе этих усилий, мы планируем продолжить изучение еще большего количества способов оптимизации в будущем.
Во второй части этой серии, «Создание доступной сети», вы узнаете, как YouTube сделал свой веб-сайт более доступным для пользователей программ чтения с экрана.
Особая благодарность Жилберто Кокки, Лорен Усуи, Бенджи Беару, Бо Айе, Богдану Баласу, Кенни Трану, Мэтью Смиту, Филу Харнишу, Лине Сахони, Джереми Вагнеру, Филипу Уолтону, Харлин Батра, а также командам YouTube и Chrome за их вклад в развитие эта работа.