ในช่วง 2-3 ปีที่ผ่านมา เบราว์เซอร์ได้พัฒนาประสิทธิภาพการแสดงผลไปอย่างมาก โดยเฉพาะบนอุปกรณ์เคลื่อนที่ ก่อนหน้านี้คุณไม่มีทางที่จะได้เฟรมเรตที่ราบรื่นสำหรับเนื้อหาที่ซับซ้อน แต่ตอนนี้คุณก็ทำได้หากทำอย่างระมัดระวัง
แต่สำหรับพวกเราส่วนใหญ่แล้ว สิ่งที่เราทดสอบในอุปกรณ์ของตัวเองได้นั้นไม่ตรงกับสิ่งที่ผู้ใช้ได้รับ หากผู้ใช้ไม่ได้รับประสบการณ์การรับชมที่ราบรื่นระดับ 60 fps ประสบการณ์ของผู้ใช้ก็จะแย่ลง และท้ายที่สุดผู้ใช้ก็จะเปลี่ยนไปใช้บริการอื่นและเราก็จะได้รับผลกระทบ ด้วยเหตุนี้ W3C จึงกำลังพูดคุยเกี่ยวกับ API ใหม่ที่จะช่วยให้เราเห็นสิ่งที่ผู้ใช้เห็น ซึ่งก็คือ Frame Timing API
เมื่อเร็วๆ นี้ Jake Archibald และฉันได้บันทึกวิดีโอภาพรวมของ API นี้ไว้ หากต้องการดูแทนการอ่าน โปรดดูวิดีโอต่อไปนี้
การใช้ Frame Timing API
คุณสามารถทําสิ่งต่างๆ มากมายด้วย Frame Timing API และที่สำคัญคือคุณสามารถวัดสิ่งที่สําคัญต่อคุณและโปรเจ็กต์ อย่างไรก็ตาม ต่อไปนี้เป็นแนวคิดบางส่วน
- ติดตาม FPS ของภาพเคลื่อนไหว JavaScript และ CSS
- ติดตามความลื่นไหลของการเลื่อนหน้าเว็บ (หรือรายการแบบเลื่อนได้ไม่รู้จบที่ยอดเยี่ยมที่คุณมี)
- ลดเอฟเฟกต์ภาพให้น้อยลงโดยอัตโนมัติตามภาระงานปัจจุบันของอุปกรณ์
- การทดสอบแบบถดถอยในเมตริกประสิทธิภาพรันไทม์
การเสนอขายโดยใช้เวลาสั้นๆ
หน้าตาของ API ในข้อกําหนดปัจจุบันเป็นอย่างไร คุณสามารถดึงข้อมูลเกี่ยวกับเวลาของเธรดโปรแกรมแสดงผล ซึ่ง JavaScript, สไตล์ และเลย์เอาต์ทํางานอยู่ (คุณอาจเคยได้ยินว่าเทรดเดอร์เรนเดอร์เรียกว่าเทรดหลัก ซึ่งก็เหมือนกัน เพียงแต่ใช้ชื่ออื่น)
var rendererEvents = window.performance.getEntriesByType("renderer");
ระเบียนแต่ละรายการของเธรดโปรแกรมแสดงผลที่คุณได้รับจะมีลักษณะดังนี้
{
sourceFrameNumber: 120,
startTime: 1342.549374253
cpuTime: 6.454313323
}
โดยพื้นฐานแล้ว แต่ละระเบียนคือออบเจ็กต์ที่มีหมายเลขเฟรมที่ไม่ซ้ำกัน การประทับเวลาความละเอียดสูงสำหรับเวลาที่เฟรมเริ่มต้น และอีกรายการสำหรับระยะเวลาที่ใช้ CPU เมื่อใช้อาร์เรย์เหล่านี้ คุณสามารถดูค่า startTime
แต่ละค่าและดูว่าเธรดหลักทำงานที่ 60 fps หรือไม่ โดยพื้นฐานแล้ว "startTime
ของเฟรมแต่ละเฟรมเพิ่มขึ้นเป็นกลุ่มๆ ประมาณ 16 มิลลิวินาทีหรือไม่"
แต่นอกจากนี้ คุณยังจะได้รับ cpuTime
ด้วย เพื่อที่จะทราบว่าคุณอยู่ในขอบเขต 16 มิลลิวินาทีอย่างสบายๆ หรืออยู่ในระดับที่ช้า หาก cpuTime
อยู่ใกล้กับขอบเขต 16 มิลลิวินาที แสดงว่าระบบมีเวลาไม่มากนักสำหรับการดำเนินการต่างๆ เช่น การรวบรวมขยะ และการใช้งาน CPU ที่สูงจะทำให้แบตเตอรี่หมดเร็วขึ้นด้วย
นอกจากข้อมูลของเธรดโปรแกรมแสดงผลแล้ว คุณยังดึงข้อมูลเกี่ยวกับเวลาของเธรดคอมโพสิตได้อีกด้วย ซึ่งจะแสดงภาพและคอมโพสิต
var compositeThreadEvents = window.performance.getEntriesByType("composite");
แต่ละรายการเหล่านี้จะแสดงผลพร้อมหมายเลขเฟรมต้นทางด้วย ซึ่งคุณใช้เพื่อเชื่อมโยงกับเหตุการณ์ของเธรดหลักได้
{
sourceFrameNumber: 120,
startTime: 1352.343235321
}
เนื่องจากวิธีคอมโพสมักจะทํางานในเบราว์เซอร์ บันทึกเหล่านี้จึงอาจมีหลายรายการต่อบันทึกเธรดโปรแกรมแสดงผล 1 รายการ คุณจึงใช้ sourceFrameNumber
เพื่อเชื่อมโยงบันทึกเหล่านั้นกลับเข้าด้วยกันได้ นอกจากนี้ ยังมีการสนทนากันว่าควรระบุเวลา CPU ในระเบียนเหล่านี้ด้วยหรือไม่ ดังนั้นหากคุณมีความเห็นที่แน่ชัด ก็แสดงความคิดเห็นในปัญหา GitHub
ข้อมูลเพิ่มเติม
API นี้ยังไม่พร้อมใช้งาน แต่หวังว่าจะพร้อมใช้งานเร็วๆ นี้ ในระหว่างนี้ คุณสามารถอ่านและทำสิ่งต่อไปนี้ได้
- อ่านเอกสารอธิบายในรีโพสิทอรี่ มีหลายแง่มุมเกี่ยวกับวิธีบันทึกข้อมูลเฟรมให้มีประโยชน์มากที่สุด และคำอธิบายจะชี้แนะแนวทางบางส่วนที่นี่
- ดูฉบับร่างล่าสุดของข้อกำหนด เนื้อหาไม่ซับซ้อนมากนักและควรค่าแก่การอ่าน
- รายงานปัญหาเกี่ยวกับฟีเจอร์ที่ขาดหายไปหรือปัญหาที่อาจเกิดขึ้น คุณทราบดีว่าต้องการวัดอะไร ดังนั้นโปรดแสดงความคิดเห็นหากคิดว่ามีบางอย่างที่คุณทําไม่ได้กับ API ที่ต้องการ