Пример изменений, которые веб-команда 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 и Chrome за их вклад в развитие эта работа.