Pemutaran Video Di Web: Keadaan Video Saat Ini (Bagian 1)
Diterbitkan: 2022-03-10Penggunaan video di web meningkat karena perangkat dan jaringan menjadi lebih cepat dan lebih mampu menangani konten video. Penelitian menunjukkan bahwa situs dengan video meningkatkan keterlibatan sebesar 80%. Situs E-Commerce dengan video memiliki konversi yang lebih tinggi daripada situs tanpa video.
Tetapi menambahkan video dapat dikenakan biaya. Video (menjadi file yang lebih besar) menambah waktu buka halaman, dan penelitian kinerja menunjukkan bahwa halaman yang lebih lambat memiliki efek sebaliknya dari keterlibatan dan konversi pelanggan yang lebih rendah. Dalam artikel ini, saya akan membahas metrik penting untuk menyeimbangkan kinerja dan pemutaran video di web, melihat bagaimana video digunakan saat ini, dan memberikan praktik terbaik dalam menayangkan video di web.
Salah satu langkah pertama untuk meningkatkan kepuasan pelanggan adalah mempercepat waktu buka halaman . Google telah menunjukkan bahwa halaman seluler yang memuat lebih dari tiga detik kehilangan 53% audiensnya karena ditinggalkan. Studi lain menemukan bahwa pada peningkatan kinerja situs, penggunaan dan penjualan meningkat.
Menambahkan video ke situs web akan meningkatkan keterlibatan, tetapi juga dapat secara dramatis memperlambat waktu buka, jadi jelas bahwa keseimbangan harus ditemukan antara menambahkan video ke situs Anda dan tidak terlalu memengaruhi waktu buka.
Bacaan yang disarankan : Daftar Periksa Kinerja Front-End 2018 [PDF, Apple Pages]
Video Di Web Hari Ini
Untuk memeriksa status video di web hari ini, saya akan menggunakan data dari Arsip HTTP. Arsip HTTP menggunakan WebPageTest untuk memindai kinerja 1,2 juta situs seluler dan desktop setiap dua minggu, lalu menyimpan datanya di Google BigQuery.
Biasanya hanya halaman utama setiap domain yang dicentang (artinya www.cnn.com
dijalankan, tetapi www.cnn.com/politics
tidak). Data ini dapat membantu kami memahami bagaimana penggunaan video di web memengaruhi kinerja situs web. Pengujian seluler dijalankan pada Motorola G4 yang diemulasi dengan koneksi internet 3G (turun 1,6 MBPS, naik 768 KBPS, 300 ms RTT), dan pengujian desktop menjalankan Chrome pada sambungan kabel (5 MBPS turun, 1 MBPS naik, 28 md RTT). Saya akan menggunakan kumpulan data mulai 1 Agustus 2018.
Situs yang Mengunduh Video
Sebagai langkah pertama untuk mempelajari situs dengan video, kita harus melihat situs yang mengunduh file video saat halaman dimuat. Ada 35rb situs seluler dan 55rb situs desktop dengan unduhan file video di kumpulan data Arsip HTTP (yaitu 3% dari semua situs seluler dan 4,5% dari semua situs desktop). Membandingkan desktop dengan seluler, kami menemukan bahwa 30 ribu situs ini memiliki video di seluler dan desktop (meninggalkan ~5.800 situs di seluler tanpa video di desktop).
Halaman seluler median dengan video memiliki bobot 7 MB (583% lebih besar dari 1,2 MB ditemukan untuk situs seluler median). Peningkatan ini tidak sepenuhnya disebabkan oleh video saja (2,5 MB). Karena situs dengan video cenderung lebih kaya fitur dan menarik secara visual, mereka juga menggunakan lebih banyak gambar (median situs memiliki lebih dari 1 MB), CSS, dan Javascript. Tabel di bawah ini juga menunjukkan bahwa SpeedIndex median (pengukuran seberapa cepat konten muncul di layar) untuk situs dengan video 3,7 detik lebih lambat dari situs seluler biasa, membutuhkan waktu 11,5 detik untuk dimuat.
indeks kecepatan | Jumlah Byte | Video Byte | Byte CSS | Gambar Byte | Byte JS | |
---|---|---|---|---|---|---|
Video | 11544 | 6.963.579 | 2.526.098 | 80.327 | 1.596.062 | 708.978 |
semua situs | 7780 | 1.201.802 | 0 | 40.648 | 449.585 | 336.973 |
Ini jelas menunjukkan bahwa situs yang lebih interaktif dan memiliki konten video membutuhkan waktu (rata-rata) lebih lama untuk memuat situs tersebut tanpa video. Tapi bisakah kita mempercepat pengiriman video? Apa lagi yang bisa kita pelajari dari data yang ada?
Video Hosting
Saat memeriksa pengiriman video, apakah file disajikan dari CDN atau penyedia video, atau apakah pengembang menghosting video di server mereka sendiri? Dengan memeriksa domain video yang dikirimkan di seluler, kami menemukan bahwa 12.163 domain digunakan untuk mengirimkan video, yang menunjukkan bahwa ~49% situs menyajikan file video mereka sendiri. Jika kami menyusun peringkat domain berdasarkan frekuensi, kami dapat menentukan solusi hosting video yang paling umum:
Video Doman | cnt | % |
---|---|---|
fbcdn.net | 116788 | 67% |
akamaihd.net | 11170 | 6% |
googlevideo.com | 10394 | 6% |
cloudinary.com | 3170 | 2% |
amazonaws.com | 1939 | 1% |
cloudfront.net | 1896 | 1% |
pixfs.net | 1853 | 1% |
akamaized.net | 1573 | 1% |
tedcdn.com | 1507 | 1% |
contentabc.com | 1507 | 1% |
vimeocdn.com | 1373 | 1% |
dailymotion.com | 1337 | 1% |
teads.tv | 1022 | 1% |
youtube.com | 1007 | 1% |
adstatic.com | 998 | 1% |
CDN dan domain teratas Facebook, Akamai, Google, Cloudinary, AWS, dan Cloudfront memimpin, yang tidak mengejutkan. Namun, menarik untuk melihat YouTube dan Vimeo sejauh ini dalam daftar, karena mereka adalah dua situs berbagi video paling populer.
Mari kita lihat pengiriman video YouTube, Vimeo dan Facebook:
Jumlah Video YouTube
Secara default, halaman dengan video YouTube yang disematkan sebenarnya tidak mengunduh file video apa pun — hanya skrip dan gambar placeholder, sehingga tidak muncul di situs pencarian dengan unduhan video. Salah satu unduhan Javascript untuk pemutar Video YouTube adalah www-embed-player.js
. Mencari file ini, kami menemukan 69k instance di 66.647 situs seluler. Situs-situs ini memiliki SpeedIndex rata-rata 10.700, dan penggunaan data sebesar 3,31 MB — lebih baik daripada situs dengan unduhan video, tetapi masih lebih lambat daripada situs tanpa video sama sekali. Peningkatan data secara langsung terkait dengan lebih banyak gambar dan Javascript (seperti yang ditunjukkan di bawah).
indeks kecepatan | Jumlah Byte | Video Byte | Byte CSS | Gambar Byte | Byte JS | |
---|---|---|---|---|---|---|
Video | 11544 | 6.963.579 | 2.526.098 | 80.327 | 1.596.062 | 708.978 |
Semua situs | 7780 | 1.201.802 | 0 | 40.648 | 449.585 | 336.973 |
Skrip YouTube | 10700 | 3.310.000 | 0 | 126.314 | 1.733.473 | 1.005.758 |
Jumlah Video Vimeo
Ada 14.148 permintaan untuk video Vimeo di Arsip HTTP untuk pemutaran Video. Saya hanya melihat 5.848 permintaan untuk file player.js (dalam format https://f.vimeocdn.com/p/3.2.0/js/player.js
— menyiratkan bahwa mungkin ada banyak video di satu halaman, atau mungkin lokasi lain untuk file pemutar video. Ada 17 versi berbeda dari pemutar yang ada di Arsip HTTP, dengan yang paling populer adalah 3.1.5 dan 3.1.4:
URL | cnt |
---|---|
https://f.vimeocdn.com/p/3.1.5/js/player.js | 1832 |
https://f.vimeocdn.com/p/3.1.4/js/player.js | 1057 |
https://f.vimeocdn.com/p/3.1.17/js/player.js | 730 |
https://f.vimeocdn.com/p/3.1.8/js/player.js | 507 |
https://f.vimeocdn.com/p/3.1.10/js/player.js | 432 |
https://f.vimeocdn.com/p/3.1.15/js/player.js | 352 |
https://f.vimeocdn.com/p/3.1.19/js/player.js | 153 |
https://f.vimeocdn.com/p/3.1.2/js/player.js | 117 |
https://f.vimeocdn.com/p/3.1.13/js/player.js | 105 |
Tampaknya tidak ada peningkatan kinerja untuk Perpustakaan Vimeo mana pun — semua halaman memiliki waktu muat yang sama.
Catatan : Menggunakan www-embed-player.js
untuk YouTube atau https://f.vimeocdn.com/p/*/js/player.js
untuk Vimeo adalah sidik jari yang baik untuk browser dengan cache bersih, tetapi jika pelanggan sebelumnya telah menjelajahi situs dengan video tersemat, file ini mungkin sudah ada di cache browser, dan karenanya tidak akan diminta ulang. Tapi, seperti yang baru-baru ini dicatat oleh Andy Davies, ini bukan asumsi yang aman untuk dibuat.
Jumlah Video Facebook
Mengejutkan bahwa dalam data Arsip HTTP, 67% dari semua permintaan video berasal dari CDN Facebook. Ternyata di Chrome, widget Facebook pihak ke-3 mengunduh 30% dari semua video yang diposting di dalam widget (Efek ini tidak terjadi di Safari atau di Firefox.). Ternyata widget pihak ke-3 yang ditambahkan hanya dengan beberapa baris kode bertanggung jawab atas 57% dari semua video yang terlihat di Arsip HTTP.
Jenis File Video
Mayoritas video di halaman yang diuji adalah Mp4. Jika kita melihat semua video yang diunduh (tidak termasuk yang dari Facebook), kita mendapatkan tampilan berikut:
Ekstensi file | Jumlah video | % |
---|---|---|
.mp4 | 48.448 | 53% |
.ts | 18.026 | 20% |
.webm | 3.946 | 4% |
14.926 | 16% | |
.m4s | 2.017 | 2% |
.mpg | 1,431 | 2% |
.mov | 441 | 0% |
.m4v | 407 | 0% |
.swf | 251 | 0% |
Dari file tanpa ekstensi — 10k adalah file googlevideo.com
.
Apa yang bisa kita pelajari tentang file-file ini? Mari kita lihat setiap jenis file untuk mempelajari lebih lanjut tentang konten yang dikirimkan.
Saya menggunakan FFPROBE untuk menanyakan 34k file MP4 unik, dan memperoleh data untuk 14.700 video (banyak video telah diubah atau dihapus dalam 3 minggu dari pengambilan Arsip HTTP hingga analisis).
Data Video MP4
Dari 14,7 ribu video dalam kumpulan data, 8.564 memiliki trek audio (58%). Video pendek yang diputar otomatis atau video yang diputar di latar belakang tidak memerlukan audio, jadi menghapus trek audio adalah cara yang bagus untuk mengurangi ukuran file (dan mempercepat pengiriman) video Anda.
Aspek terpenting berikutnya untuk mengunduh video dengan cepat adalah dimensi. Semakin besar dimensi (dan dalam hal video, ada tiga dimensi yang perlu dipertimbangkan: width
× height
× time
), semakin besar file video.
Durasi Video MP4
Sebagian besar video 14k yang dipelajari berdurasi pendek: durasi rata-rata (persentil ke-50) adalah 21 detik. Namun, 10% dari video yang disurvei berdurasi lebih dari 2 menit. Kasus penggunaan di sini, tentu saja, akan dibagi, tetapi untuk loop video pendek, atau video latar belakang — video yang lebih pendek akan menggunakan lebih sedikit data, dan mengunduh lebih cepat.
MP4 Video Lebar Dan Tinggi
Dimensi video di layar menentukan berapa banyak piksel yang harus digunakan setiap bingkai. Bagan di bawah ini menunjukkan berbagai lebar video yang ditayangkan ke perangkat seluler. (Sebagai catatan, Moto G4 memiliki ukuran layar 1080x1920, dan semua halaman ditampilkan dalam mode potret).
Seperti yang ditunjukkan data, dua lebar video yang paling banyak digunakan secara signifikan lebih besar daripada layar G4 (saat dipegang dalam mode potret). 49% penuh dari semua video disajikan dengan lebar lebih dari 1080 piksel. Alcatel 1x, perangkat Android Go baru, memiliki layar 480x960 piksel. 77% video yang dikirimkan dalam kumpulan sampel berukuran lebih besar dari 480 piksel.
Saat dimensi video berkurang, ukuran file juga berkurang (dan dengan demikian waktu untuk mengirimkan video). Ini adalah alasan utama untuk mengubah ukuran video.
Mengapa video ini begitu besar? Jika kami menghubungkan video yang ditayangkan di seluler dan desktop, kami menemukan bahwa 18% video yang ditayangkan di seluler adalah video yang sama yang ditayangkan di desktop. Ini adalah 'masalah' yang dipecahkan untuk gambar bertahun-tahun yang lalu dengan gambar responsif. Dengan menayangkan video dengan ukuran berbeda ke perangkat dengan ukuran berbeda, kami dapat memastikan bahwa video yang indah disajikan, tetapi pada ukuran dan dimensi yang masuk akal untuk perangkat.
Kecepatan Bit Video MP4
Kecepatan bit video yang dikirimkan ke perangkat memainkan pengaruh besar pada seberapa baik video akan diputar ulang. Tes Arsip HTTP dijalankan pada koneksi 3G dengan kecepatan unduh 1,6 MBPS. Untuk memutar ulang (tanpa mengulur waktu) unduhan harus lebih cepat daripada pemutaran. Mari berikan 80% dari bitrate yang tersedia ke file video (1,3 MBPS). 47% dari video dalam kumpulan sampel memiliki bitrate lebih dari 1,3 MBPS, yang berarti bahwa ketika video ini diputar pada koneksi 3G, video tersebut cenderung macet — yang menyebabkan pelanggan tidak senang. 27% video memiliki bitrate lebih tinggi dari 2,5 MBPS, 10% lebih tinggi dari 5 MBPS, dan 35 video yang ditayangkan ke perangkat seluler memiliki bitrate > 10 MBPS. Video yang lebih besar ini tidak mungkin diputar tanpa terhenti di banyak koneksi — tetap atau seluler.
Apa yang Menyebabkan Bitrate Lebih Tinggi
Video yang lebih besar cenderung membawa bitrate yang lebih besar, karena video berdimensi lebih besar memerlukan lebih banyak data untuk mengisi piksel tambahan pada perangkat. Referensi silang bitrate dari setiap video ke lebar menegaskan hal ini: video dengan lebar 1280 (oranye) dan 1920 (abu-abu) memiliki distribusi bitrate yang jauh lebih luas (lebih banyak titik data ke kanan di bagan). Kolom yang ditandai dengan warna kuning menunjukkan 136 video dengan lebar 1920, dan bitrate antara 10-11 MBPS.
Jika kami hanya memvisualisasikan video lebih dari 1,6 MBPS, menjadi jelas bahwa resolusi layar yang lebih tinggi (1280 dan 1920) bertanggung jawab atas video dengan bitrate yang lebih tinggi.
MP4: HTTP vs. HTTPS
HTTP2 telah mendefinisikan ulang pengiriman konten dengan koneksi multipleks — di mana hanya satu koneksi per server yang diperlukan. Untuk file besar seperti video, apakah HTTP2 memberikan peningkatan yang berarti pada pengiriman konten? Jika kita melihat statistik dari Arsip HTTP:
Dengan menghilangkan 116 ribu video Facebook (semua dikirim melalui HTTP2), kami melihat bahwa ini adalah pembagian 50:50 antara HTTP 1.1 dan HTTP2. Namun, HTTP1.1 dapat menggunakan HTTPS, dan saat kami memfilter penggunaan HTTPS, kami menemukan bahwa 81% streaming video dikirim melalui HTTPS, dengan HTTP2 yang digunakan sedikit lebih banyak daripada HTTPS1.1 (41%:36%)
Seperti yang Anda lihat, membandingkan kecepatan pengiriman video HTTP dan HTTP2 masih dalam proses.
Streaming Video HLS
Streaming video menggunakan bitrate adaptif adalah cara ideal untuk mengirimkan video ke pengguna akhir. Beberapa versi dari setiap video dibuat dengan dimensi dan kecepatan bit yang berbeda. Daftar streaming yang tersedia disajikan ke perangkat pemutaran, dan pemutar video di perangkat dapat memilih streaming yang paling sesuai berdasarkan ukuran layar perangkat dan kondisi jaringan yang tersedia. Ada 1.065 file manifes (dan 14k file streaming video) dalam kumpulan data Arsip HTTP yang saya periksa.
Pemutaran Aliran Video
Salah satu metrik utama dalam streaming video adalah memulai video secepat mungkin. Sementara file manifes memiliki daftar aliran yang tersedia, pemutar tidak mengetahui bandwidth jaringan yang tersedia di awal pemutaran. Untuk memulai streaming, dan karena pemain harus memilih streaming, biasanya ia memilih yang pertama dalam daftar. Untuk memfasilitasi startup video yang cepat, penting untuk menempatkan aliran yang benar di bagian atas file manifes Anda.
Catatan : Memanfaatkan API Info Jaringan Chrome untuk menghasilkan file manifes dengan cepat mungkin merupakan cara yang baik untuk mengoptimalkan konten video dengan cepat saat memulai.
Salah satu cara untuk memastikan bahwa video dimulai dengan cepat adalah memulai dengan segmen video dengan kualitas terendah, karena unduhan akan menjadi yang tercepat. Kualitas video awal mungkin berpiksel, tetapi karena pemutar lebih memahami kualitas jaringan, pemutar dapat dengan cepat menyesuaikan ke aliran video yang lebih sesuai (semoga lebih berkualitas). Dengan mengingat hal itu, mari kita lihat bitrate aliran awal di Arsip HTTP.
Garis merah pada bagan di atas menunjukkan 1,5 MBPS (ingat bahwa pengujian seluler dijalankan pada 1,6 MBPS, dan tidak hanya konten video yang diunduh). Kami melihat 30,5% dari semua aliran (semuanya di sebelah kiri baris) dimulai dengan bitrate awal lebih tinggi dari 1,5 MBPS (dan dengan demikian tidak mungkin diputar pada koneksi 3G) 17% mulai di atas 2 MBPS.
Jadi apa yang terjadi ketika pengunduhan video lebih lambat dari pemutaran video yang sebenarnya? Awalnya, pemain akan mencoba mengunduh file bitrate (terlalu) besar, tetapi berdasarkan kecepatan unduh, akan menyadari masalahnya. Pemutar kemudian akan beralih ke mengunduh video dengan bitrate yang lebih rendah, sehingga unduhan lebih cepat daripada pemutaran. Masalahnya adalah bahwa upaya pengunduhan awal membutuhkan waktu, dan menambahkan penundaan ke awal pemutaran video menyebabkan pengabaian pelanggan.
Kami juga dapat melihat bitrate paling umum dari file .ts
(file yang memiliki konten video), untuk melihat bitrate apa yang akhirnya diunduh di ponsel. Data ini mencakup bitrate awal, dan file berikutnya yang diunduh selama menjalankan WebPageTest:
Kita dapat melihat dua pengelompokan utama bitrate streaming video (100-300 KBPS, dan puncak yang lebih luas dari 300-1.000 MBPS). Di sinilah aliran muncul, mengingat kecepatan jaringan dibatasi pada 1,6 MBPS.
Membandingkan data dengan desktop, Seluler jelas lebih tinggi pada bitrate yang lebih rendah, dan streaming desktop memiliki puncak yang tinggi dalam rentang 500-600 dan 800-900 KBPS, yang tidak terlihat di seluler.
Ketika kami membandingkan bitrate awal yang diamati (biru) dengan file sebenarnya yang diunduh, sangat jelas bahwa untuk seluler, bitrate umumnya menurun selama pemutaran streaming, yang menunjukkan bahwa menurunkan bitrate awal untuk streaming video dapat meningkatkan kinerja startup video dan mencegah kemacetan. dalam pemutaran awal video. Video desktop juga tampak menurun, tetapi mungkin juga beberapa video berpindah ke kecepatan pemutaran yang lebih tinggi.
Kesimpulan
Konten video di web meningkatkan keterlibatan dan kepuasan pelanggan. Halaman yang dimuat dengan cepat memiliki efek yang sama. Penambahan video ke situs web Anda akan memperlambat waktu rendering halaman, yang memerlukan keseimbangan antara pemuatan halaman secara keseluruhan dan konten video. Untuk mengurangi ukuran konten video Anda, pastikan Anda memiliki versi dengan ukuran yang sesuai untuk dimensi perangkat seluler, dan gunakan video yang lebih pendek jika memungkinkan.
Jika pemutaran video Anda tidak penting, ikuti jalur YouTube dan Vimeo — unduh semua bagian yang diperlukan agar siap diputar, tetapi jangan benar-benar mengunduh segmen video apa pun sampai pengguna menekan tombol putar. Terakhir — jika Anda melakukan streaming video — mulailah dengan pengaturan kualitas terendah untuk memastikan pemutaran video yang cepat.
Dalam posting video saya berikutnya, saya akan mengambil temuan umum ini, dan menggali lebih dalam tentang cara mengatasi masalah potensial dengan contoh.