ดูข้อมูลเกี่ยวกับการวัดภาพเคลื่อนไหว วิธีพิจารณาเฟรมภาพเคลื่อนไหว และความลื่นไหลโดยรวมของหน้าเว็บ
คุณอาจเคยพบหน้าเว็บที่ "กระตุก" หรือ "ค้าง" ขณะเลื่อนหรือแสดงภาพเคลื่อนไหว เราขออธิบายว่าประสบการณ์การใช้งานเหล่านี้ไม่ราบรื่น ทีม Chrome กำลังดำเนินการเพิ่มการรองรับเครื่องมือในแล็บสำหรับการตรวจจับภาพเคลื่อนไหว รวมถึงปรับปรุงการวินิจฉัยไปป์ไลน์การแสดงผลใน Chromium อย่างต่อเนื่องเพื่อแก้ไขปัญหาประเภทนี้
เราต้องการแชร์ความคืบหน้าล่าสุด มอบคําแนะนําที่ชัดเจนเกี่ยวกับเครื่องมือ และพูดคุยเกี่ยวกับแนวคิดสําหรับเมตริกความลื่นไหลของภาพเคลื่อนไหวในอนาคต และเช่นเคย เรายินดีรับฟังความคิดเห็นจากคุณ
โพสต์นี้จะครอบคลุมหัวข้อหลัก 3 หัวข้อ ได้แก่
- ภาพรวมของภาพเคลื่อนไหวและเฟรมภาพเคลื่อนไหว
- มุมมองปัจจุบันของเราเกี่ยวกับการวัดความลื่นไหลของภาพเคลื่อนไหวโดยรวม
- คำแนะนำที่เป็นประโยชน์ 2-3 ข้อสำหรับใช้ประโยชน์จากเครื่องมือใน Lab ในปัจจุบัน
ภาพเคลื่อนไหวคืออะไร
ภาพเคลื่อนไหวทำให้เนื้อหามีชีวิตชีวา การทำให้เนื้อหาเคลื่อนไหว โดยเฉพาะการตอบสนองต่อการโต้ตอบของผู้ใช้ จะทำให้ประสบการณ์การใช้งานดูเป็นธรรมชาติ เข้าใจง่าย และสนุกยิ่งขึ้น
แต่ภาพเคลื่อนไหวที่ใช้งานไม่ดีหรือการเพิ่มภาพเคลื่อนไหวมากเกินไปอาจทำให้ประสบการณ์การใช้งานแย่ลงและไม่สนุกเลย เราทุกคนคงเคยโต้ตอบกับอินเทอร์เฟซที่เพิ่มเอฟเฟกต์การเปลี่ยนภาพ "ที่มีประโยชน์" มากเกินไป ซึ่งทำให้ประสบการณ์การใช้งานแย่ลงเมื่อทำงานได้ไม่ดี ดังนั้นผู้ใช้บางรายจึงอาจต้องการลดการเคลื่อนไหว ซึ่งเป็นค่ากำหนดของผู้ใช้ที่คุณควรปฏิบัติตาม
ภาพเคลื่อนไหวทำงานอย่างไร
สรุปสั้นๆ ก็คือไปป์ไลน์การแสดงผลประกอบด้วยขั้นตอนตามลำดับ 2-3 ขั้นตอนดังนี้
- สไตล์: คํานวณสไตล์ที่ใช้กับองค์ประกอบ
- เลย์เอาต์: สร้างเรขาคณิตและตำแหน่งสำหรับองค์ประกอบแต่ละรายการ
- ระบายสี: กรอกพิกเซลขององค์ประกอบแต่ละรายการลงในเลเยอร์
- คอมโพสิต: วาดเลเยอร์ลงในหน้าจอ
แม้ว่าจะมีวิธีกำหนดภาพเคลื่อนไหวหลายวิธี แต่ภาพเคลื่อนไหวทั้งหมดจะทำงานผ่านวิธีใดวิธีหนึ่งต่อไปนี้
- การปรับเลย์เอาต์ พร็อพเพอร์ตี้
- การปรับคุณสมบัติสี
- การปรับพร็อพเพอร์ตี้คอมโพสิต
เนื่องจากขั้นตอนเหล่านี้เป็นขั้นตอนต่อเนื่องกัน คุณจึงควรกำหนดภาพเคลื่อนไหวในแง่ของพร็อพเพอร์ตี้ที่อยู่ต่อๆ ไปในไปป์ไลน์ ยิ่งอัปเดตเร็วมากเท่าใด ค่าใช้จ่ายก็จะยิ่งสูงขึ้นและกระบวนการก็ยิ่งมีแนวโน้มที่จะไม่ราบรื่น (ดูรายละเอียดเพิ่มเติมได้ที่ประสิทธิภาพการแสดงผล)
แม้ว่าการแสดงผลพร็อพเพอร์ตี้เลย์เอาต์แบบเคลื่อนไหวจะสะดวก แต่ก็มีค่าใช้จ่ายตามมา แม้ว่าค่าใช้จ่ายเหล่านั้นจะไม่ปรากฏให้เห็นในทันที คุณควรกำหนดภาพเคลื่อนไหวในแง่ของการเปลี่ยนแปลงพร็อพเพอร์ตี้คอมโพสิตทุกครั้งที่เป็นไปได้
การกําหนดภาพเคลื่อนไหว CSS แบบประกาศหรือการใช้ภาพเคลื่อนไหวบนเว็บ และการทำให้คุณสมบัติคอมโพสิตเคลื่อนไหวเป็นขั้นตอนแรกที่ดีในการทำให้ภาพเคลื่อนไหวราบรื่นและมีประสิทธิภาพ แต่อย่างไรก็ตาม การทำเช่นนี้เพียงอย่างเดียวไม่ได้รับประกันความลื่นไหล เนื่องจากภาพเคลื่อนไหวบนเว็บที่มีประสิทธิภาพก็ยังมีขีดจำกัดด้านประสิทธิภาพ ด้วยเหตุนี้ การวัดผลจึงมีความสําคัญเสมอ
เฟรมภาพเคลื่อนไหวคืออะไร
การอัปเดตการแสดงภาพหน้าเว็บอาจใช้เวลาสักครู่จึงจะปรากฏ การเปลี่ยนแปลงภาพจะทําให้เกิดเฟรมภาพเคลื่อนไหวใหม่ ซึ่งจะแสดงผลบนจอแสดงผลของผู้ใช้ในที่สุด
แสดงการอัปเดตเป็นระยะๆ เพื่อให้การอัปเดตภาพเป็นกลุ่ม จอแสดงผลจำนวนมากจะอัปเดตเป็นช่วงเวลาที่ตายตัว เช่น 60 ครั้งต่อวินาที (นั่นคือ 60 Hz) จอแสดงผลที่ทันสมัยกว่าบางรุ่นอาจเสนออัตราการรีเฟรชที่สูงขึ้น (90–120 Hz กำลังได้รับความนิยม) บ่อยครั้งที่จอแสดงผลเหล่านี้สามารถปรับอัตราการรีเฟรชตามต้องการ หรือแม้แต่เสนออัตราเฟรมที่ปรับได้อย่างเต็มที่
เป้าหมายของแอปพลิเคชันต่างๆ เช่น เกมหรือเบราว์เซอร์ คือการประมวลผลการอัปเดตภาพแบบเป็นกลุ่มทั้งหมดเหล่านี้และสร้างเฟรมภาพเคลื่อนไหวที่สมบูรณ์ภายในกำหนดเวลาทุกครั้ง โปรดทราบว่าเป้าหมายนี้แตกต่างจากงานสำคัญอื่นๆ ของเบราว์เซอร์อย่างสิ้นเชิง เช่น การโหลดเนื้อหาจากเครือข่ายอย่างรวดเร็ว หรือการดำเนินการ JavaScript อย่างมีประสิทธิภาพ
ในบางครั้ง การอัปเดตภาพทั้งหมดให้เสร็จสมบูรณ์ภายในกำหนดเวลาที่จอแสดงผลกำหนดอาจเป็นเรื่องยากเกินไป เมื่อเกิดกรณีนี้ขึ้น เบราว์เซอร์จะทิ้งเฟรม หน้าจอไม่ดับ แต่จะแสดงภาพซ้ำๆ คุณจะเห็นการอัปเดตภาพเดิมนานขึ้นอีกนิด ซึ่งเป็นเฟรมภาพเคลื่อนไหวเดียวกันกับที่แสดงในโอกาสเฟรมก่อนหน้า
ปัญหานี้เกิดขึ้นบ่อยมาก ไม่จำเป็นต้องสังเกตเห็นเลย โดยเฉพาะสำหรับเนื้อหาแบบคงที่หรือเนื้อหาที่คล้ายเอกสาร ซึ่งพบได้ทั่วไปในแพลตฟอร์มเว็บ เฟรมที่หายไปจะปรากฏขึ้นก็ต่อเมื่อมีอัปเดตภาพที่สำคัญ เช่น ภาพเคลื่อนไหว ซึ่งเราจำเป็นต้องมีการอัปเดตภาพเคลื่อนไหวอย่างต่อเนื่องเพื่อแสดงการเคลื่อนไหวที่ราบรื่น
อะไรส่งผลต่อเฟรมภาพเคลื่อนไหว
นักพัฒนาเว็บสามารถส่งผลอย่างมากต่อความสามารถของเบราว์เซอร์ในการแสดงผลและนำเสนอการอัปเดตภาพอย่างรวดเร็วและมีประสิทธิภาพ
ตัวอย่างมีดังต่อไปนี้
- การใช้เนื้อหาที่มีขนาดใหญ่เกินไปหรือใช้ทรัพยากรมากจนถอดรหัสได้ช้าในอุปกรณ์เป้าหมาย
- การใช้เลเยอร์มากเกินไปซึ่งต้องใช้หน่วยความจำ GPU มากเกินไป
- การกําหนดรูปแบบ CSS หรือภาพเคลื่อนไหวบนเว็บที่ซับซ้อนเกินไป
- การใช้การออกแบบที่ไม่เหมาะสมซึ่งปิดใช้การเพิ่มประสิทธิภาพการแสดงผลอย่างรวดเร็ว
- JS ทํางานในเทรดหลักมากเกินไป ทําให้งานใช้เวลานานซึ่งบล็อกการอัปเดตภาพ
แต่คุณจะรู้ได้อย่างไรเมื่อเฟรมภาพเคลื่อนไหวแสดงไม่ทันกำหนดเวลาและทำให้เกิดเฟรมที่หายไป
วิธีหนึ่งที่เป็นไปได้คือการใช้การโหวต requestAnimationFrame() แต่ก็มีข้อเสียหลายประการ requestAnimationFrame() หรือ "rAF" จะบอกให้เบราว์เซอร์ทราบว่าคุณต้องการแสดงภาพเคลื่อนไหวและขอโอกาสดำเนินการดังกล่าวก่อนขั้นตอนการแสดงผลถัดไปของไปป์ไลน์การแสดงผล หากระบบไม่ได้เรียกใช้ฟังก์ชันการเรียกกลับในเวลาที่คุณคาดไว้ แสดงว่าระบบไม่ได้ดำเนินการวาดภาพและข้ามเฟรมอย่างน้อย 1 เฟรม คุณสามารถคำนวณเมตริก "เฟรมต่อวินาที" (FPS) ประเภทหนึ่งได้ด้วยการสำรวจและนับความถี่ที่เรียกใช้ rAF
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()กำหนดเวลาบล็อกที่ไม่ได้ใช้งานเป็นเวลานานได้เมื่อใช้งานอย่างต่อเนื่อง (บล็อกที่มีความยาวเกินกว่า 1 เฟรม) - ในทํานองเดียวกัน การไม่มีบล็อกที่ไม่ได้ใช้งานเป็นเวลานานจะทําให้เบราว์เซอร์ไม่สามารถกําหนดเวลางานอื่นๆ ที่ทํางานต่อเนื่อง (เช่น การเก็บขยะนานขึ้นและงานอื่นๆ ในเบื้องหลังหรืองานคาดการณ์)
- หากเปิดและปิดการโหวต คุณอาจพลาดกรณีที่เกินงบประมาณเฟรม
- การสำรวจจะรายงานผลบวกลวงในกรณีที่เบราว์เซอร์ใช้ความถี่การอัปเดตแบบผันแปร (เช่น เนื่องจากสถานะพลังงานหรือระดับการมองเห็น)
- และที่สำคัญที่สุดคือไม่ได้บันทึกการอัปเดตภาพเคลื่อนไหวทุกประเภท
การทำงานมากเกินไปในเธรดหลักอาจส่งผลต่อความสามารถในการดูเฟรมภาพเคลื่อนไหว ดูตัวอย่างการกระตุกเพื่อดูว่าภาพเคลื่อนไหวที่ขับเคลื่อนโดย RAF จะทําให้เฟรมตกและมีการเรียกกลับ rAF น้อยลง รวมถึง FPS ลดลงอย่างไรเมื่อมีงานมากเกินไปในเธรดหลัก (เช่น เลย์เอาต์)
เมื่อเธรดหลักทำงานช้า การอัปเดตภาพจะเริ่มกระตุก เยี่ยมไปเลย
เครื่องมือวัดผลจํานวนมากมุ่งเน้นที่ความสามารถของชุดข้อความหลักในการให้ผลลัพธ์อย่างทันท่วงที และเพื่อให้เฟรมภาพเคลื่อนไหวทำงานได้อย่างราบรื่น แต่นี่ไม่ใช่ทั้งหมด ลองพิจารณาตัวอย่างต่อไปนี้
วิดีโอด้านบนแสดงหน้าที่แทรกงานที่มีระยะเวลานานลงในเธรดหลักเป็นระยะๆ งานระยะยาวเหล่านี้ทำให้หน้าเว็บไม่สามารถแสดงการอัปเดตภาพบางประเภทได้ และคุณจะเห็นการลดลงของ requestAnimationFrame() FPS ที่รายงานเป็น 0 ที่มุมซ้ายบน
แต่หน้าเว็บยังคงเลื่อนได้อย่างราบรื่นแม้จะมีงานเหล่านี้อยู่ เนื่องจากในเบราว์เซอร์สมัยใหม่ การเลื่อนมักจะเป็นแบบเธรด ซึ่งขับเคลื่อนโดยคอมโพสิตอร์ทั้งหมด
นี่เป็นตัวอย่างที่มีเฟรมที่หลุดไปหลายเฟรมในเธรดหลักพร้อมกัน แต่ยังคงมีเฟรมการเลื่อนที่ส่งได้สําเร็จหลายเฟรมในเธรดคอมโพสิต เมื่องานระยะยาวเสร็จสมบูรณ์แล้ว การอัปเดตการวาดภาพในเธรดหลักจะไม่มีการเปลี่ยนแปลงที่มองเห็นได้ การสำรวจ rAF แนะนำให้เฟรมลดลงเป็น 0 แต่ภาพผู้ใช้จะไม่เห็นความแตกต่าง
สำหรับเฟรมภาพเคลื่อนไหว เรื่องราวจะซับซ้อนกว่า
เฟรมภาพเคลื่อนไหว: ข้อมูลอัปเดตที่สำคัญ
ตัวอย่างข้างต้นแสดงให้เห็นว่าเรื่องราวมีมากกว่าแค่ requestAnimationFrame()
ดังนั้น การอัปเดตภาพเคลื่อนไหวและเฟรมภาพเคลื่อนไหวจะสำคัญเมื่อใด เกณฑ์ที่เรากำลังพิจารณาและอยากทราบความคิดเห็นมีดังนี้
- การอัปเดตชุดข้อความหลักและคอมโพสเซอร์
- ไม่มีการอัปเดตสี
- การตรวจหาภาพเคลื่อนไหว
- คุณภาพกับปริมาณ
การอัปเดตชุดข้อความหลักและคอมโพสเซอร์
การอัปเดตเฟรมภาพเคลื่อนไหวไม่ใช่บูลีน เฟรมไม่ได้แสดงเฉพาะแบบเต็มหรือแบบสมบูรณ์เท่านั้น มีหลายสาเหตุที่เฟรมภาพเคลื่อนไหวอาจแสดง เพียงบางส่วน กล่าวคือ อาจมีเนื้อหาที่ล้าสมัยอยู่ด้วยขณะที่มีการอัปเดตภาพใหม่ที่แสดงอยู่
ตัวอย่างที่พบบ่อยที่สุดของกรณีนี้คือเมื่อเบราว์เซอร์สร้างการอัปเดตใหม่ในเธรดหลักภายในกำหนดเวลาเฟรมไม่ได้ แต่มีการอัปเดตเธรดคอมโพสิเตอร์ใหม่ (เช่น ตัวอย่างการเลื่อนแบบใช้เธรดก่อนหน้านี้)
เหตุผลสําคัญประการหนึ่งที่แนะนําให้ใช้ภาพเคลื่อนไหวแบบประกาศเพื่อแสดงภาพเคลื่อนไหวของพร็อพเพอร์ตี้คอมโพสิทคือ การทำเช่นนี้จะช่วยให้ภาพเคลื่อนไหวทํางานโดยสมบูรณ์จากเธรดคอมโพสิทแม้ว่าเธรดหลักจะทํางานอยู่ก็ตาม ภาพเคลื่อนไหวประเภทเหล่านี้จะสร้างการอัปเดตภาพต่อไปได้อย่างมีประสิทธิภาพและควบคู่กันไป
ในทางกลับกัน ก็อาจมีกรณีที่การอัปเดตชุดข้อความหลักพร้อมใช้งานสำหรับการนำเสนอแล้วในท้ายที่สุด แต่หลังจากที่พลาดกำหนดเวลาของเฟรมหลายรายการ เบราว์เซอร์จะมีอัปเดตใหม่บางส่วน แต่อาจไม่ใช่เวอร์ชันล่าสุด
พูดอย่างกว้างๆ ก็คือ เราจะถือว่าเฟรมที่มีภาพอัปเดตใหม่บางส่วนแต่ไม่ใช่ทั้งหมดเป็นเฟรมบางส่วน เฟรมบางส่วนค่อนข้างพบได้ทั่วไป โดยหลักการแล้ว การอัปเดตบางส่วนควรมีการอัปเดตภาพที่สำคัญที่สุดอย่างน้อย เช่น ภาพเคลื่อนไหว แต่จะเกิดขึ้นได้ก็ต่อเมื่อภาพเคลื่อนไหวนั้นขับเคลื่อนโดยเธรดคอมโพสิตเท่านั้น
ไม่มีการอัปเดตสี
การอัปเดตบางส่วนอีกประเภทหนึ่งคือเมื่อสื่ออย่างรูปภาพยังไม่ถอดรหัสและแรสเตอร์เสร็จทันเวลาสำหรับการแสดงเฟรม
หรือแม้ว่าหน้าเว็บจะไม่มีการอัปเดตใดๆ เลย แต่เบราว์เซอร์อาจยังแสดงผลช้ากว่าการอัปเดตภาพขณะเลื่อนอย่างรวดเร็ว นั่นเป็นเพราะระบบอาจทิ้งการแสดงผลพิกเซลของเนื้อหาที่อยู่นอกวิวพอร์ตที่มองเห็นได้เพื่อประหยัดหน่วยความจำ GPU การแสดงผลพิกเซลต้องใช้เวลา และอาจใช้เวลานานกว่า 1 เฟรมในการแสดงผลทุกอย่างหลังจากการเลื่อนหน้าจอครั้งใหญ่ เช่น การปัดนิ้ว โดยทั่วไปเราเรียกกรณีนี้ว่าการจัดเรียงแบบตาราง
โอกาสในการเรนเดอร์เฟรมแต่ละเฟรมช่วยให้คุณติดตามได้ว่าการอัปเดตภาพล่าสุดปรากฏบนหน้าจอมากน้อยเพียงใด การวัดความสามารถในการดำเนินการดังกล่าวในหลายๆ เฟรม (หรือช่วงเวลา) เรียกกันโดยทั่วไปว่าอัตราเฟรม
หาก GPU ทำงานช้ามาก เบราว์เซอร์ (หรือแพลตฟอร์ม) อาจเริ่มควบคุมอัตราการพยายามอัปเดตภาพ ซึ่งจะส่งผลให้อัตราเฟรมที่มีประสิทธิภาพลดลง แม้ว่าในทางเทคนิคแล้ววิธีนี้อาจลดจำนวนการอัปเดตเฟรมที่หลุดไป แต่ภาพรวมจะยังคงปรากฏเป็นอัตราเฟรมที่ต่ำลง
อย่างไรก็ตาม อัตราเฟรมต่ำบางประเภทก็ไม่ได้แย่เสมอไป หากหน้าเว็บไม่มีการใช้งานส่วนใหญ่และไม่มีภาพเคลื่อนไหวที่ทำงานอยู่ อัตราเฟรมต่ำก็ดูน่าดึงดูดเท่ากับอัตราเฟรมสูง (และยังช่วยประหยัดแบตเตอรี่ได้ด้วย)
อัตราเฟรมจึงสำคัญในกรณีใด
การตรวจหาภาพเคลื่อนไหว
อัตราเฟรมที่สูงมีความสำคัญอย่างยิ่งในช่วงที่มีภาพเคลื่อนไหวที่สำคัญ ภาพเคลื่อนไหวประเภทต่างๆ จะขึ้นอยู่กับการอัปเดตภาพจากเธรดหนึ่งๆ (หลัก ผู้จัดเรียง หรือผู้ทำงาน) ดังนั้นการอัปเดตภาพจึงขึ้นอยู่กับว่าเธรดนั้นอัปเดตภายในกำหนดเวลาหรือไม่ เราจะบอกว่าชุดข้อความหนึ่งๆ ส่งผลต่อความลื่นไหลเมื่อใดก็ตามที่มีภาพเคลื่อนไหวที่ทำงานอยู่ซึ่งขึ้นอยู่กับการอัปเดตชุดข้อความนั้น
ภาพเคลื่อนไหวบางประเภทจะกำหนดและตรวจจับได้ง่ายกว่าประเภทอื่นๆ ภาพเคลื่อนไหวแบบประกาศหรือภาพเคลื่อนไหวที่ทำงานตามอินพุตของผู้ใช้จะกำหนดได้ง่ายกว่าภาพเคลื่อนไหวที่ทำงานด้วย JavaScript ซึ่งติดตั้งใช้งานเป็นอัปเดตเป็นระยะสำหรับพร็อพเพอร์ตี้สไตล์ที่เคลื่อนไหวได้
แม้จะใช้ requestAnimationFrame() ก็ตาม คุณก็ไม่สามารถสรุปได้ว่าการเรียก rAF ทุกครั้งจะสร้างการอัปเดตภาพหรือภาพเคลื่อนไหวเสมอไป ตัวอย่างเช่น การใช้การสำรวจ rAF เพื่อติดตามอัตราเฟรม (ดังที่แสดงด้านบน) ไม่ควรส่งผลต่อการวัดความลื่นไหล เนื่องจากไม่มีการอัปเดตภาพ
คุณภาพกับปริมาณ
สุดท้ายนี้ การตรวจหาภาพเคลื่อนไหวและการอัปเดตเฟรมภาพเคลื่อนไหวเป็นเพียงส่วนหนึ่งของเรื่องราวเท่านั้น เนื่องจากจะจับเฉพาะจำนวนการอัปเดตภาพเคลื่อนไหว ไม่ใช่คุณภาพ
เช่น คุณอาจเห็นอัตราเฟรมที่ราบรื่น 60 เฟรมต่อวินาทีขณะดูวิดีโอ ในทางเทคนิคแล้ว วิดีโอนี้เล่นได้อย่างราบรื่น แต่วิดีโอเองอาจมีอัตราบิตต่ำหรือมีปัญหาเกี่ยวกับการบัฟเฟอร์ของเครือข่าย เมตริกความลื่นไหลของภาพเคลื่อนไหวไม่ได้จับภาพลักษณะนี้โดยตรง แต่อาจยังทำให้ผู้ใช้รู้สึกไม่สบายใจ
หรือเกมที่ใช้ประโยชน์จาก <canvas> (อาจใช้เทคนิคอย่างแคนวาสนอกหน้าจอเพื่อให้เฟรมเรตคงที่) ในทางเทคนิคอาจราบรื่นอย่างสมบูรณ์ในแง่ของเฟรมภาพเคลื่อนไหว แต่โหลดชิ้นงานเกมคุณภาพสูงไปยังฉากไม่ได้หรือแสดงข้อบกพร่องในการเรนเดอร์
และแน่นอนว่าเว็บไซต์อาจมีภาพเคลื่อนไหวที่ไม่ดีเอามากๆ 🙂
เราคิดว่ามันเจ๋งมากสำหรับยุคนั้น
สถานะของเฟรมภาพเคลื่อนไหวเดียว
เนื่องจากเฟรมอาจแสดงเพียงบางส่วน หรือเฟรมที่หลุดอาจเกิดขึ้นในลักษณะที่ไม่ส่งผลต่อความลื่นไหล เราจึงเริ่มคิดว่าแต่ละเฟรมมีคะแนนความสมบูรณ์หรือความลื่นไหล
ต่อไปนี้คือวิธีการต่างๆ ที่เราใช้ตีความสถานะของเฟรมภาพเคลื่อนไหวเฟรมเดียว โดยจัดเรียงจากกรณีที่ดีที่สุดไปจนถึงกรณีที่แย่ที่สุด
| ไม่ต้องการอัปเดต | เวลาที่ไม่ได้ใช้งาน เฟรมก่อนหน้าซ้ำ |
| นำเสนออย่างเต็มรูปแบบ | การอัปเดตชุดข้อความหลักได้รับการดำเนินการภายในกำหนดเวลา หรือไม่จำเป็นต้องอัปเดตชุดข้อความหลัก |
| นำเสนอบางส่วน | คอมโพสิเตอร์เท่านั้น การอัปเดตเธรดหลักที่ล่าช้าไม่มีการเปลี่ยนแปลงที่มองเห็นได้ |
| นำเสนอบางส่วน | คอมโพสิเตอร์เท่านั้น เทรดหลักมีการอัปเดตภาพ แต่การอัปเดตนั้นไม่มีภาพเคลื่อนไหวที่ส่งผลต่อความลื่นไหล |
| นำเสนอบางส่วน | คอมโพสิตเท่านั้น เทรดหลักมีการอัปเดตภาพซึ่งส่งผลต่อความราบรื่น แต่มีเฟรมที่ล้าสมัยก่อนหน้านี้เข้ามาและระบบใช้แทน |
| นำเสนอบางส่วน | คอมโพสิเตอร์เท่านั้น ไม่มีการอัปเดตหลักที่ต้องการ และการอัปเดตคอมโพสิเตอร์มีภาพเคลื่อนไหวที่ส่งผลต่อความลื่นไหล |
| นำเสนอบางส่วน | คอมโพสิเตอร์เท่านั้น แต่การอัปเดตคอมโพสิเตอร์ไม่มีภาพเคลื่อนไหวที่ส่งผลต่อความลื่นไหล |
| เฟรมที่ลดน้อยลง | ไม่มีข้อมูลอัปเดต ไม่ต้องการอัปเดตคอมโพสิเตอร์ และระบบหน่วงเวลาส่วนหลัก |
| เฟรมที่ลดน้อยลง | ต้องการอัปเดตเครื่องมือทำภาพคอมโพสิต แต่เกิดความล่าช้า |
| เฟรมค้าง | ต้องการการอัปเดต โปรแกรมแสดงผลสร้างการอัปเดตแล้ว แต่ GPU ยังคงไม่แสดงการอัปเดตดังกล่าวก่อนกำหนดเวลา vsync |
คุณอาจเปลี่ยนสถานะเหล่านี้ให้เป็นคะแนนได้ และวิธีหนึ่งในการตีความคะแนนนี้อาจเป็นการพิจารณาความน่าจะเป็นที่ผู้ใช้จะเห็น เฟรมที่หลุดไปเพียงเฟรมเดียวอาจสังเกตได้ยาก แต่หากมีเฟรมที่หลุดไปหลายเฟรมติดต่อกันก็จะส่งผลต่อความลื่นไหล
การรวมข้อมูลทั้งหมดเข้าด้วยกัน: เมตริกเปอร์เซ็นต์เฟรมที่หลุด
แม้ว่าบางครั้งอาจจําเป็นต้องเจาะลึกสถานะของเฟรมภาพเคลื่อนไหวแต่ละเฟรม แต่การกำหนดคะแนน "โดยย่อ" อย่างรวดเร็วสําหรับประสบการณ์การใช้งานก็มีประโยชน์เช่นกัน
เนื่องจากเฟรมอาจแสดงเพียงบางส่วน และแม้การข้ามการอัปเดตเฟรมทั้งหมดอาจไม่ได้ส่งผลต่อความลื่นไหลจริงๆ เราจึงต้องการมุ่งเน้นที่ขอบเขตที่เบราว์เซอร์ไม่สามารถแสดงการอัปเดตที่สมบูรณ์แบบจากมุมมองภาพเมื่อจำเป็นมากกว่าการนับเฟรมเพียงอย่างเดียว
รูปแบบความคิดควรเปลี่ยนจาก
- เฟรมต่อวินาที
- ตรวจหาการอัปเดตภาพเคลื่อนไหวที่สำคัญซึ่งขาดหายไป เพื่อ
- เปอร์เซ็นต์ที่ลดลงในช่วงระยะเวลาหนึ่งๆ
สิ่งที่สำคัญคือสัดส่วนเวลาในการรอการอัปเดตที่สำคัญ เราคิดว่าวิธีนี้สอดคล้องกับวิธีที่ผู้ใช้รับรู้ถึงความราบรื่นของเนื้อหาเว็บในการใช้งานจริง ที่ผ่านมาเราใช้เมตริกชุดแรกต่อไปนี้
- เปอร์เซ็นต์ที่ลดลงโดยเฉลี่ย: สำหรับเฟรมภาพเคลื่อนไหวทั้งหมดที่ไม่ใช่เฟรมที่ไม่ได้ทำงานตลอดทั้งไทม์ไลน์
- เปอร์เซ็นต์เฟรมที่หลุดออกที่เลวร้ายที่สุด: ตามที่วัดในกรอบเวลา 1 วินาที
- เปอร์เซ็นไทล์ที่ 95 ของเปอร์เซ็นต์เฟรมที่หลุด: วัดจากระยะเวลา 1 วินาทีโดยประมาณ
คุณดูคะแนนเหล่านี้ได้ในเครื่องมือสําหรับนักพัฒนาซอฟต์แวร์ของ Chrome บางรายการในปัจจุบัน แม้ว่าเมตริกเหล่านี้จะมุ่งเน้นที่อัตราเฟรมโดยรวมเท่านั้น แต่เราก็ประเมินปัจจัยอื่นๆ ด้วย เช่น เวลาในการตอบสนองของเฟรม
ลองใช้เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ได้เลย
HUD ประสิทธิภาพ
Chromium มี HUD ประสิทธิภาพที่เรียบร้อยซ่อนอยู่หลัง Flag (chrome://flags/#show-performance-metrics-hud) ซึ่งคุณจะเห็นคะแนนแบบเรียลไทม์สำหรับสิ่งต่างๆ เช่น Core Web Vitals รวมถึงคำจำกัดความการทดสอบบางอย่างสำหรับความลื่นไหลของภาพเคลื่อนไหวโดยอิงตามเปอร์เซ็นต์เฟรมที่หลุดเมื่อเวลาผ่านไป
สถิติการแสดงผลเฟรม
เปิดใช้ "สถิติการแสดงผลเฟรม" ในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ผ่านการตั้งค่าการแสดงผลเพื่อดูมุมมองแบบเรียลไทม์ของเฟรมภาพเคลื่อนไหวใหม่ ซึ่งมีการแยกแยะด้วยรหัสสีเพื่อแยกการอัปเดตบางส่วนจากการอัปเดตเฟรมที่ส่งผ่านอย่างสมบูรณ์ FPS ที่รายงานคือ FPS สำหรับเฟรมที่แสดงอย่างสมบูรณ์เท่านั้น
เครื่องมือดูเฟรมในการบันทึกโปรไฟล์ประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บ
แผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บมีเครื่องมือดูเฟรมมาอย่างยาวนาน อย่างไรก็ตาม เครื่องมือนี้เริ่มทำงานไม่สอดคล้องกับไปป์ไลน์การแสดงผลสมัยใหม่ มีการปรับปรุงมากมายเมื่อเร็วๆ นี้ แม้กระทั่งใน Chrome Canary เวอร์ชันล่าสุด ซึ่งเราคิดว่าจะช่วยให้แก้ไขข้อบกพร่องเกี่ยวกับภาพเคลื่อนไหวได้ง่ายขึ้นมาก
วันนี้คุณจะเห็นว่าเฟรมในเครื่องมือดูเฟรมจะสอดคล้องกับขอบเขต vsync มากขึ้น และมีรหัสสีตามสถานะ ขณะนี้เรายังไม่มีการแสดงภาพความแตกต่างทั้งหมดที่ระบุไว้ข้างต้น แต่เราวางแผนที่จะเพิ่มการแสดงภาพอื่นๆ ในอนาคตอันใกล้
การติดตามของ Chrome
สุดท้ายนี้ เครื่องมือสำหรับการเจาะลึกรายละเอียดอย่างการติดตามของ Chrome จะช่วยให้คุณบันทึกการติดตาม "การแสดงผลเนื้อหาเว็บ" ผ่าน Perfetto UI (หรือ about:tracing) เวอร์ชันใหม่ และเจาะลึกไปป์ไลน์กราฟิกของ Chrome ได้ งานนี้อาจดูน่าท้อแท้ แต่เรามีสิ่งใหม่ๆ เพิ่มลงใน Chromium เมื่อเร็วๆ นี้เพื่อช่วยให้คุณทำงานได้ง่ายขึ้น คุณดูภาพรวมของฟีเจอร์ที่มีได้ในเอกสารวงจรชีวิตของเฟรม
เหตุการณ์การติดตามช่วยให้คุณระบุสิ่งต่อไปนี้ได้อย่างแน่นอน
- ภาพเคลื่อนไหวที่ทำงานอยู่ (โดยใช้เหตุการณ์ชื่อ
TrackerValidation) - การดูไทม์ไลน์ที่แน่นอนของเฟรมภาพเคลื่อนไหว (โดยใช้เหตุการณ์ที่มีชื่อว่า
PipelineReporter) - สําหรับการอัปเดตภาพเคลื่อนไหวที่กระตุก ให้หาสาเหตุที่ทําให้ภาพเคลื่อนไหวทำงานช้าลง (โดยใช้รายละเอียดเหตุการณ์ภายในเหตุการณ์
PipelineReporter) - สําหรับภาพเคลื่อนไหวที่ขับเคลื่อนโดยอินพุต ให้ดูระยะเวลาที่ใช้ในการรับการอัปเดตภาพ (โดยใช้เหตุการณ์ชื่อ
EventLatency)
ขั้นตอนถัดไป
โครงการริเริ่ม Web Vitals มีเป้าหมายเพื่อมอบเมตริกและคำแนะนำในการสร้างประสบการณ์การใช้งานที่ยอดเยี่ยมบนเว็บ เมตริกที่มาจากห้องทดลอง เช่น เวลาในการบล็อกทั้งหมด (TBT) มีความสำคัญต่อการจับและวินิจฉัยปัญหาการโต้ตอบที่อาจเกิดขึ้น เราวางแผนที่จะออกแบบเมตริกที่คล้ายกันซึ่งอิงตามห้องทดลองสำหรับความลื่นไหลของภาพเคลื่อนไหว
เราจะแจ้งให้คุณทราบอย่างต่อเนื่องขณะที่เราพัฒนาแนวคิดการออกแบบเมตริกที่ครอบคลุมโดยอิงตามข้อมูลเฟรมภาพเคลื่อนไหวแต่ละเฟรม
ในอนาคต เรายังต้องการออกแบบ API ที่ช่วยให้วัดความลื่นไหลของภาพเคลื่อนไหวได้อย่างมีประสิทธิภาพสำหรับผู้ใช้จริงในภาคสนามและในห้องทดลองด้วย โปรดติดตามข้อมูลอัปเดตในช่องทางดังกล่าวด้วย
ความคิดเห็น
เรายินดีกับการปรับปรุงล่าสุดและเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ทั้งหมดที่มาพร้อมกับ Chrome เพื่อวัดความลื่นไหลของแอนิเมชัน โปรดลองใช้เครื่องมือเหล่านี้ เปรียบเทียบประสิทธิภาพของภาพเคลื่อนไหว แล้วแจ้งให้เราทราบผลลัพธ์
คุณสามารถส่งความคิดเห็นไปยังกลุ่ม web-vitals-feedback ของ Google โดยใส่ "[Smoothness Metrics]" ในบรรทัดเรื่อง เราหวังว่าจะได้รับความคิดเห็นจากคุณ