การเล่นวิดีโอบนเว็บ: สถานะปัจจุบันของวิดีโอ (ตอนที่ 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 ไซต์บนมือถือโดยไม่มีวิดีโอบนเดสก์ท็อป)
หน้าเพจบนมือถือที่มีค่าเฉลี่ยซึ่งมีวิดีโอมีน้ำหนักอยู่ที่ 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 นาที แน่นอนว่ากรณีการใช้งานจะถูกแบ่งออก แต่สำหรับวิดีโอวนรอบสั้น หรือวิดีโอพื้นหลัง — วิดีโอที่สั้นกว่าจะใช้ข้อมูลน้อยลง และดาวน์โหลดเร็วขึ้น
ความกว้างและความสูงของวิดีโอ 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 วิดีโอขนาดใหญ่เหล่านี้ไม่น่าจะเล่นได้โดยไม่ต้องหยุดการเชื่อมต่อจำนวนมาก — คงที่หรือมือถือ
อะไรนำไปสู่บิตเรตที่สูงขึ้น
วิดีโอขนาดใหญ่มักมีบิตเรตที่มากกว่า เนื่องจากวิดีโอขนาดใหญ่ขึ้นต้องการข้อมูลจำนวนมากขึ้นเพื่อเติมพิกเซลเพิ่มเติมบนอุปกรณ์ การอ้างอิงบิตเรตของแต่ละวิดีโอกับความกว้างเป็นการยืนยันว่า วิดีโอที่มีความกว้าง 1280 (สีส้ม) และ 1920 (สีเทา) มีการกระจายบิตเรตที่กว้างกว่ามาก (มีจุดข้อมูลทางด้านขวามากขึ้นในแผนภูมิ) คอลัมน์ที่มีเครื่องหมายสีเหลืองหมายถึงวิดีโอ 136 รายการที่มีความกว้าง 1920 และอัตราบิตระหว่าง 10-11 MBPS
หากเรามองเห็นเฉพาะวิดีโอที่มีขนาดเกิน 1.6 MBPS จะเห็นได้ชัดว่าความละเอียดหน้าจอที่สูงขึ้น (1280 และ 1920) จะเป็นตัวกำหนดอัตราบิตของวิดีโอที่สูงขึ้น
MP4: HTTP กับ HTTPS
HTTP2 ได้กำหนดการส่งมอบเนื้อหาใหม่ด้วยการเชื่อมต่อแบบมัลติเพล็กซ์ — โดยที่จำเป็นต้องมีการเชื่อมต่อเพียงหนึ่งครั้งต่อเซิร์ฟเวอร์ สำหรับไฟล์ขนาดใหญ่ เช่น วิดีโอ HTTP2 ให้การปรับปรุงที่มีความหมายในการนำเสนอเนื้อหาหรือไม่ หากเราดูสถิติจาก HTTP Archive:
ละเว้นวิดีโอ Facebook 116k (ทั้งหมดส่งผ่าน HTTP2) เราจะเห็นว่ามีการแบ่ง 50:50 ระหว่าง HTTP 1.1 และ HTTP2 อย่างไรก็ตาม HTTP1.1 สามารถใช้ HTTPS ได้ และเมื่อเรากรองการใช้งาน HTTPS เราพบว่า 81% ของวิดีโอสตรีมถูกส่งผ่าน HTTPS โดยที่ HTTP2 ถูกใช้มากกว่า HTTPS1.1 เล็กน้อย (41%:36%)
อย่างที่คุณเห็น การเปรียบเทียบความเร็วของการส่งวิดีโอ 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 — ดาวน์โหลดชิ้นส่วนที่จำเป็นทั้งหมดเพื่อให้พร้อมสำหรับการเล่น แต่อย่าดาวน์โหลดส่วนวิดีโอใดๆ จนกว่าผู้ใช้จะกดเล่น สุดท้ายนี้ หากคุณกำลังสตรีมวิดีโอ ให้เริ่มต้นด้วยการตั้งค่าคุณภาพต่ำสุดเพื่อให้แน่ใจว่าสามารถเล่นวิดีโอได้อย่างรวดเร็ว
ในโพสต์ถัดไปในวิดีโอ ฉันจะนำสิ่งที่ค้นพบทั่วไปเหล่านี้ และเจาะลึกถึงวิธีแก้ไขปัญหาที่อาจเกิดขึ้นด้วยตัวอย่าง