สู่เมตริกความลื่นไหลของภาพเคลื่อนไหว

เรียนรู้เกี่ยวกับการวัดภาพเคลื่อนไหว วิธีคิดเกี่ยวกับเฟรมของภาพเคลื่อนไหว และความราบรื่นของหน้าโดยรวม

คุณอาจเคยพบปัญหาหน้าที่ "กระตุก" หรือ "ค้าง" ระหว่างการเลื่อนหรือภาพเคลื่อนไหว เราชอบพูดได้ว่าประสบการณ์เหล่านี้ไม่ได้ราบรื่น เพื่อแก้ไขปัญหาประเภทนี้ ทีม Chrome ได้พยายามเพิ่มการรองรับเครื่องมือสำหรับห้องทดลองสำหรับการตรวจจับภาพเคลื่อนไหว ตลอดจนปรับปรุงการวินิจฉัยไปป์ไลน์การแสดงภาพภายใน Chromium อย่างต่อเนื่อง

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

โพสต์นี้จะครอบคลุมหัวข้อหลักๆ 3 หัวข้อ ได้แก่

• ภาพเคลื่อนไหวและเฟรมของภาพเคลื่อนไหวคร่าวๆ
• ปัจจุบันสิ่งที่เราคิดเกี่ยวกับการวัดความลื่นไหลของภาพเคลื่อนไหวโดยรวม
• คำแนะนำที่นำไปใช้ได้จริงบางส่วนสำหรับการใช้เครื่องมือในห้องทดลองในวันนี้

ภาพเคลื่อนไหวคืออะไร

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

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

ภาพเคลื่อนไหวทำงานอย่างไร

โดยสรุปแล้ว ไปป์ไลน์การแสดงผลประกอบด้วยขั้นตอนตามลำดับ 2-3 ขั้นตอน ดังนี้

1. รูปแบบ: คำนวณรูปแบบ ที่ใช้กับองค์ประกอบ
2. เลย์เอาต์: สร้างเรขาคณิตและตำแหน่ง สำหรับแต่ละองค์ประกอบ
3. สี: เติมพิกเซลของแต่ละองค์ประกอบลงในเลเยอร์
4. วัสดุเชิงประกอบ: วาดเลเยอร์ลงในหน้าจอ

แม้ว่าการกําหนดภาพเคลื่อนไหวจะมีหลายวิธี แต่ทุกวิธีจะมีหลักการพื้นฐานแบบใดแบบหนึ่ง ดังนี้

• การปรับคุณสมบัติเลย์เอาต์
• การปรับคุณสมบัติ 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> (หรืออาจจะใช้เทคนิคอย่างภาพนอกหน้าจอเพื่อดูแลให้อัตราเฟรมคงที่) ในทางเทคนิคอาจทำได้อย่างราบรื่นอย่างสมบูรณ์แบบในเรื่องเฟรมภาพเคลื่อนไหว แต่ในขณะเดียวกันก็โหลดเนื้อหาเกมคุณภาพสูงในฉากหรือไม่ได้แสดงภาพองค์ประกอบต่างๆ

และแน่นอนว่าเว็บไซต์อาจมีภาพเคลื่อนไหวที่ไม่ดีมากๆ 🙂

ฉันคิดว่าพวกเขาคงจะดีไม่น้อยเลยที่สละเวลามาฟัง!

สถานะของเฟรมภาพเคลื่อนไหวเดียว

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

ต่อไปนี้เป็นแง่มุมต่างๆ ที่เราตีความสถานะของเฟรมภาพเคลื่อนไหวเดียว โดยเรียงลำดับจากดีที่สุดไปหาแย่ที่สุด

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

รวมข้อมูลทั้งหมด: เมตริกเปอร์เซ็นต์ของเฟรมที่ลดน้อยลง

แม้ว่าบางครั้งอาจจำเป็นต้องเจาะลึกสถานะของเฟรมภาพเคลื่อนไหวแต่ละเฟรม แต่การกำหนดคะแนน "ข้อมูลโดยย่อ" แบบคร่าวๆ ก็มีประโยชน์เช่นกัน

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

โมเดลทางความคิดควรเริ่มจาก

1. เฟรมต่อวินาที เป็น
2. การตรวจหาอัปเดตภาพเคลื่อนไหวที่สำคัญและหายไป เพื่อ
3. เปอร์เซ็นต์ที่ลดลงในระยะเวลาที่กำหนด

สิ่งที่สำคัญก็คือ สัดส่วนของเวลาที่รอการอัปเดตที่สำคัญ เราคิดว่าวิธีนี้ตรงกับวิธีทั่วไปที่ผู้ใช้จะได้สัมผัส ความลื่นไหลของเนื้อหาเว็บ ที่ผ่านมา เราได้ใช้เมตริกต่อไปนี้เป็นชุดเมตริกเริ่มต้น

• เปอร์เซ็นต์ที่ลดลงโดยเฉลี่ย: สำหรับเฟรมภาพเคลื่อนไหวที่ไม่ได้ใช้งานทั้งหมดตลอดไทม์ไลน์
• กรณีที่แย่ที่สุดสำหรับเปอร์เซ็นต์เฟรมที่หลุด: ที่วัดได้ในกรอบเวลาการเลื่อน 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]" ในบรรทัดเรื่อง เราหวังเป็นอย่างยิ่งว่าจะได้รับ ความคิดเห็นจากคุณ