เรียนรู้เกี่ยวกับการวัดภาพเคลื่อนไหว วิธีคิดเกี่ยวกับเฟรมของภาพเคลื่อนไหว และความราบรื่นของหน้าโดยรวม
คุณอาจเคยพบปัญหาหน้าที่ "กระตุก" หรือ "ค้าง" ระหว่างการเลื่อนหรือภาพเคลื่อนไหว เราชอบพูดได้ว่าประสบการณ์เหล่านี้ไม่ได้ราบรื่น เพื่อแก้ไขปัญหาประเภทนี้ ทีม Chrome ได้พยายามเพิ่มการรองรับเครื่องมือสำหรับห้องทดลองสำหรับการตรวจจับภาพเคลื่อนไหว ตลอดจนปรับปรุงการวินิจฉัยไปป์ไลน์การแสดงภาพภายใน Chromium อย่างต่อเนื่อง
เราต้องการแชร์ความคืบหน้าล่าสุด ให้แนวทางเกี่ยวกับเครื่องมือที่เป็นรูปธรรม และพูดคุยเกี่ยวกับแนวคิดสำหรับเมตริกความราบรื่นของภาพเคลื่อนไหวในอนาคต เรายินดีรับฟังความคิดเห็นจากคุณเสมอ
โพสต์นี้จะครอบคลุมหัวข้อหลักๆ 3 หัวข้อ ได้แก่
- ภาพเคลื่อนไหวและเฟรมของภาพเคลื่อนไหวคร่าวๆ
- ปัจจุบันสิ่งที่เราคิดเกี่ยวกับการวัดความลื่นไหลของภาพเคลื่อนไหวโดยรวม
- คำแนะนำที่นำไปใช้ได้จริงบางส่วนสำหรับการใช้เครื่องมือในห้องทดลองในวันนี้
ภาพเคลื่อนไหวคืออะไร
แอนิเมชันช่วยให้เนื้อหามีชีวิตชีวา ภาพเคลื่อนไหวทำให้ประสบการณ์ดูเป็นธรรมชาติ เข้าใจง่าย และสนุกมากขึ้น โดยเฉพาะเพื่อตอบสนองต่อการโต้ตอบของผู้ใช้
แต่ภาพเคลื่อนไหวที่ทำได้ไม่ดี หรือแค่เพิ่มภาพเคลื่อนไหวมากเกินไป อาจทำให้ประสบการณ์แย่ลงและทำให้ไม่สนุกเลย เราอาจจะเคยโต้ตอบแต่อินเทอร์เฟซที่เพิ่มเอฟเฟกต์การเปลี่ยนที่ "มีประโยชน์" มากเกินไป ซึ่งจริงๆ แล้วกลายเป็นศัตรูต่อประสบการณ์ที่มีประสิทธิภาพต่ำ ดังนั้น ผู้ใช้บางรายอาจต้องการลดการเคลื่อนไหว ซึ่งเป็นค่ากำหนดของผู้ใช้ที่คุณควรยึดตาม
ภาพเคลื่อนไหวทำงานอย่างไร
โดยสรุปแล้ว ไปป์ไลน์การแสดงผลประกอบด้วยขั้นตอนตามลำดับ 2-3 ขั้นตอน ดังนี้
- รูปแบบ: คำนวณรูปแบบ ที่ใช้กับองค์ประกอบ
- เลย์เอาต์: สร้างเรขาคณิตและตำแหน่ง สำหรับแต่ละองค์ประกอบ
- สี: เติมพิกเซลของแต่ละองค์ประกอบลงในเลเยอร์
- วัสดุเชิงประกอบ: วาดเลเยอร์ลงในหน้าจอ
แม้ว่าการกําหนดภาพเคลื่อนไหวจะมีหลายวิธี แต่ทุกวิธีจะมีหลักการพื้นฐานแบบใดแบบหนึ่ง ดังนี้
- การปรับคุณสมบัติเลย์เอาต์
- การปรับคุณสมบัติ paint
- การปรับคุณสมบัติ Composite
เนื่องจากระยะเหล่านี้เป็นแบบเรียงตามลำดับ จึงจำเป็นต้องกำหนดภาพเคลื่อนไหวในรูปของพร็อพเพอร์ตี้ที่อยู่ต่ำลงมาในไปป์ไลน์ ยิ่งดำเนินการอัปเดตเร็วเท่าไร ค่าใช้จ่ายก็จะยิ่งมากขึ้นเท่านั้นและมีโอกาสราบรื่นน้อยลง (ดูรายละเอียดเพิ่มเติมในประสิทธิภาพในการแสดงผล)
แม้ว่าการสร้างภาพเคลื่อนไหวของพร็อพเพอร์ตี้เลย์เอาต์ก็จะมีต้นทุนในการดำเนินการ แม้ว่าค่าใช้จ่ายเหล่านั้นจะไม่ได้ชัดเจนทันทีก็ตาม ภาพเคลื่อนไหวควรกำหนดในรูปของการเปลี่ยนแปลงคุณสมบัติผสมเมื่อเป็นไปได้
การกำหนดภาพเคลื่อนไหว CSS เชิงรับหรือการใช้เว็บภาพเคลื่อนไหว และการทำให้พร็อพเพอร์ตี้แบบผสมเคลื่อนไหวเป็นขั้นตอนแรกที่ควรทำในการรับประกันภาพเคลื่อนไหวที่ราบรื่นและมีประสิทธิภาพ แต่ถึงกระนั้น การทำเช่นนั้นก็ไม่สามารถรับประกันความลื่นไหลได้ เพราะแม้แต่ภาพเคลื่อนไหวบนเว็บที่มีประสิทธิภาพก็มีข้อจำกัดด้านประสิทธิภาพเช่นกัน ด้วยเหตุนี้การวัดผลจึงเป็นสิ่งสำคัญเสมอ
เฟรมภาพเคลื่อนไหวคืออะไร
การอัปเดตภาพนำเสนอของหน้าเว็บจะใช้เวลาสักครู่จึงจะปรากฏ การเปลี่ยนแปลงภาพจะนำไปสู่เฟรมภาพเคลื่อนไหวใหม่ ซึ่งจะแสดงในจอแสดงผลของผู้ใช้ในท้ายที่สุด
แสดงการอัปเดตในบางช่วงเวลา การอัปเดตภาพจึงรวมกันเป็นกลุ่ม จอแสดงผลหลายๆ จอจะอัปเดตข้อมูลตามช่วงเวลาคงที่ เช่น 60 ครั้งต่อวินาที (ซึ่งก็คือ 60 Hz) ส่วนจอแสดงผลที่ทันสมัยมากขึ้นบางรุ่นอาจให้อัตราการรีเฟรชสูงขึ้น (90–120 Hz จะเป็นสิ่งที่พบได้ทั่วไป) บ่อยครั้งที่จอแสดงผลเหล่านี้สามารถปรับระหว่างอัตราการรีเฟรชตามต้องการ หรือแม้กระทั่งมอบอัตราเฟรมที่แปรผันทั้งหมดได้
เป้าหมายของแอปพลิเคชันอย่างเช่น เกมหรือเบราว์เซอร์ คือการประมวลผลการอัปเดตภาพเหล่านี้ทั้งหมดและสร้างเฟรมภาพเคลื่อนไหวที่สมบูรณ์ภายในกำหนดเวลาทุกครั้ง โปรดทราบว่าเป้าหมายนี้จะแตกต่างจากงานสำคัญอื่นๆ ของเบราว์เซอร์โดยสิ้นเชิง เช่น การโหลดเนื้อหาจากเครือข่ายอย่างรวดเร็วหรือการทำงาน JavaScript อย่างมีประสิทธิภาพ
ในบางสถานการณ์ การอัปเดตภาพทั้งหมดให้เสร็จภายในกำหนดเวลาที่จอแสดงผลกำหนดอาจทำได้ยากเกินไป ในกรณีนี้ เบราว์เซอร์จะวางเฟรมลง หน้าจอไม่ดับไป แต่กลับปรากฏขึ้นซ้ำๆ คุณจะเห็นการอัปเดตภาพเดิมนานขึ้นเล็กน้อย ซึ่งก็คือเฟรมภาพเคลื่อนไหวเดียวกันกับที่แสดงในโอกาสของเฟรมก่อนหน้า
ซึ่งสิ่งนี้เกิดขึ้นบ่อยอยู่แล้ว เนื้อหาเหล่านี้ไม่อาจรับรู้ได้เสมอไป โดยเฉพาะกับเนื้อหาแบบคงที่หรือเนื้อหาที่มีลักษณะเหมือนเอกสาร ซึ่งมักเป็นเนื้อหาทั่วไปในแพลตฟอร์มบนเว็บโดยเฉพาะ เฟรมที่ลดต่ำลงจะปรากฏให้เห็นเฉพาะเมื่อมีการอัปเดตภาพที่สำคัญ เช่น ภาพเคลื่อนไหว ซึ่งเราต้องมีการอัปเดตภาพเคลื่อนไหวเป็นประจำเพื่อให้แสดงการเคลื่อนไหวได้อย่างราบรื่น
สิ่งที่ส่งผลต่อเฟรมของภาพเคลื่อนไหว
นักพัฒนาเว็บมีส่วนสำคัญต่อความสามารถของเบราว์เซอร์ในการแสดงผลและนำเสนอการอัปเดตภาพได้อย่างรวดเร็วและมีประสิทธิภาพ
ตัวอย่างมีดังต่อไปนี้
- การใช้เนื้อหาขนาดใหญ่หรือต้องใช้ทรัพยากรมากเกินไปในการถอดรหัสบนอุปกรณ์เป้าหมายอย่างรวดเร็ว
- การใช้เลเยอร์มากเกินไปต้องใช้หน่วยความจำ GPU มากเกินไป
- การกำหนดรูปแบบ CSS หรือภาพเคลื่อนไหวบนเว็บที่ซับซ้อนเกินไป
- การใช้รูปแบบป้องกันการออกแบบที่ปิดใช้การเพิ่มประสิทธิภาพการแสดงผลอย่างรวดเร็ว
- มี JS มากเกินไปในเทรดหลัก ส่งผลให้มีงานที่ใช้เวลานานซึ่งจะบล็อกการอัปเดตภาพ
แต่จะรู้ได้อย่างไรว่าเฟรมภาพเคลื่อนไหวเลยกำหนดเวลาไปแล้วและทำให้เฟรมกระตุก
วิธีการหนึ่งที่เป็นไปได้คือการใช้แบบสำรวจ requestAnimationFrame()
แต่ยังมีข้อเสียหลายประการ requestAnimationFrame()
หรือ "rAF" จะบอกเบราว์เซอร์ว่าคุณต้องการสร้างภาพเคลื่อนไหวและขอโอกาสทำก่อนขั้นตอนการแสดงผลถัดไปของไปป์ไลน์การแสดงผล หากระบบไม่เรียกใช้ฟังก์ชันเรียกกลับในเวลาที่คุณต้องการ หมายความว่าระบบไม่ได้เรียกใช้สีและข้ามเฟรมอย่างน้อย 1 รายการ แบบสำรวจและการนับความถี่ที่เรียก rAF ช่วยให้คุณคำนวณเมตริก "เฟรมต่อวินาที" (FPS) ได้
let frameTimes = [];
function pollFramesPerSecond(now) {
frameTimes = [...frameTimes.filter(t => t > now - 1000), now];
requestAnimationFrame(pollFramesPerSecond);
console.log('Frames per second:', frameTimes.length);
}
requestAnimationFrame(pollFramesPerSecond);
การใช้แบบสำรวจของ requestAnimationFrame()
ไม่ใช่ความคิดที่ดีเนื่องจากสาเหตุหลายประการต่อไปนี้
- ทุกสคริปต์ต้องตั้งค่าลูปแบบสำรวจของตัวเอง
- เนื่องจากสามารถบล็อกเส้นทางวิกฤติได้
- แม้ว่าการโพล rAF จะรวดเร็ว แต่ก็อาจป้องกันไม่ให้
requestIdleCallback()
ตั้งเวลาบล็อกที่ไม่มีการใช้งานเป็นเวลานานเมื่อใช้อย่างต่อเนื่อง (การบล็อกที่มีเฟรมเกินเฟรมเดียว) - ในทำนองเดียวกัน การไม่มีการบล็อกการไม่ใช้งานที่ยาวนานจะทำให้เบราว์เซอร์ไม่สามารถกำหนดเวลางานอื่นๆ ที่ใช้เวลานาน (เช่น การเก็บรวบรวมขยะที่นานขึ้น และการทำงานเบื้องหลังหรือการทำงานที่คาดเดาอื่นๆ)
- หากเปิดและปิดแบบสำรวจ คุณอาจพลาดกรณีที่มีการใช้งบประมาณของเฟรมเกิน
- แบบสำรวจจะรายงานผลบวกลวงในกรณีที่เบราว์เซอร์ใช้ความถี่ในการอัปเดตที่เปลี่ยนแปลงได้ (เช่น เนื่องจากพลังงานหรือสถานะการแสดงผล)
- และที่สำคัญที่สุดคือมันไม่ได้บันทึกการอัปเดต ภาพเคลื่อนไหวทุกประเภท
การทำงานมากเกินไปในเทรดหลักอาจส่งผลต่อความสามารถในการดูเฟรมภาพเคลื่อนไหว ลองดูตัวอย่าง Jam เพื่อดูว่าภาพเคลื่อนไหวที่ขับเคลื่อนด้วย RAF เมื่อมีงานมากเกินไปในเทรดหลัก (เช่น เลย์เอาต์) จะทำให้เฟรมลดลงและโค้ดเรียกกลับ rAF น้อยลง รวมถึง FPS ที่ต่ำลง
เมื่อเทรดหลักหยุดชะงัก การอัปเดตภาพจะเริ่มกระตุก นั่นแหละ!
เครื่องมือวัดผลจำนวนมากมุ่งเน้นที่ความสามารถของเทรดหลักอย่างมากเพื่อให้แสดงผลได้ทันเวลา และช่วยให้เฟรมภาพเคลื่อนไหวทำงานได้อย่างราบรื่น แต่นี่ไม่ใช่เรื่องราวทั้งหมด ลองพิจารณาตัวอย่างต่อไปนี้
วิดีโอด้านบนแสดงหน้าเว็บที่แทรกงานที่ยาวลงในเทรดหลักเป็นระยะๆ งานที่ใช้เวลานานเหล่านี้ทำลายความสามารถของหน้าเว็บในการมอบการอัปเดตภาพบางประเภทโดยสิ้นเชิง และคุณจะเห็นได้ว่า FPS ที่รายงานของ requestAnimationFrame()
ลดลงต่อเนื่องกันเหลือ 0
ถึงกระนั้น หน้าเว็บก็จะยังคงเลื่อนลงได้อย่างราบรื่นแม้จะงานที่ใช้เวลานาน นั่นเป็นเพราะในเบราว์เซอร์สมัยใหม่ การเลื่อนมักจะเป็นแบบแยกชุดข้อความ ซึ่งขับเคลื่อนโดยตัวจัดวางองค์ประกอบทั้งหมด
นี่คือตัวอย่างที่มีเฟรมที่ตกลงกันหลายเฟรมในเทรดหลัก แต่ยังคงมีเฟรมสำหรับการเลื่อนที่ส่งสําเร็จหลายเฟรมในเทรดคอมโพสิเตอร์ เมื่องานที่ใช้เวลานานเสร็จสมบูรณ์แล้ว การอัปเดตสี Thread หลักจะไม่มีการเปลี่ยนแปลงรูปลักษณ์
สำหรับเฟรมภาพเคลื่อนไหว เรื่องราวไม่ได้ง่ายแบบนั้น
เฟรมของภาพเคลื่อนไหว: การอัปเดตที่สำคัญ
ตัวอย่างด้านบนแสดงให้เห็นว่า requestAnimationFrame()
เรื่องราวยังมีอะไรอีกมากมาย
การอัปเดตภาพเคลื่อนไหวและเฟรมของภาพเคลื่อนไหวจะมีความสำคัญเมื่อใด โดยเกณฑ์ต่อไปนี้ เรากำลังพิจารณาและต้องการทราบความคิดเห็น
- การอัปเดตชุดข้อความหลักและตัวจัดวางองค์ประกอบ
- ไม่มีการอัปเดตสี
- กำลังตรวจจับภาพเคลื่อนไหว
- คุณภาพกับปริมาณ
การอัปเดตชุดข้อความหลักและตัวจัดวางองค์ประกอบ
การอัปเดตเฟรมของภาพเคลื่อนไหวไม่ใช่บูลีน แต่ไม่ได้หมายความว่าเฟรมอาจหลุด หรือนำเสนออย่างสมบูรณ์แล้วเท่านั้น ระบบอาจแสดงเฟรมภาพเคลื่อนไหวบางส่วนเนื่องจากสาเหตุหลายประการ กล่าวคือ เนื้อหาอาจมีเนื้อหาที่ไม่มีอัปเดตได้พร้อมกัน และยังมีการอัปเดตภาพใหม่ๆ บางส่วนด้วย
ตัวอย่างที่พบบ่อยที่สุดคือเมื่อเบราว์เซอร์ไม่สามารถอัปเดตเทรดหลักใหม่ภายในกำหนดเวลาของเฟรม แต่มีการอัปเดตเทรด Compositor ใหม่ (เช่น ตัวอย่างการเลื่อนแบบชุดข้อความจากก่อนหน้านี้)
เหตุผลสำคัญประการหนึ่งว่าทำไมการใช้ภาพเคลื่อนไหวแบบประกาศเพื่อสร้างภาพเคลื่อนไหวของพร็อพเพอร์ตี้ผสมคือ การดำเนินการดังกล่าวจะทำให้ภาพเคลื่อนไหวสามารถขับเคลื่อนด้วยเทรดตัวปรับแต่งทั้งหมดแม้ว่าเทรดหลักจะไม่ว่างก็ตาม ภาพเคลื่อนไหวประเภทนี้สามารถให้การอัปเดตภาพได้อย่างมีประสิทธิภาพและไปพร้อมกัน
ในทางตรงกันข้าม อาจมีบางกรณีที่การอัปเดตเทรดหลักพร้อมให้นำเสนอได้ในที่สุด แต่หลังจากพ้นกำหนดเวลาของเฟรมไปแล้วหลายครั้ง เบราว์เซอร์จะมีอัปเดตใหม่บางส่วน แต่อาจไม่ใช่เวอร์ชันล่าสุด
พูดกว้างๆ คือเราพิจารณาเฟรมที่มีการอัปเดตภาพใหม่ๆ เป็นเฟรมบางส่วนโดยไม่มีการอัปเดตภาพใหม่ทั้งหมด เฟรมบางส่วนเป็นเรื่องปกติ ตามหลักการแล้ว การอัปเดตบางส่วนอย่างน้อยจะต้องมีการอัปเดตภาพที่สำคัญที่สุด เช่น ภาพเคลื่อนไหว แต่สามารถเกิดขึ้นได้ก็ต่อเมื่อภาพเคลื่อนไหวนั้นขับเคลื่อนด้วยเธรดคอมโพสิเตอร์
ไม่มีการอัปเดตสี
การอัปเดตบางส่วนอีกประเภทหนึ่งคือเมื่อสื่ออย่างรูปภาพยังถอดรหัสและแรสเตอร์ได้ทันเวลาสําหรับการนำเสนอเฟรม
หรือแม้ว่าหน้าเว็บจะเป็นภาพนิ่งโดยสมบูรณ์ แต่เบราว์เซอร์ก็อาจยังคงไม่แสดงการอัปเดตภาพในระหว่างการเลื่อนอย่างรวดเร็ว นั่นเป็นเพราะระบบอาจละทิ้งการแปลงพิกเซลของเนื้อหานอกวิวพอร์ตที่มองเห็นได้เพื่อประหยัดหน่วยความจำ GPU การแสดงพิกเซลต้องใช้เวลาและอาจใช้เวลาในการแสดงผลทุกอย่างนานกว่า 1 เฟรมหลังจากการเลื่อนขนาดใหญ่ เช่น การสะบัดนิ้ว หรือที่เรียกกันโดยทั่วไปว่าลายกระดานหมากรุก
โอกาสในการแสดงผลแต่ละเฟรมช่วยให้คุณติดตามได้ว่าการอัปเดตภาพล่าสุดเกิดขึ้นในหน้าจอได้มากน้อยเพียงใด การวัดความสามารถในการดำเนินการดังกล่าวในหลายเฟรม (หรือเวลา) นั้นเรียกกันโดยทั่วไปว่าอัตราการส่งข้อมูลของเฟรม
หาก GPU หยุดทำงานจริง เบราว์เซอร์ (หรือแพลตฟอร์ม) อาจเริ่มเร่งอัตราการพยายามอัปเดตภาพ ซึ่งทำให้อัตราเฟรมที่มีประสิทธิภาพลดลง แม้ว่าในทางเทคนิคแล้วจะเป็นการลดจำนวนการอัปเดตเฟรมที่ลดลง แต่ภาพจะยังคงแสดงเป็นอัตราการส่งข้อมูลของเฟรมที่ต่ำกว่า
แต่อัตราการส่งข้อมูลของเฟรมต่ำก็ไม่ได้แย่เสมอไป หากหน้าเว็บส่วนใหญ่ไม่มีการใช้งานและไม่มีภาพเคลื่อนไหวที่ทำงานอยู่ อัตราเฟรมต่ำจะสวยงามพอๆ กับอัตราเฟรมสูง (และช่วยประหยัดแบตเตอรี่ได้)
อัตราการส่งข้อมูลของเฟรมจะมีความสำคัญเมื่อใด
กำลังตรวจจับภาพเคลื่อนไหว
อัตราการส่งข้อมูลของเฟรมสูงมีความสำคัญ โดยเฉพาะในช่วงเวลาที่มีภาพเคลื่อนไหวที่สำคัญ ภาพเคลื่อนไหวประเภทต่างๆ จะขึ้นอยู่กับการอัปเดตภาพจากเทรดเฉพาะ (หลัก คอมโพสิเตอร์ หรือผู้ปฏิบัติงาน) ดังนั้นการอัปเดตภาพจึงขึ้นอยู่กับชุดข้อความที่อัปเดตภายในกำหนดเวลา เราว่าชุดข้อความที่ระบุส่งผลต่อความลื่นไหลเมื่อใดก็ตามที่มีภาพเคลื่อนไหวที่ใช้งานอยู่ซึ่งขึ้นอยู่กับการอัปเดตชุดข้อความนั้น
ภาพเคลื่อนไหวบางประเภทกำหนดและตรวจจับได้ง่ายกว่าประเภทอื่นๆ ภาพเคลื่อนไหวแบบประกาศหรือภาพเคลื่อนไหวที่ผู้ใช้ป้อนเข้ามาจะมีความชัดเจนมากกว่าภาพเคลื่อนไหวที่มาจาก JavaScript ที่นำไปใช้เป็นการอัปเดตคุณสมบัติรูปแบบที่เคลื่อนไหวได้เป็นระยะๆ
แม้จะใช้ requestAnimationFrame()
แล้ว คุณก็ไม่สามารถคิดได้ว่าการเรียกใช้ rAF ทุกครั้งต้องมีการอัปเดตภาพหรือภาพเคลื่อนไหว ตัวอย่างเช่น การใช้โพล rAF เพื่อติดตามอัตราเฟรม (ดังที่แสดงด้านบน) เพียงอย่างเดียวไม่ควรส่งผลต่อการวัดความลื่นไหลเพราะไม่มีการอัปเดตภาพ
คุณภาพกับปริมาณ
สุดท้าย การตรวจหาภาพเคลื่อนไหวและการอัปเดตเฟรมของภาพเคลื่อนไหวเป็นเพียงส่วนหนึ่งของเรื่องราวเท่านั้น เนื่องจากระบบจะบันทึกปริมาณการอัปเดตภาพเคลื่อนไหวเท่านั้น ไม่ใช่คุณภาพ
เช่น คุณอาจเห็นอัตราเฟรมที่ 60 FPS คงที่ขณะดูวิดีโอ โดยในทางเทคนิคแล้วก็ราบรื่นมาก แต่ตัววิดีโอเองอาจมีอัตราบิตต่ำ หรือมีปัญหาเกี่ยวกับการบัฟเฟอร์เครือข่าย ตัวเลขนี้ไม่ได้บันทึกตามเมตริกความราบรื่นของภาพเคลื่อนไหวโดยตรง แต่อาจทำให้ผู้ใช้ตกใจ
หรือเกมที่ใช้ประโยชน์จาก <canvas>
(หรืออาจจะใช้เทคนิคอย่างภาพนอกหน้าจอเพื่อดูแลให้อัตราเฟรมคงที่) ในทางเทคนิคอาจทำได้อย่างราบรื่นอย่างสมบูรณ์แบบในเรื่องเฟรมภาพเคลื่อนไหว แต่ในขณะเดียวกันก็โหลดเนื้อหาเกมคุณภาพสูงในฉากหรือไม่ได้แสดงภาพองค์ประกอบต่างๆ
และแน่นอนว่าเว็บไซต์อาจมีภาพเคลื่อนไหวที่ไม่ดีมากๆ 🙂
ฉันคิดว่าพวกเขาคงจะดีไม่น้อยเลยที่สละเวลามาฟัง!
สถานะของเฟรมภาพเคลื่อนไหวเดียว
เนื่องจากเฟรมอาจมีการนำเสนอบางส่วน หรือเฟรมหลุดอาจเกิดขึ้นในลักษณะที่ไม่ส่งผลต่อความราบรื่น เราจึงเริ่มคิดว่าแต่ละเฟรมมีคะแนนความสมบูรณ์หรือความราบรื่น
ต่อไปนี้เป็นแง่มุมต่างๆ ที่เราตีความสถานะของเฟรมภาพเคลื่อนไหวเดียว โดยเรียงลำดับจากดีที่สุดไปหาแย่ที่สุด
ไม่ต้องการการอัปเดต | เวลาที่ไม่มีการใช้งาน ทำซ้ำเฟรมก่อนหน้า |
นำเสนออย่างเต็มรูปแบบ | มีการอัปเดตเทรดหลักภายในกำหนดเวลาหรือไม่ต้องการอัปเดตเทรดหลัก |
นำเสนอบางส่วน | เฉพาะคอมโพสิตเท่านั้น การอัปเดตเทรดหลักที่ล่าช้าไม่มีการเปลี่ยนแปลงภาพ |
นำเสนอบางส่วน | เฉพาะคอมโพสิตเท่านั้น เทรดหลักมีการอัปเดตภาพ แต่การอัปเดตนั้นไม่มีภาพเคลื่อนไหวที่ส่งผลต่อความลื่นไหล |
นำเสนอบางส่วน | เฉพาะคอมโพสิตเท่านั้น เทรดหลักมีการอัปเดตภาพที่ส่งผลกระทบต่อความราบรื่น แต่มีการส่งเฟรมที่ไม่มีอัปเดตก่อนหน้านี้และมีการใช้แทน |
นำเสนอบางส่วน | เฉพาะคอมโพสิตเท่านั้น หากไม่มีการอัปเดตหลักที่ต้องการ และการอัปเดตตัวจัดวางองค์ประกอบจะมีภาพเคลื่อนไหวที่ส่งผลต่อความลื่นไหล |
นำเสนอบางส่วน | เฉพาะคอมโพสิตเท่านั้น แต่การอัปเดตตัวจัดวางองค์ประกอบไม่มีภาพเคลื่อนไหวที่ส่งผลต่อความลื่นไหล |
เฟรมที่ลดลง | ไม่มีการอัปเดต ไม่มีการอัปเดตตัวจัดวางองค์ประกอบที่ต้องการ และอุปกรณ์หลักล่าช้า |
เฟรมที่ลดลง | ต้องการอัปเดตคอมโพสิเตอร์ แต่เกิดความล่าช้า |
เฟรมไม่มีอัปเดต | ต้องอัปเดตก่อนเนื่องจากตัวแสดงผลสร้างขึ้น แต่ GPU ยังไม่แสดงการอัปเดตก่อนกำหนดเวลาของ vsync |
และคุณสามารถเปลี่ยนรัฐเหล่านี้ให้เป็นคะแนนได้ วิธีหนึ่งที่จะช่วยตีความคะแนนนี้ได้คือ การพิจารณาว่าผู้ใช้เป็นความน่าจะเป็นในการสังเกตได้ เฟรมที่ตกทีละเฟรมอาจไม่สามารถสังเกตได้มากนัก แต่การแสดงเฟรมที่ตกหล่นจำนวนมากมีผลต่อความลื่นไหลในแถวแน่นอน
รวมข้อมูลทั้งหมด: เมตริกเปอร์เซ็นต์ของเฟรมที่ลดน้อยลง
แม้ว่าบางครั้งอาจจำเป็นต้องเจาะลึกสถานะของเฟรมภาพเคลื่อนไหวแต่ละเฟรม แต่การกำหนดคะแนน "ข้อมูลโดยย่อ" แบบคร่าวๆ ก็มีประโยชน์เช่นกัน
เนื่องจากเฟรมอาจมีการนำเสนอเพียงบางส่วน และเพราะแม้แต่การอัปเดตเฟรมที่ข้ามทั้งหมดก็อาจไม่ได้ส่งผลต่อความราบรื่น เราอยากจะเน้นการนับเฟรมน้อยลง และหันไปสนใจขอบเขตที่เบราว์เซอร์ไม่สามารถให้การอัปเดตสมบูรณ์ด้วยภาพได้อย่างครบถ้วน
โมเดลทางความคิดควรเริ่มจาก
- เฟรมต่อวินาที เป็น
- การตรวจหาอัปเดตภาพเคลื่อนไหวที่สำคัญและหายไป เพื่อ
- เปอร์เซ็นต์ที่ลดลงในระยะเวลาที่กำหนด
สิ่งที่สำคัญก็คือ สัดส่วนของเวลาที่รอการอัปเดตที่สำคัญ เราคิดว่าวิธีนี้ตรงกับวิธีทั่วไปที่ผู้ใช้จะได้สัมผัส ความลื่นไหลของเนื้อหาเว็บ ที่ผ่านมา เราได้ใช้เมตริกต่อไปนี้เป็นชุดเมตริกเริ่มต้น
- เปอร์เซ็นต์ที่ลดลงโดยเฉลี่ย: สำหรับเฟรมภาพเคลื่อนไหวที่ไม่ได้ใช้งานทั้งหมดตลอดไทม์ไลน์
- กรณีที่แย่ที่สุดสำหรับเปอร์เซ็นต์เฟรมที่หลุด: ที่วัดได้ในกรอบเวลาการเลื่อน 1 วินาที
- เปอร์เซ็นไทล์ที่ 95 ของเปอร์เซ็นต์ที่เฟรมลดลง: เมื่อวัดในกรอบเวลาเลื่อน 1 วินาที
คุณดูคะแนนเหล่านี้ได้ในเครื่องมือสําหรับนักพัฒนาซอฟต์แวร์ Chrome บางรายการในปัจจุบัน แม้ว่าเมตริกเหล่านี้จะมุ่งเน้นที่อัตราการส่งข้อมูลของเฟรมโดยรวมเท่านั้น แต่เราก็กำลังประเมินปัจจัยอื่นๆ ด้วย เช่น เวลาในการตอบสนองของเฟรม
ลองใช้งานในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์เลย!
HUD ประสิทธิภาพ
Chromium มี HUD ประสิทธิภาพที่เป็นระเบียบซ่อนอยู่ด้านหลังธง
(chrome://flags/#show-performance-metrics-hud
) ในนั้นคุณจะเห็นคะแนนสดสำหรับสิ่งต่างๆ เช่น Core Web Vitals รวมถึงคำจำกัดความทดลองอีก 2-3 รายการเพื่อความลื่นไหลของภาพเคลื่อนไหวโดยอิงตามเปอร์เซ็นต์เฟรมที่ลดลงเมื่อเวลาผ่านไป
สถิติการแสดงผลเฟรม
เปิดใช้ "สถิติการแสดงผลเฟรม" ในเครื่องมือสำหรับนักพัฒนาเว็บผ่านการตั้งค่าการแสดงผลเพื่อดูมุมมองสดของเฟรมภาพเคลื่อนไหวใหม่ ซึ่งมีโค้ดสีเพื่อแยกการอัปเดตบางส่วนออกจากการอัปเดตเฟรมที่วางโดยสมบูรณ์ FPS ที่รายงานมีไว้สำหรับเฟรมที่มีการนำเสนออย่างสมบูรณ์เท่านั้น
โปรแกรมดูเฟรมในการบันทึกโปรไฟล์ประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บ
แผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บมีโปรแกรมดูเฟรมมาอย่างยาวนาน อย่างไรก็ตาม เวอร์ชันไม่สอดคล้องกับวิธีการทำงานของไปป์ไลน์การแสดงผลสมัยใหม่ ล่าสุดหลายๆ อย่างมีการปรับปรุงมากมาย แม้แต่ใน Chrome Canary เวอร์ชันล่าสุด ซึ่งเราคิดว่าน่าจะช่วยแก้ปัญหาเกี่ยวกับภาพเคลื่อนไหวได้ง่ายขึ้นมาก
วันนี้ คุณจะเห็นว่าเฟรมในโปรแกรมดูเฟรมสอดคล้องกับขอบเขต vsync มากขึ้น และมีการเขียนโค้ดสีตามสถานะ ความแตกต่างเล็กๆ น้อยๆ ทั้งหมดที่กล่าวมาข้างต้นจะยังไม่มีการแสดงผลแบบเต็มรูปแบบ แต่เรากำลังวางแผนที่จะเพิ่มภาพอื่นๆ อีกในเร็วๆ นี้
การติดตามด้วย Chrome
สุดท้าย เมื่อใช้ Chrome Tracing ซึ่งเป็นเครื่องมือตัวเลือกสำหรับการเจาะลึกรายละเอียด คุณสามารถบันทึกการติดตาม "การแสดงผลเนื้อหาเว็บ" ผ่าน UI ของ Perfetto (หรือ about:tracing
) ใหม่และเจาะลึกลงไปในไปป์ไลน์กราฟิกของ Chrome อาจเป็นงานที่น่าหวาดหวั่น แต่จะมีบางอย่าง
ที่เพิ่มลงใน Chromium เมื่อเร็วๆ นี้เพื่อให้ทำได้ง่ายขึ้น คุณดูภาพรวมของสิ่งที่พร้อมใช้งานได้ในเอกสารอายุการใช้งานของเฟรม
คุณจะระบุข้อมูลต่อไปนี้ได้อย่างละเอียดผ่านเหตุการณ์การติดตาม
- ภาพเคลื่อนไหวที่กำลังทำงาน (โดยใช้เหตุการณ์ชื่อ
TrackerValidation
) - การรับไทม์ไลน์ที่แน่นอนของเฟรมภาพเคลื่อนไหว (โดยใช้เหตุการณ์ที่ชื่อว่า
PipelineReporter
) - สำหรับการอัปเดตภาพเคลื่อนไหวที่ไม่สม่ำเสมอ ให้ค้นหาสิ่งที่บล็อกไม่ให้ภาพเคลื่อนไหวทำงานเร็วขึ้น (โดยใช้รายละเอียดของเหตุการณ์ภายใน
PipelineReporter
เหตุการณ์) - สำหรับภาพเคลื่อนไหวที่มาจากอินพุต โปรดดูระยะเวลาที่ใช้ในการรับการอัปเดตภาพ (โดยใช้เหตุการณ์ชื่อ
EventLatency
)
ขั้นตอนถัดไป
โครงการริเริ่ม Web Vitals มีเป้าหมายเพื่อให้บริการเมตริกและคำแนะนำในการสร้างประสบการณ์ที่ยอดเยี่ยมของผู้ใช้บนเว็บ เมตริกที่ใช้ Lab เช่น เวลาการบล็อกทั้งหมด (TBT) มีความสำคัญต่อการจับและวินิจฉัยปัญหาการโต้ตอบที่อาจเกิดขึ้น เรากำลังวางแผนจะออกแบบเมตริกที่ใช้กันในห้องทดลองที่คล้ายคลึงกันเพื่อให้ภาพเคลื่อนไหวราบรื่น
เราจะคอยแจ้งให้ทราบในขณะที่เราเดินหน้าต่อในการออกแบบเมตริกที่ครอบคลุมตามข้อมูลเฟรมของภาพเคลื่อนไหวแต่ละรายการ
ในอนาคต เรายังต้องการออกแบบ API ที่จะช่วยวัดความลื่นไหลของภาพเคลื่อนไหวได้อย่างมีประสิทธิภาพสำหรับผู้ใช้จริงในภาคสนามและในห้องทดลอง ติดตามข้อมูลอัปเดตจากที่นั่นเช่นกัน
ความคิดเห็น
เราตื่นเต้นกับการปรับปรุงล่าสุดและเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ทั้งหมดที่เราจัดส่งใน Chrome เพื่อวัดความราบรื่นของภาพเคลื่อนไหว โปรดลองใช้เครื่องมือเหล่านี้ เปรียบเทียบภาพเคลื่อนไหว และแจ้งให้เราทราบว่าแอปจะนำไปที่ใด
คุณสามารถส่งความคิดเห็นไปยัง Google Group web-vitals-feedback ที่มี "[Smoothness Metrics]" ในบรรทัดเรื่อง เราหวังเป็นอย่างยิ่งว่าจะได้รับ ความคิดเห็นจากคุณ