Membangun web yang lebih baik: YouTube yang lebih cepat

Studi kasus tentang perubahan yang dilakukan tim web YouTube untuk meningkatkan performa, meningkatkan rasio kelulusan Core Web Vitals, dan meningkatkan metrik bisnis utama.

Addy Osmani
Addy Osmani
Sriram Krishnan
Sriram Krishnan

Tim Chrome sering membahas tentang "membuat web yang lebih baik", tetapi apa maksudnya? Pengalaman web harus cepat, dapat diakses, dan menggunakan kemampuan perangkat saat pengguna sangat membutuhkannya. Dogfooding adalah bagian dari budaya Google. Jadi, tim Chrome telah berpartner dengan YouTube untuk berbagi pelajaran yang diperoleh selama ini dalam serial baru yang disebut, "Building a lebih baik web". Bagian pertama serial ini akan membahas cara YouTube membuat pengalaman web yang lebih cepat.

PageSpeed Insights yang menampilkan data Laporan UX Chrome.
Halaman Tonton YouTube untuk web seluler yang memenuhi nilai minimum Data Web Inti.

Di YouTube, performa berkaitan dengan seberapa cepat video dan konten lainnya—seperti rekomendasi dan komentar—dimuat di halaman web. Performa juga diukur dengan seberapa cepat YouTube merespons interaksi pengguna seperti penelusuran, kontrol pemutar, suka, dan bagikan.

Pasar berkembang yang terus berkembang, seperti Brasil, India, dan Indonesia, sangat penting untuk web seluler YouTube. Karena banyak pengguna di region ini memiliki perangkat yang lebih lambat dan bandwidth jaringan yang terbatas, memastikan pengalaman yang cepat dan lancar merupakan tujuan yang penting.

Untuk memberikan pengalaman yang inklusif bagi semua pengguna, YouTube berupaya meningkatkan metrik performa seperti Data Web Inti melalui pemuatan lambat dan modernisasi kode.

Meningkatkan Core Web Vitals

Untuk mengidentifikasi area yang perlu ditingkatkan, tim YouTube menggunakan Laporan Pengalaman Pengguna Chrome (CrUX) untuk melihat pengalaman pengguna sebenarnya saat menonton video dan membuka halaman hasil penelusuran di perangkat seluler di lapangan. Mereka menyadari bahwa metrik Data Web Inti mereka memiliki banyak ruang untuk ditingkatkan, dengan metrik Largest Contentful Paint (LCP) yang mencapai 4-6 detik dalam beberapa kasus. Hasil ini jauh lebih tinggi dari target mereka 2,5 detik.

Diagram FCP dan LCP yang menunjukkan rasio kelulusan halaman Tonton YouTube serta asal YouTube.

Untuk mengidentifikasi area yang perlu ditingkatkan, mereka menggunakan Lighthouse untuk mengaudit halaman tonton YouTube, yang menunjukkan skor Lighthouse (lab) yang rendah dengan First Contentful Paint (FCP) 3,5 detik dan LCP 8,5 detik.

Laporan Lighthouse untuk YouTube Seluler.
Chrome menetapkan target 1,8 detik untuk FCP dan 2,5 detik untuk LCP sebagai standar emas. FCP dan LCP jelas berwarna kuning dan merah masing-masing 3,5 detik dan 8,5 detik.

Untuk mengoptimalkan FCP dan LCP, tim YouTube melakukan beberapa eksperimen, yang menghasilkan dua penemuan besar.

  1. Penemuan pertama adalah mereka dapat meningkatkan performa dengan memindahkan HTML untuk Pemutar Video di atas skrip yang membuat Pemutar Video menjadi interaktif. Pengujian lab menunjukkan bahwa hal ini dapat meningkatkan FCP dan LCP dari 4,4 detik menjadi 1,1 detik.

  2. Penemuan kedua adalah LCP hanya mempertimbangkan gambar poster elemen <video>, bukan frame dari streaming video itu sendiri. YouTube secara tradisional telah mengoptimalkan waktu tercepat hingga video mulai diputar. Jadi, untuk meningkatkan LCP, tim juga mulai mengoptimalkan seberapa cepat mereka dapat mengirimkan gambar poster. Mereka bereksperimen dengan beberapa variasi gambar poster dan memilih salah satu yang mendapatkan skor terbaik dalam pengujian pengguna. Sebagai hasil dari upaya ini, FCP dan LCP menunjukkan peningkatan yang signifikan, dengan LCP kolom meningkat dari 4,6 detik menjadi 2,0 detik.

Tonton Eksperimen LCP Halaman untuk web seluler yang menampilkan kontrol, eksperimen A (thumbnail gambar), dan eksperimen B (thumbnail hitam)
Di lab, kami mengamati peningkatan FCP dan LCP dari 4,4 detik menjadi 1,1 detik setelah perubahan ini diterapkan. Eksperimen A: Penggunaan thumbnail video yang sebenarnya berfungsi dengan baik di halaman tempat video awalnya dijeda, tetapi untuk halaman video yang diputar otomatis seperti halaman tonton, video tersebut berperforma buruk dalam studi pengguna. Hal ini juga mengakibatkan penurunan pengguna aktif. Eksperimen B: Penggunaan gambar poster berwarna hitam solid menunjukkan hasil terbaik dalam studi pengguna. Pengguna merasa transisi dari hitam solid ke frame pertama video merupakan pengalaman yang tidak terlalu mengganggu untuk video yang diputar otomatis.
Thumbnail berwarna hitam telah di-deploy dalam produksi untuk semua pengguna web seluler pada Juli 2021 dan menunjukkan peningkatan nyata pada FCP dan LCP, seperti yang terlihat dalam analisis RUM di atas.
Thumbnail hitam di-deploy dalam produksi untuk semua pengguna web seluler pada Juli 2021, yang menunjukkan peningkatan yang signifikan pada FCP dan LCP, seperti yang terlihat dalam analisis RUM di atas.

Meskipun pengoptimalan ini benar-benar meningkatkan LCP, tim merasa bahwa definisi metrik LCP saat ini tidak sepenuhnya menangkap, dari perspektif pengguna, saat "konten utama" halaman telah dimuat—yang merupakan sasaran LCP.

Untuk mengatasi masalah ini, anggota tim YouTube berpartner dengan anggota tim Chrome untuk mempelajari cara meningkatkan metrik LCP guna mengatasi kasus penggunaan mereka. Setelah mempertimbangkan kelayakan dan dampak beberapa opsi, tim tersebut menyepakati proposal untuk mempertimbangkan waktu render frame pertama elemen video sebagai kandidat LCP.

Setelah perubahan ini diterapkan di Chrome, tim YouTube bersemangat untuk melanjutkan upaya mereka dalam mengoptimalkan LCP. Selain itu, versi metrik yang diperbarui akan berarti bahwa pengoptimalan ini akan memiliki dampak yang lebih langsung pada pengalaman pengguna yang sebenarnya.

Modularisasi dengan pemuatan lambat

Halaman YouTube berisi banyak modul yang dimuat dengan cepat. Untuk mengoptimalkan cara lebih dari 50 komponen dirender, tim membuat komponen ke peta modul JS yang akan memberi tahu klien modul mana yang akan dimuat. Dengan menandai komponen sebagai lambat, modul JS akan dimuat nanti, sehingga mengurangi waktu pemuatan awal halaman dan jumlah JavaScript tidak terpakai yang dikirim ke klien.

Namun, setelah pemuatan lambat diterapkan, tim melihat efek waterfall bahwa komponen yang dimuat lambat dan dependensinya akan dimuat pada waktu yang tidak optimal.

Untuk mengatasi masalah ini, tim menentukan kumpulan komponen minimal yang diperlukan dalam tampilan dan mengelompokkannya dalam satu permintaan jaringan. Hasilnya adalah peningkatan kecepatan halaman, pengurangan waktu penguraian JavaScript, dan, pada akhirnya, waktu rendering awal yang lebih baik.

Pengelolaan status di seluruh komponen

YouTube mengalami masalah performa karena kontrol pemutarnya, terutama di perangkat lama. Analisis kode menunjukkan bahwa pemutar, yang memungkinkan pengguna mengontrol fitur seperti kecepatan dan progres pemutaran, telah menjadi terkomponen berlebihan dari waktu ke waktu.

Pemutar dan kontrol YouTube divisualisasi
Pemutar video YouTube memungkinkan pengguna mengontrol kecepatan pemutaran, mengikuti progres, melewati bagian, dan lainnya. Saat pengguna mengetuk kontrol tertentu, perubahan status harus dikomunikasikan ke kontrol lain, misalnya ketukan pengguna pada status progres harus dibagikan ke kontrol seperti pemutar, subtitel, dll.

Setiap peristiwa gerakan sentuh status progres memicu dua penghitungan ulang gaya tambahan dan memerlukan waktu 21,17 md selama pengujian performa berjalan di lab. Seiring dengan penambahan kontrol baru dari waktu ke waktu, pola kontrol terdesentralisasi sering kali menyebabkan dependensi melingkar dan kebocoran memori, yang berdampak negatif pada performa halaman tonton.

Peristiwa 21,17 md ditampilkan di linimasa Performa.
Chrome DevTools dengan performa yang melambat 4 kali lipat pada CPU.

Untuk memperbaiki masalah karena kontrol terdesentralisasi, tim memperbarui UI pemutar untuk menyinkronkan semua update, yang pada dasarnya memfaktorkan ulang pemutar ke satu komponen tingkat atas yang akan meneruskan data ke turunannya. Hal ini memastikan hanya satu siklus update (render) UI untuk setiap perubahan status, sehingga menghilangkan update berantai. Peristiwa gerakan sentuh status progres pemutar baru tidak memiliki penghitungan ulang gaya selama eksekusi JavaScript dan sekarang hanya memerlukan 25% waktu pemutar lama.

Pengurangan waktu dalam acara yang ditampilkan di linimasa performa.

Modernisasi kode ini juga menghasilkan peningkatan performa tambahan seperti waktu pemuatan tontonan yang lebih baik di perangkat lama, lebih sedikit pemutaran yang ditinggalkan, dan jumlah error non-fatal yang berkurang.

Hasil dan pengoptimalan

Sebagai hasil dari investasi YouTube dalam performa, halaman tonton dimuat jauh lebih cepat dengan 76% URL situs seluler YouTube kini lulus nilai minimum metrik Data Web Inti di lapangan. Di desktop, LCP lab untuk halaman tontonan dikurangi dari sekitar 4,6 detik menjadi 1,6 detik. Performa rendering dan interaksi situs, khususnya pada pemutar video YouTube, mengalami penurunan waktu yang dihabiskan dalam eksekusi JavaScript hingga 75% dibandingkan sebelumnya.

Peningkatan performa web YouTube selama setahun terakhir juga telah meningkatkan metrik bisnis, termasuk waktu tonton dan pengguna aktif harian. Berdasarkan keberhasilan upaya ini, kami berencana untuk terus mempelajari lebih banyak cara untuk mengoptimalkan di masa mendatang.

Terima kasih khusus kepada Gilberto Cocchi, Lauren Usui, Benji Bear, Bo Aye, Bogdan Balas, Kenny Tran, Matthew Smith, Phil Harnish, Leena Sahoni, Jeremy Wagner, Philip Walton, Harleen Batra, serta tim YouTube dan Chrome atas kontribusi mereka dalam pekerjaan ini.