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

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

Behdad Bakhshinategh

Jonathan Ross

Michal Mocny

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

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

โพสต์นี้จะมีหัวข้อหลัก 3 หัวข้อดังต่อไปนี้

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

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

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

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

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

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

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

แม้ว่าจะมีวิธีกำหนดภาพเคลื่อนไหวหลายวิธี แต่ภาพเคลื่อนไหวทั้งหมดจะทำงานผ่านวิธีใดวิธีหนึ่งต่อไปนี้

• การปรับเลย์เอาต์ พร็อพเพอร์ตี้
• การปรับคุณสมบัติสี
• การปรับพร็อพเพอร์ตี้คอมโพสิต

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

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

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

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

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

แสดงการอัปเดตเป็นระยะๆ เพื่อให้การอัปเดตภาพเป็นกลุ่ม หลายหน้าจอจะอัปเดตตามช่วงเวลาที่กำหนดไว้ เช่น 60 ครั้งต่อวินาที (60 Hz) จอแสดงผลที่ทันสมัยบางรุ่นอาจเสนออัตราการรีเฟรชที่สูงขึ้น (90–120 Hz กำลังได้รับความนิยม) บ่อยครั้งที่จอแสดงผลเหล่านี้สามารถปรับอัตราการรีเฟรชตามต้องการ หรือแม้แต่เสนออัตราเฟรมที่ปรับได้อย่างเต็มที่

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

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

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

อะไรส่งผลต่อเฟรมภาพเคลื่อนไหว

นักพัฒนาเว็บสามารถส่งผลอย่างมากต่อความสามารถของเบราว์เซอร์ในการแสดงผลและนำเสนอการอัปเดตภาพอย่างรวดเร็วและมีประสิทธิภาพ

ตัวอย่างมีดังต่อไปนี้

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

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

วิธีหนึ่งที่เป็นไปได้คือการใช้แบบสำรวจ requestAnimationFrame() แต่ก็มีข้อเสียหลายประการ requestAnimationFrame() หรือ "rAF" จะบอกให้เบราว์เซอร์ทราบว่าคุณต้องการแสดงภาพเคลื่อนไหวและขอโอกาสดำเนินการดังกล่าวก่อนขั้นตอนการแสดงผลถัดไปของไปป์ไลน์การแสดงผล หากไม่มีการเรียกใช้ฟังก์ชัน Callback ในเวลาที่คาดไว้ แสดงว่าไม่มีการทําสีและข้ามเฟรมอย่างน้อย 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 ลดลงอย่างไรเมื่อมีงานมากเกินไปในเธรดหลัก (เช่น เลย์เอาต์)

เมื่อเธรดหลักทำงานช้า การอัปเดตภาพจะเริ่มกระตุก นั่นมันวุ่นวายมาก!

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

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

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

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

สำหรับเฟรมภาพเคลื่อนไหว เรื่องราวไม่ง่ายนัก

เฟรมภาพเคลื่อนไหว: ข้อมูลอัปเดตที่สำคัญ

ตัวอย่างข้างต้นแสดงให้เห็นว่าเรื่องราวมีมากกว่าแค่ requestAnimationFrame()

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

• การอัปเดตชุดข้อความหลักและคอมโพสเซอร์
• ไม่มีการอัปเดตสี
• การตรวจหาภาพเคลื่อนไหว
• คุณภาพกับปริมาณ

การอัปเดตชุดข้อความหลักและคอมโพสิต

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

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

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

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

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

ไม่มีการอัปเดตการแสดงผล

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

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

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

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

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

อัตราเฟรมจึงสำคัญในกรณีใด

การตรวจหาภาพเคลื่อนไหว

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

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

แม้จะใช้ requestAnimationFrame() ก็ตาม คุณก็ไม่สามารถสรุปได้ว่าการเรียก rAF ทุกครั้งจะสร้างการอัปเดตภาพหรือภาพเคลื่อนไหวเสมอไป ตัวอย่างเช่น การใช้การสำรวจ rAF เพื่อติดตามอัตราเฟรม (ดังที่แสดงด้านบน) ไม่ควรส่งผลต่อการวัดความลื่นไหล เนื่องจากไม่มีการอัปเดตภาพ

คุณภาพกับปริมาณ

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

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

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

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

เราคิดว่ามันเจ๋งมากสำหรับยุคนั้น

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

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

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

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

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

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

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

รูปแบบความคิดควรเปลี่ยนจาก

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

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

• เปอร์เซ็นต์เฉลี่ยที่ลดลง: สำหรับเฟรมภาพเคลื่อนไหวทั้งหมดที่ไม่ได้ทำงานตลอดไทม์ไลน์
• เปอร์เซ็นต์เฟรมที่หลุดออกที่เลวร้ายที่สุด: ตามที่วัดในกรอบเวลา 1 วินาที
• เปอร์เซ็นไทล์ที่ 95 ของเปอร์เซ็นต์เฟรมที่หลุด: วัดจากช่วงเวลา 1 วินาทีโดยประมาณ

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

ลองใช้เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ได้เลย

HUD ประสิทธิภาพ

Chromium มี HUD ด้านประสิทธิภาพที่สวยงามซ่อนอยู่หลังแฟล็ก (chrome://flags/#show-performance-metrics-hud) ใน Chrome คุณจะพบคะแนนสดสำหรับสิ่งต่างๆ เช่น Core Web Vitals รวมถึงคำจำกัดความจากการทดสอบ 2-3 รายการเกี่ยวกับความลื่นไหลของภาพเคลื่อนไหวโดยอิงตามเปอร์เซ็นต์เฟรมที่หลุดเมื่อเวลาผ่านไป

สถิติการแสดงผลเฟรม

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