การเล่นวิดีโอบนเว็บ: สถานะปัจจุบันของวิดีโอ (ตอนที่ 1)

เผยแพร่แล้ว: 2022-03-10
สรุปอย่างรวดเร็ว ↬ เนื้อหาวิดีโอบนเว็บเพิ่มความผูกพันและความพึงพอใจของลูกค้า หน้าที่โหลดเร็วมีผลเช่นเดียวกัน การเพิ่มวิดีโอลงในเว็บไซต์ของคุณจะทำให้เวลาในการแสดงหน้าเว็บช้าลง ทำให้ต้องมีความสมดุลระหว่างการโหลดหน้าเว็บโดยรวมกับเนื้อหาวิดีโอ

การใช้วิดีโอบนเว็บเพิ่มขึ้นเนื่องจากอุปกรณ์และเครือข่ายเร็วขึ้นและสามารถจัดการเนื้อหาวิดีโอได้มากขึ้น การวิจัยแสดงให้เห็นว่าไซต์ที่มีวิดีโอเพิ่มการมีส่วนร่วมถึง 80% ไซต์อีคอมเมิร์ซที่มีวิดีโอมีการแปลงที่สูงกว่าไซต์ที่ไม่มีวิดีโอ

แต่การเพิ่มวิดีโออาจมีค่าใช้จ่าย วิดีโอ (เป็นไฟล์ขนาดใหญ่) เพิ่มเวลาในการโหลดหน้าเว็บ และการวิจัยประสิทธิภาพพบว่าหน้าเว็บที่ช้ากว่ามีผลตรงกันข้ามกับการมีส่วนร่วมของลูกค้าและการแปลงที่ลดลง ในบทความนี้ ฉันจะตรวจสอบเมตริกที่สำคัญเพื่อสร้างสมดุลระหว่างประสิทธิภาพและการเล่นวิดีโอบนเว็บ ดูวิธีการใช้วิดีโอในปัจจุบัน และให้แนวทางปฏิบัติที่ดีที่สุดในการนำเสนอวิดีโอบนเว็บ

ขั้นตอนแรกในการปรับปรุงความพึงพอใจของลูกค้าคือการ เร่งความเร็วในการโหลดหน้าเว็บ Google ได้แสดงให้เห็นว่าหน้ามือถือที่ใช้เวลาในการโหลดนานกว่าสามวินาทีสูญเสีย 53% ของผู้ชมที่จะละทิ้ง การศึกษาอื่นๆ พบว่าการปรับปรุงประสิทธิภาพไซต์ การใช้งาน และยอดขายเพิ่มขึ้น

การเพิ่มวิดีโอลงในเว็บไซต์จะเพิ่มการมีส่วนร่วม แต่ก็สามารถชะลอเวลาในการโหลดได้อย่างมาก ดังนั้นจึงเป็นที่ชัดเจนว่าจะต้องมีความสมดุลระหว่างการเพิ่มวิดีโอลงในไซต์ของคุณและไม่ส่งผลกระทบต่อเวลาในการโหลดมากเกินไป

การอ่านที่แนะนำ : รายการตรวจสอบประสิทธิภาพ Front-End 2018 [PDF, Apple Pages]

วิดีโอบนเว็บวันนี้

เพื่อตรวจสอบสถานะของวิดีโอบนเว็บวันนี้ ฉันจะใช้ข้อมูลจาก HTTP Archive HTTP Archive ใช้ WebPageTest เพื่อสแกนประสิทธิภาพของเว็บไซต์มือถือและเดสก์ท็อป 1.2 ล้านเว็บไซต์ทุกสองสัปดาห์ แล้วจัดเก็บข้อมูลใน Google BigQuery

โดยปกติจะมีการตรวจสอบ www.cnn.com หลักของแต่ละโดเมน (หมายถึงมีการเรียกใช้ www.cnn.com แต่ www.cnn.com/politics ไม่ใช่) ข้อมูลนี้ช่วยให้เราเข้าใจว่าการใช้วิดีโอบนเว็บส่งผลต่อประสิทธิภาพของเว็บไซต์อย่างไร การทดสอบมือถือทำงานบน Motorola G4 จำลองที่มีการเชื่อมต่ออินเทอร์เน็ต 3G (ลดลง 1.6 MBPS, เพิ่มขึ้น 768 KBPS, 300 ms RTT) และการทดสอบเดสก์ท็อปเรียกใช้ Chrome ด้วยการเชื่อมต่อด้วยสายเคเบิล (ลดลง 5 MBPS, เพิ่มขึ้น 1 MBPS, 28 ms RTT) ฉันจะใช้ชุดข้อมูลตั้งแต่วันที่ 1 สิงหาคม 2018

เพิ่มเติมหลังกระโดด! อ่านต่อด้านล่าง↓

ไซต์ที่ดาวน์โหลดวิดีโอ

ในขั้นแรกในการศึกษาไซต์ที่มีวิดีโอ เราควรดูไซต์ที่ดาวน์โหลดไฟล์วิดีโอเมื่อโหลดหน้าเว็บ มีไซต์บนมือถือ 35k และไซต์เดสก์ท็อป 55k ที่มีการดาวน์โหลดไฟล์วิดีโอในชุดข้อมูล HTTP Archive (นั่นคือ 3% ของไซต์บนมือถือทั้งหมดและ 4.5% ของไซต์เดสก์ท็อปทั้งหมด) เมื่อเปรียบเทียบเดสก์ท็อปกับมือถือ เราพบว่า 30k ของไซต์เหล่านี้มีวิดีโอทั้งบนมือถือและเดสก์ท็อป (เหลือไซต์ประมาณ 5,800 ไซต์บนมือถือโดยไม่มีวิดีโอบนเดสก์ท็อป)

แผนภูมิ Pi แสดงการทับซ้อนกันของไซต์วิดีโอบนมือถือและเดสก์ท็อป
ไซต์บนมือถือและเดสก์ท็อปพร้อมวิดีโอ (ตัวอย่างขนาดใหญ่)

หน้าเพจบนมือถือที่มีค่าเฉลี่ยซึ่งมีวิดีโอมีน้ำหนักอยู่ที่ 7 MB (พบ 583% ใหญ่กว่า 1.2 MB สำหรับไซต์บนมือถือระดับมัธยฐาน) การเพิ่มขึ้นนี้ไม่ได้นับรวมโดยวิดีโอเพียงอย่างเดียว (2.5 MB) เนื่องจากไซต์ที่มีวิดีโอมีแนวโน้มที่จะมีคุณลักษณะที่สมบูรณ์และน่าดึงดูดใจมากกว่า พวกเขาจึงใช้รูปภาพมากขึ้น (ไซต์เฉลี่ยมีมากกว่า 1 MB มากกว่า) CSS และ Javascript ตารางด้านล่างยังแสดงให้เห็นว่าค่ามัธยฐาน SpeedIndex (การวัดความเร็วของเนื้อหาที่ปรากฏบนหน้าจอ) สำหรับไซต์ที่มีวิดีโอช้ากว่าไซต์บนมือถือทั่วไป 3.7 วินาที โดยใช้เวลาในการโหลดมากถึง 11.5 วินาที

SpeedIndex ไบต์ทั้งหมด ไบต์วิดีโอ ไบต์ CSS ไบต์รูปภาพ ไบต์ JS
วีดีโอ 11544 6,963,579 2,526,098 80,327 1,596,062 708,978
เว็บไซต์ทั้งหมด 7780 1,201,802 0 40,648 449,585 336,973

สิ่งนี้แสดงให้เห็นอย่างชัดเจนว่าไซต์ที่มีการโต้ตอบมากกว่าและมีเนื้อหาวิดีโอ (โดยเฉลี่ย) ใช้เวลานานกว่าในการโหลดไซต์ที่ไม่มีวิดีโอ แต่เราสามารถเร่งการส่งวิดีโอได้หรือไม่? เราสามารถเรียนรู้อะไรได้อีกจากข้อมูลในมือ?

โฮสติ้งวิดีโอ

เมื่อตรวจสอบการส่งวิดีโอ ไฟล์ถูกให้บริการจากผู้ให้บริการ CDN หรือวิดีโอ หรือนักพัฒนาโฮสต์วิดีโอบนเซิร์ฟเวอร์ของตนเอง จากการตรวจสอบโดเมนของวิดีโอที่ส่งทางมือถือ เราพบว่ามีการใช้โดเมน 12,163 โดเมนเพื่อส่งวิดีโอ ซึ่งบ่งชี้ว่า ~49% ของเว็บไซต์ให้บริการไฟล์วิดีโอของตนเอง หากเราเรียงลําดับโดเมนตามความถี่ เราจะสามารถระบุโซลูชันการโฮสต์วิดีโอที่พบบ่อยที่สุดได้:

วิดีโอ Doman cnt %
fbcdn.net 116788 67%
akamaihd.net 11170 6%
googlevideo.com 10394 6%
cloudinary.com 3170 2%
amazonaws.com พ.ศ. 2482 1%
cloudfront.net พ.ศ. 2439 1%
pixfs.net พ.ศ. 2396 1%
akamaized.net 1573 1%
tedcdn.com 1507 1%
contentabc.com 1507 1%
vimeocdn.ccom 1373 1%
dailymotion.com 1337 1%
teads.tv 1022 1%
youtube.com 1007 1%
adstatic.com 998 1%

CDN และโดเมนยอดนิยมอย่าง Facebook, Akamai, Google, Cloudinary, AWS และ Cloudfront เป็นผู้นำ ซึ่งไม่น่าแปลกใจเลย อย่างไรก็ตาม เป็นเรื่องที่น่าสนใจที่จะเห็น YouTube และ Vimeo อยู่ในรายการ เนื่องจากเป็นเว็บไซต์แบ่งปันวิดีโอยอดนิยมสองแห่ง

มาดูการส่งวิดีโอ YouTube, Vimeo และ Facebook:

จำนวนวิดีโอ YouTube

ตามค่าเริ่มต้น หน้าที่ฝังวิดีโอ YouTube ไว้จะไม่ดาวน์โหลดไฟล์วิดีโอใด ๆ จริง ๆ เป็นเพียงสคริปต์และภาพตัวแทนเท่านั้น ดังนั้นจึงไม่ปรากฏในการค้นหาไซต์ที่มีการดาวน์โหลดวิดีโอ หนึ่งในการดาวน์โหลด Javascript สำหรับโปรแกรมเล่นวิดีโอ YouTube คือ www-embed-player.js เมื่อค้นหาไฟล์นี้ เราพบ 69k อินสแตนซ์บนไซต์มือถือ 66,647 ไซต์ ไซต์เหล่านี้มีค่ามัธยฐาน SpeedIndex 10,700 และการใช้ข้อมูล 3.31MB ดีกว่าไซต์ที่ดาวน์โหลดวิดีโอ แต่ก็ยังช้ากว่าไซต์ที่ไม่มีวิดีโอเลย ข้อมูลที่เพิ่มขึ้นสัมพันธ์โดยตรงกับรูปภาพและ Javascript มากขึ้น (ดังแสดงด้านล่าง)

ดัชนีความเร็ว ไบต์ทั้งหมด ไบต์วิดีโอ ไบต์ CSS ไบต์รูปภาพ ไบต์ JS
วีดีโอ 11544 6,963,579 2,526,098 80,327 1,596,062 708,978
เว็บไซต์ทั้งหมด 7780 1,201,802 0 40,648 449,585 336,973
สคริปต์ YouTube 10700 3,310,000 0 126,314 1,733,473 1,005,758

จำนวนวิดีโอ Vimeo

มีคำขอ 14,148 รายการสำหรับวิดีโอ Vimeo ใน HTTP Archive สำหรับการเล่นวิดีโอ ฉันเห็นคำขอไฟล์ player.js เพียง 5,848 คำขอ (ในรูปแบบ https://f.vimeocdn.com/p/3.2.0/js/player.js — หมายความว่าอาจมีวิดีโอหลายรายการในหน้าเดียว หรือบางที ตำแหน่งอื่นสำหรับไฟล์เครื่องเล่นวิดีโอ มี 17 เวอร์ชันที่แตกต่างกันของโปรแกรมเล่นที่มีอยู่ใน HTTP Archive โดยที่นิยมมากที่สุดคือ 3.1.5 และ 3.1.4:

URL cnt
https://f.vimeocdn.com/p/3.1.5/js/player.js พ.ศ. 2375
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

ดูเหมือนว่าจะไม่มีประสิทธิภาพเพิ่มขึ้นสำหรับไลบรารี Vimeo ใด ๆ — หน้าทั้งหมดมีเวลาโหลดที่ใกล้เคียงกัน

หมายเหตุ : การใช้ www-embed-player.js สำหรับ YouTube หรือ https://f.vimeocdn.com/p/*/js/player.js สำหรับ Vimeo ถือเป็นลายนิ้วมือที่ดีสำหรับบราวเซอร์ที่มีแคชสะอาด แต่ถ้าลูกค้ามีมาก่อน เรียกดูไซต์ที่มีวิดีโอที่ฝังอยู่ ไฟล์นี้อาจอยู่ในแคชของเบราว์เซอร์แล้ว และจะไม่ถูกร้องขอซ้ำ แต่อย่างที่ Andy Davies ได้กล่าวไว้เมื่อเร็วๆ นี้ นี่ไม่ใช่ข้อสันนิษฐานที่ปลอดภัย

จำนวนวิดีโอบน Facebook

น่าแปลกใจที่ข้อมูล HTTP Archive 67% ของคำขอวิดีโอทั้งหมดมาจาก CDN ของ Facebook ปรากฎว่าใน Chrome วิดเจ็ต Facebook บุคคลที่สามดาวน์โหลด 30% ของวิดีโอทั้งหมดที่โพสต์ภายในวิดเจ็ต (เอฟเฟกต์นี้ไม่เกิดขึ้นใน Safari หรือใน Firefox) ปรากฎว่าวิดเจ็ตของบุคคลที่สามที่เพิ่มด้วยรหัสเพียงไม่กี่บรรทัดนั้นรับผิดชอบ 57% ของวิดีโอทั้งหมดที่เห็นใน HTTP Archive

ประเภทไฟล์วิดีโอ

วิดีโอส่วนใหญ่ในหน้าที่ทดสอบคือ Mp4 หากเราดูวิดีโอทั้งหมดที่ดาวน์โหลด (ยกเว้นวิดีโอจาก Facebook) เราจะได้รับมุมมองต่อไปนี้:

นามสกุลไฟล์ จำนวนวิดีโอ %
.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%

ของไฟล์ที่ไม่มีนามสกุล — 10k เป็นไฟล์ googlevideo.com

เราเรียนรู้อะไรเกี่ยวกับไฟล์เหล่านี้ได้บ้าง มาดูไฟล์แต่ละประเภทกันเพื่อเรียนรู้เพิ่มเติมเกี่ยวกับเนื้อหาที่ส่ง

ฉันใช้ FFPROBE เพื่อสืบค้นไฟล์ MP4 ที่ไม่ซ้ำกันจำนวน 34k และได้รับข้อมูลสำหรับวิดีโอ 14,700 รายการ (วิดีโอจำนวนมากมีการเปลี่ยนแปลงหรือถูกลบใน 3 สัปดาห์จากการจับภาพ HTTP Archive ไปสู่การวิเคราะห์)

ข้อมูลวิดีโอ MP4

จากวิดีโอ 14.7k ในชุดข้อมูล 8,564 มีแทร็กเสียง (58%) วิดีโอขนาดสั้นที่เล่นอัตโนมัติหรือวิดีโอที่เล่นเป็นแบ็กกราวด์ไม่ต้องการเสียง ดังนั้นการตัดแทร็กเสียงจึงเป็นวิธีที่ดีในการลดขนาดไฟล์ (และเร่งความเร็วในการส่ง) ของวิดีโอของคุณ

สิ่งสำคัญที่สุดรองลงมาในการดาวน์โหลดวิดีโออย่างรวดเร็วคือมิติข้อมูล ขนาดที่ใหญ่ขึ้น (และในกรณีของวิดีโอ ควรพิจารณาสามมิติ: width × height × time ) ไฟล์วิดีโอก็จะใหญ่ขึ้น

MP4 Video Duration

วิดีโอ 14k ส่วนใหญ่ที่ศึกษานั้นสั้น: ระยะเวลามัธยฐาน (เปอร์เซ็นต์ไทล์ที่ 50) คือ 21 วินาที อย่างไรก็ตาม 10% ของวิดีโอที่สำรวจนั้นมีความยาวเกิน 2 นาที แน่นอนว่ากรณีการใช้งานจะถูกแบ่งออก แต่สำหรับวิดีโอวนรอบสั้น หรือวิดีโอพื้นหลัง — วิดีโอที่สั้นกว่าจะใช้ข้อมูลน้อยลง และดาวน์โหลดเร็วขึ้น

แผนภูมิคอลัมน์แบ่งความยาววิดีโอออกเป็น 10 วินาที
การกระจายของระยะเวลาวิดีโอ (ตัวอย่างขนาดใหญ่)

ความกว้างและความสูงของวิดีโอ MP4

ขนาดของวิดีโอบนหน้าจอกำหนดจำนวนพิกเซลที่แต่ละเฟรมจะต้องใช้ แผนภูมิด้านล่างแสดงความกว้างของวิดีโอต่างๆ ที่ส่งไปยังอุปกรณ์เคลื่อนที่ (โปรดทราบว่า Moto G4 มีขนาดหน้าจอ 1080×1920 และหน้าทั้งหมดจะถูกดูในโหมดแนวตั้ง)

แผนภูมิคอลัมน์ที่แสดงจำนวนความกว้างของวิดีโอแต่ละรายการที่สังเกตได้ในชุดข้อมูล
จำนวนวิดีโอตามความกว้าง (ตัวอย่างขนาดใหญ่)

ตามข้อมูลที่แสดง ความกว้างของวิดีโอที่ใช้มากที่สุดสองขนาดนั้นใหญ่กว่าหน้าจอ G4 อย่างมาก (เมื่ออยู่ในโหมดแนวตั้ง) วิดีโอทั้งหมด 49% ให้บริการโดยมีความกว้างมากกว่า 1080 พิกเซล Alcatel 1x ซึ่งเป็นอุปกรณ์ Android Go ใหม่ มีหน้าจอ 480×960 พิกเซล 77% ของวิดีโอที่ส่งในชุดตัวอย่างมีขนาดใหญ่กว่า 480 พิกเซล

เมื่อขนาดของวิดีโอลดลง ขนาดของไฟล์ก็ลดลงเช่นกัน (และเวลาในการส่งวิดีโอ) นี่คือเหตุผลหลักในการปรับขนาดวิดีโอ

ทำไมวิดีโอเหล่านี้จึงใหญ่มาก หากเราเชื่อมโยงวิดีโอที่แสดงบนอุปกรณ์เคลื่อนที่และเดสก์ท็อป เราพบว่าวิดีโอ 18% ที่แสดงบนอุปกรณ์เคลื่อนที่เป็นวิดีโอเดียวกันกับที่แสดงบนเดสก์ท็อป นี่คือ 'ปัญหา' ที่แก้ไขได้สำหรับรูปภาพเมื่อหลายปีก่อนด้วยรูปภาพที่ตอบสนอง การให้บริการวิดีโอที่มีขนาดต่างกันไปยังอุปกรณ์ขนาดต่างๆ กัน ทำให้เราสามารถมั่นใจได้ว่าวิดีโอที่สวยงามจะได้รับการนำเสนอ แต่ในขนาดและขนาดที่เหมาะสมกับอุปกรณ์

บิตเรตวิดีโอ MP4

บิตเรตของวิดีโอที่ส่งไปยังอุปกรณ์จะส่งผลอย่างมากต่อความสามารถในการเล่นวิดีโอ การทดสอบ HTTP Archive ทำงานบนการเชื่อมต่อ 3G ที่ความเร็วในการดาวน์โหลด 1.6 MBPS ในการเล่น (โดยไม่หยุดชะงัก) การดาวน์โหลดจะต้องเร็วกว่าการเล่น ให้ 80% ของบิตเรตที่มีให้กับไฟล์วิดีโอ (1.3 MBPS) 47% ของวิดีโอในชุดตัวอย่างมีบิตเรตมากกว่า 1.3 MBPS ซึ่งหมายความว่าเมื่อเล่นวิดีโอเหล่านี้ผ่านการเชื่อมต่อ 3G มีแนวโน้มที่จะหยุดทำงาน ส่งผลให้ลูกค้าไม่พอใจ 27% ของวิดีโอมีบิตเรตสูงกว่า 2.5 MBPS, 10% สูงกว่า 5 MBPS และวิดีโอ 35 รายการที่แสดงบนอุปกรณ์มือถือมีบิตเรต > 10 MBPS วิดีโอขนาดใหญ่เหล่านี้ไม่น่าจะเล่นได้โดยไม่ต้องหยุดการเชื่อมต่อจำนวนมาก — คงที่หรือมือถือ

แผนภูมิคอลัมน์แสดงรายการบิตเรตของวิดีโอในที่เก็บข้อมูล 500 KBPS
บิตเรตของวิดีโอที่สังเกตได้ (ตัวอย่างขนาดใหญ่)

อะไรนำไปสู่บิตเรตที่สูงขึ้น

วิดีโอขนาดใหญ่มักมีบิตเรตที่มากกว่า เนื่องจากวิดีโอขนาดใหญ่ขึ้นต้องการข้อมูลจำนวนมากขึ้นเพื่อเติมพิกเซลเพิ่มเติมบนอุปกรณ์ การอ้างอิงบิตเรตของแต่ละวิดีโอกับความกว้างเป็นการยืนยันว่า วิดีโอที่มีความกว้าง 1280 (สีส้ม) และ 1920 (สีเทา) มีการกระจายบิตเรตที่กว้างกว่ามาก (มีจุดข้อมูลทางด้านขวามากขึ้นในแผนภูมิ) คอลัมน์ที่มีเครื่องหมายสีเหลืองหมายถึงวิดีโอ 136 รายการที่มีความกว้าง 1920 และอัตราบิตระหว่าง 10-11 MBPS

แผนภูมิคอลัมน์ 3 มิติ แสดงให้เห็นว่าอัตราบิตและขนาดวิดีโอสัมพันธ์กันอย่างไร
บิตเรตเทียบกับ ความกว้างของวิดีโอ (ตัวอย่างขนาดใหญ่)

หากเรามองเห็นเฉพาะวิดีโอที่มีขนาดเกิน 1.6 MBPS จะเห็นได้ชัดว่าความละเอียดหน้าจอที่สูงขึ้น (1280 และ 1920) จะเป็นตัวกำหนดอัตราบิตของวิดีโอที่สูงขึ้น

แผนภูมิ 3 มิติแสดงว่าวิดีโอที่มีความกว้างมากขึ้นโดยทั่วไปมีบิตเรตที่สูงกว่า
อัตราบิตสูงและความกว้างของวิดีโอ (ตัวอย่างขนาดใหญ่)

MP4: HTTP กับ HTTPS

HTTP2 ได้กำหนดการส่งมอบเนื้อหาใหม่ด้วยการเชื่อมต่อแบบมัลติเพล็กซ์ — โดยที่จำเป็นต้องมีการเชื่อมต่อเพียงหนึ่งครั้งต่อเซิร์ฟเวอร์ สำหรับไฟล์ขนาดใหญ่ เช่น วิดีโอ HTTP2 ให้การปรับปรุงที่มีความหมายในการนำเสนอเนื้อหาหรือไม่ หากเราดูสถิติจาก HTTP Archive:

แผนภูมิวงกลมของ HTTP1 กับ HTTP2 สำหรับการส่งวิดีโอ
HTTP1 กับ HTTP2 (ตัวอย่างขนาดใหญ่)

ละเว้นวิดีโอ Facebook 116k (ทั้งหมดส่งผ่าน HTTP2) เราจะเห็นว่ามีการแบ่ง 50:50 ระหว่าง HTTP 1.1 และ HTTP2 อย่างไรก็ตาม HTTP1.1 สามารถใช้ HTTPS ได้ และเมื่อเรากรองการใช้งาน HTTPS เราพบว่า 81% ของวิดีโอสตรีมถูกส่งผ่าน HTTPS โดยที่ HTTP2 ถูกใช้มากกว่า HTTPS1.1 เล็กน้อย (41%:36%)

แผนภูมิวงกลมแสดง HTTP1 ที่ไม่ปลอดภัยและการแยกย่อยที่ปลอดภัยเพิ่มเติม
HTTP กับ HTTP2 และปลอดภัย (ตัวอย่างขนาดใหญ่)

อย่างที่คุณเห็น การเปรียบเทียบความเร็วของการส่งวิดีโอ HTTP และ HTTP2 นั้นอยู่ในระหว่างดำเนินการ

สตรีมมิ่งวิดีโอ HLS

การสตรีมวิดีโอโดยใช้อัตราบิตที่ปรับเปลี่ยนได้เป็นวิธีที่เหมาะที่สุดในการส่งวิดีโอไปยังผู้ใช้ปลายทาง วิดีโอแต่ละเวอร์ชันหลายเวอร์ชันสร้างขึ้นด้วยขนาดและบิตเรตที่แตกต่างกัน รายการสตรีมที่พร้อมใช้งานจะแสดงต่ออุปกรณ์เล่น และโปรแกรมเล่นวิดีโอบนอุปกรณ์สามารถเลือกสตรีมที่เหมาะสมที่สุดตามขนาดของหน้าจออุปกรณ์และสภาวะเครือข่ายที่มี มีไฟล์ Manifest 1,065 ไฟล์ (และไฟล์สตรีมวิดีโอ 14k) ในชุดข้อมูล HTTP Archive ที่ฉันตรวจสอบ

การเล่นสตรีมวิดีโอ

ตัวชี้วัดหลักประการหนึ่งในการสตรีมวิดีโอคือการเริ่มวิดีโอให้เร็วที่สุด แม้ว่าไฟล์ Manifest จะมีรายการสตรีมที่พร้อมใช้งาน แต่โปรแกรมเล่นไม่ทราบว่าแบนด์วิดท์ที่พร้อมใช้งานของเครือข่ายเมื่อเริ่มเล่น ในการเริ่มต้นการสตรีม และเนื่องจากผู้เล่นต้องเลือกการสตรีม โดยทั่วไปจะเลือกรายการแรกในรายการ เพื่ออำนวยความสะดวกในการเริ่มต้นวิดีโออย่างรวดเร็ว การวางสตรีมที่ถูกต้องที่ด้านบนสุดของไฟล์รายการของคุณเป็นสิ่งสำคัญ

หมายเหตุ : การใช้ Chrome Network Info API เพื่อสร้างไฟล์ Manifest ในทันทีอาจเป็นวิธีที่ดีในการเพิ่มประสิทธิภาพเนื้อหาวิดีโออย่างรวดเร็วเมื่อเริ่มต้น

วิธีหนึ่งเพื่อให้แน่ใจว่าวิดีโอเริ่มได้อย่างรวดเร็วคือการเริ่มต้นด้วยส่วนวิดีโอคุณภาพต่ำที่สุด เนื่องจากการดาวน์โหลดจะเร็วที่สุด คุณภาพวิดีโอเริ่มต้นอาจมีการแตกพิกเซล แต่เมื่อโปรแกรมเล่นเข้าใจคุณภาพเครือข่ายมากขึ้น ก็สามารถปรับสตรีมวิดีโอที่เหมาะสมกว่า (หวังว่าจะมีคุณภาพสูงขึ้น) ได้อย่างรวดเร็ว ด้วยเหตุนี้ มาดูบิตเรตของสตรีมเริ่มต้นใน HTTP Archive

แผนภูมิคอลัมน์แสดงบิตเรตเริ่มต้นในการสตรีมวิดีโอ วิดีโอจำนวนมากมีบิตเรตเริ่มต้นสูงเกินไปที่จะสตรีมบนมือถือ
บิตเรตเริ่มต้นสำหรับสตรีมวิดีโอ (ตัวอย่างขนาดใหญ่)

เส้นสีแดงในแผนภูมิด้านบนหมายถึง 1.5 MBPS (จำได้ว่าการทดสอบมือถือทำงานที่ 1.6 MBPS และไม่ได้ดาวน์โหลดเฉพาะเนื้อหาวิดีโอเท่านั้น) เราเห็น 30.5% ของสตรีมทั้งหมด (ทุกอย่างทางด้านซ้ายของบรรทัด) เริ่มต้นด้วยบิตเรตเริ่มต้นที่สูงกว่า 1.5 MBPS (และไม่น่าจะเล่นบนการเชื่อมต่อ 3G) 17% เริ่มต้นที่สูงกว่า 2 MBPS

จะเกิดอะไรขึ้นเมื่อการดาวน์โหลดวิดีโอช้ากว่าการเล่นวิดีโอจริง ในขั้นต้น โปรแกรมเล่นจะพยายามดาวน์โหลดไฟล์บิตเรตขนาดใหญ่ (เกินไป) แต่ตามความเร็วในการดาวน์โหลดจะพบปัญหา จากนั้นโปรแกรมเล่นจะเปลี่ยนไปใช้การดาวน์โหลดวิดีโอที่มีอัตราบิตต่ำกว่า ดังนั้นการดาวน์โหลดจึงเร็วกว่าการเล่น ปัญหาคือความพยายามในการดาวน์โหลดครั้งแรกต้องใช้เวลา และการเพิ่มความล่าช้าในการเริ่มเล่นวิดีโอนำไปสู่การละทิ้งลูกค้า

นอกจากนี้เรายังสามารถดูบิตเรตที่พบบ่อยที่สุดของไฟล์ .ts (ไฟล์ที่มีเนื้อหาวิดีโอ) เพื่อดูว่ามีการดาวน์โหลดบิตเรตใดบนมือถือ ข้อมูลนี้รวมถึงบิตเรตเริ่มต้น และไฟล์ใดๆ ที่ตามมาภายหลังที่ดาวน์โหลดระหว่างการรัน WebPageTest:

แผนภูมิคอลัมน์ของบิตเรตที่สังเกตได้เมื่อเริ่มการสตรีม
สังเกตบิตเรตมือถือ (ตัวอย่างขนาดใหญ่)

เราสามารถเห็นกลุ่มบิตเรตการสตรีมวิดีโอหลักสองกลุ่ม (100-300 KBPS และสูงสุดที่กว้างขึ้นจาก 300-1,000 MBPS) นี่คือจุดที่เราคาดหวังให้สตรีมปรากฏขึ้น เนื่องจากความเร็วของเครือข่ายจำกัดไว้ที่ 1.6 MBPS

เมื่อเปรียบเทียบข้อมูลกับเดสก์ท็อปแล้ว เห็นได้ชัดว่าอุปกรณ์เคลื่อนที่มีอัตราบิตที่ต่ำกว่า และสตรีมบนเดสก์ท็อปมีพีคสูงในช่วง 500-600 และ 800-900 KBPS ซึ่งไม่พบในอุปกรณ์เคลื่อนที่

แผนภูมิคอลัมน์เปรียบเทียบบิตเรตที่สังเกตได้บนมือถือและเดสก์ท็อป
สังเกตบิตเรตการสตรีมบนมือถือและเดสก์ท็อป (ตัวอย่างขนาดใหญ่)
แผนภูมิคอลัมน์เปรียบเทียบบิตเรตเริ่มต้นกับบิตเรตที่สังเกตได้สำหรับอุปกรณ์เคลื่อนที่และเดสก์ท็อป
บิตเรตที่สังเกตได้, มือถือ, เดสก์ท็อปเทียบกับบิตเรตเริ่มต้น (ตัวอย่างขนาดใหญ่)

เมื่อเราเปรียบเทียบบิตเรตเริ่มต้นที่สังเกตได้ (สีน้ำเงิน) กับไฟล์จริงที่ดาวน์โหลด จะเห็นได้ชัดเจนว่าสำหรับมือถือ โดยทั่วไปบิตเรตจะลดลงระหว่างการเล่นสตรีม ซึ่งบ่งชี้ว่าการลดบิตเรตเริ่มต้นสำหรับสตรีมวิดีโออาจช่วยปรับปรุงประสิทธิภาพของการเริ่มต้นวิดีโอและป้องกันไม่ให้หยุดทำงาน ในการเล่นวิดีโอในช่วงต้น วิดีโอเดสก์ท็อปก็ดูเหมือนจะลดลงเช่นกัน แต่ก็เป็นไปได้เช่นกันที่วิดีโอบางรายการจะย้ายไปเล่นที่ความเร็วการเล่นที่สูงขึ้น

บทสรุป

เนื้อหาวิดีโอบนเว็บช่วยเพิ่มการมีส่วนร่วมและความพึงพอใจของลูกค้า หน้าที่โหลดเร็วมีผลเช่นเดียวกัน การเพิ่มวิดีโอลงในเว็บไซต์ของคุณจะทำให้เวลาในการแสดงหน้าเว็บช้าลง ทำให้ต้องมีความสมดุลระหว่างการโหลดหน้าเว็บโดยรวมกับเนื้อหาวิดีโอ หากต้องการลดขนาดเนื้อหาวิดีโอของคุณ ตรวจสอบให้แน่ใจว่าคุณมีเวอร์ชันที่มีขนาดเหมาะสมสำหรับขนาดอุปกรณ์เคลื่อนที่ และใช้วิดีโอที่สั้นกว่าเมื่อเป็นไปได้

หากการเล่นวิดีโอของคุณไม่จำเป็น ให้ทำตามเส้นทางของ YouTube และ Vimeo — ดาวน์โหลดชิ้นส่วนที่จำเป็นทั้งหมดเพื่อให้พร้อมสำหรับการเล่น แต่อย่าดาวน์โหลดส่วนวิดีโอใดๆ จนกว่าผู้ใช้จะกดเล่น สุดท้ายนี้ หากคุณกำลังสตรีมวิดีโอ ให้เริ่มต้นด้วยการตั้งค่าคุณภาพต่ำสุดเพื่อให้แน่ใจว่าสามารถเล่นวิดีโอได้อย่างรวดเร็ว

ในโพสต์ถัดไปในวิดีโอ ฉันจะนำสิ่งที่ค้นพบทั่วไปเหล่านี้ และเจาะลึกถึงวิธีแก้ไขปัญหาที่อาจเกิดขึ้นด้วยตัวอย่าง