Пример изменений, внесенных веб-командой YouTube для повышения производительности, увеличения показателей прохождения теста Core Web Vitals и улучшения ключевых бизнес-показателей.
Команда Chrome часто говорит о «создании лучшего веба», но что это значит? Веб-опыт должен быть быстрым , доступным и использовать возможности устройства в тот момент, когда пользователи больше всего в этом нуждаются. Тестирование является частью культуры Google, поэтому команда Chrome объединилась с YouTube, чтобы поделиться полученными уроками в новой серии под названием «Создание лучшего веба». Первая часть серии будет посвящена тому, как YouTube создал более быстрый веб-опыт.
На YouTube производительность связана с тем, как быстро видео и другой контент, например рекомендации и комментарии, загружаются на веб-страницах. Производительность также измеряется тем, как быстро YouTube реагирует на действия пользователя, такие как поиск, управление проигрывателем, лайки и репосты.
Растущие развивающиеся рынки, такие как Бразилия, Индия и Индонезия, важны для мобильного веба YouTube. Поскольку многие пользователи в этих регионах имеют более медленные устройства и ограниченную пропускную способность сети, обеспечение быстрого и бесперебойного опыта является критической целью.
Чтобы обеспечить инклюзивный опыт для всех пользователей, YouTube решил улучшить показатели производительности, такие как Core Web Vitals, с помощью отложенной загрузки и модернизации кода.
Улучшить основные веб-показатели
Чтобы определить области для улучшения, команда YouTube использовала отчет Chrome User Experience Report (CrUX), чтобы увидеть, как реальные пользователи воспринимают страницы просмотра видео и результатов поиска на мобильных устройствах в этой области . Они поняли, что их метрики Core Web Vitals имеют много возможностей для улучшения, а их метрика Largest Contentful Paint (LCP) в некоторых случаях составляла 4-6 секунд. Это было существенно выше их целевого показателя в 2,5 секунды.
Чтобы определить области для улучшения, они обратились к Lighthouse для аудита страниц просмотра YouTube, выявив низкий балл Lighthouse ( lab ) с показателем First Contentful Paint (FCP) 3,5 секунды и LCP 8,5 секунды.
Чтобы оптимизировать FCP и LCP, команда YouTube провела несколько экспериментов, в результате которых было сделано два важных открытия.
Первое открытие заключалось в том, что они могли бы улучшить производительность, переместив HTML для Video Player выше скрипта, который делает Video Player интерактивным. Лабораторные испытания показали, что это могло бы улучшить как 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 за их вклад в эту работу.