เรียนรู้เกี่ยวกับความคิดของเราเกี่ยวกับการวัดการตอบสนองและแสดงความคิดเห็น
ในทีมเมตริกความเร็วของ Chrome เรากำลังพยายามทำความเข้าใจให้ลึกซึ้งยิ่งขึ้นว่าหน้าเว็บตอบสนองต่อข้อมูลจากผู้ใช้ได้รวดเร็วเพียงใด เราต้องการแชร์ไอเดียในการปรับปรุงเมตริกการตอบสนองและ รับฟังความคิดเห็นของคุณ
โพสต์นี้จะครอบคลุมหัวข้อหลักๆ 2 หัวข้อ ได้แก่
- ตรวจสอบเมตริกการตอบสนองปัจจุบันของเรา First Input Delay (FID) และอธิบายเหตุผลที่เราเลือก FID มากกว่าตัวเลือกอื่นๆ
- โปรดแสดงการปรับปรุงที่เราพิจารณาแล้วซึ่งน่าจะช่วยให้เห็นเวลาในการตอบสนองตั้งแต่ต้นจนจบของแต่ละเหตุการณ์ได้ดีขึ้น การปรับปรุงเหล่านี้ยังมีเป้าหมายเพื่อให้เห็นภาพโดยรวมของการตอบสนองของหน้าเว็บตลอดอายุการใช้งาน
First Input Delay คืออะไร
เมตริก First Input Delay (FID) จะวัดระยะเวลาที่เบราว์เซอร์ใช้ในการเริ่มประมวลผลการโต้ตอบของผู้ใช้ครั้งแรกในหน้าเว็บ โดยเฉพาะอย่างยิ่ง เมตริกนี้จะวัดความแตกต่างระหว่างเวลาที่ผู้ใช้��ต้ตอบกับอุปกรณ์กับเวลาที่เบราว์เซอร์สามารถเริ่มประมวลผลตัวแฮนเดิลเหตุการณ์ได้จริง ระบบจะวัด FID เฉพาะในการแตะและการกดแป้น ซึ่งหมายความว่าระบบจะพิจารณาเฉพาะเหตุการณ์ต่อไปนี้ที่เกิดขึ้นเป็นครั้งแรกเท่านั้น
click
keydown
mousedown
pointerdown
(เฉพาะในกรณีที่ตามด้วยpointerup
)
แผนภาพต่อไปนี้แสดง FID
FID ไม่รวมเวลาที่ใช้ในการเรียกใช้เครื่องจัดการเหตุการณ์เหล่านั้น หรืองานที่เบราว์เซอร์ทำขึ้นภายหลังเพื่ออัปเดตหน้าจอ ซึ่งวัดระยะเวลาที่เทรดหลักไม่ว่างก่อนที่จะมีโอกาสจัดการกับอินพุต ระยะเวลาในการบล็อกนี้มักเกิดจากงาน JavaScript ที่ใช้เวลานาน เนื่องจากไม่สามารถหยุดการดำเนินการเหล่านี้ได้ทุกเมื่อ ดังนั้นงานปัจจุบันจะต้องเสร็จสมบูรณ์ก่อน เบราว์เซอร์จึงจะเริ่มประมวลผลอินพุตได้
เหตุผลที่เราเลือก FID
เราเชื่อว่าการวัดประสบการณ์จริงของผู้ใช้เป็นสิ่งสำคัญ เพื่อให้มั่นใจว่าการปรับปรุงเมตริกจะสร้างประโยชน์ให้แก่ผู้ใช้อย่างแท้จริง เราเลือกที่จะวัด FID เพราะแสดงถึงประสบการณ์ส่วนหนึ่งในประสบการณ์ที่ผู้ใช้ตัดสินใจโต้ตอบกับเว็บไซต์ที่เพิ่งโหลดขึ้นมา FID จะเก็บข้อมูลบางครั้งที่ผู้ใช้ต้องรอเพื่อดูการตอบสนองจากการโต้ตอบกับเว็บไซต์ กล่าวคือ FID คือขอบเขตล่างของระยะเวลาที่ผู้ใช้รอหลังจากการโต้ตอบ
เมตริกอื่นๆ เช่น Total block Time (TBT) และ Time To Interactive (TTI) จะอิงตามงานที่ใช้เวลานาน และจะวัดเวลาที่ใช้ในการบล็อกเทรดหลั��ระหว่างการโหลดด้วย เช่นเดียวกับ FID เนื่องจากเมตริกเหล่านี้สามารถวัดได้ทั้งในภาคสนามและในห้องทดลอง นักพัฒนาซอฟต์แวร์จำนวนมากจึงถามว่าทำไมเราถึงไม่ชอบเมตริกเหล่านี้มากกว่า FID
ทั้งนี้เนื่องจากสาเหตุหลายประการ บางทีเหตุผลที่สำคัญที่สุดก็คือเมตริกเหล่านี้ไม่ได้วัดประสบการณ์ของผู้ใช้โดยตรง เมตริกทั้งหมดนี้จะวัดจำนวน JavaScript ที่ทำงานในหน้าเว็บ แม้ว่าการใช้งาน JavaScript เป็นเวลานานมีแนวโน้มจะทำให้เกิดปัญหากับเว็บไซต์ แต่งานเหล่านี้ไม่ได้ส่งผลต่อประสบการณ์ของผู้ใช้เสมอไปหากผู้ใช้ไม่ได้โต้ตอบกับหน้าเว็บในขณะที่เกิดขึ้น หน้าเว็บอาจได้คะแนนที่ดีใน TBT และ TTI แต่รู้สึกว่าหน้าเว็บทำงานช้าหรืออาจได้คะแนนต่ำและทำให้ผู้ใช้รู้สึกว่าเร็ว จากประสบการณ์ของเรา การวัดทางอ้อมเหล่านี้ให้ผลลัพธ์เป็นเมตริกที่ใช้งานได้ดีกับบางเว็บไซต์ แต่ไม่เหมาะสำหรับเว็บไซต์ส่วนใหญ่ สรุปสั้นๆ ได้ว่างานที่ใช้เวลานานและ TTI ไม่ได้เน้นผู้ใช้เป็นหลักทำให้ตัวเลือกที่ไม่รัดกุมเหล่านี้ลดลง
แม้ว่าการวัดผลในห้องทดลองจะมีความสำคัญและเป็นเครื่องมือที่มีค่าอย่างยิ่งสำหรับการวินิจฉัย แต่สิ่งสำคัญคือประสบการณ์การใช้งานเว็บไซต์ของผู้ใช้ การมีเมตริกที่เน้นผู้ใช้เป็นหลักซึ่งแสดงถึงเงื่อนไขของผู้ใช้จริงจะช่วยให้คุณมั่นใจได้ว่าจะสื่อสารข้อมูลที่เกี่ยวข้องกับประสบการณ์ของผู้ใช้ได้ เราตัดสินใจเริ่มจากส่วนเล็กๆ ของประสบการณ์นั้น แม้เราจะทราบดีว่าส่วนนี้ไม่ได้แสดงถึงประสบการณ์เต็มรูปแบบ ด้วยเหตุนี้ เราจึงพยายามบันทึกช่วงเวลาที่ผู้ใช้รอให้มีการจัดการข้อมูลมากขึ้น
การวัด TTI กับผู้ใช้จริงภาคสนามนั้นถือเป็นปัญหาเนื่องจากเกิดขึ้นในช่วงท้ายของการโหลดหน้าเว็บ ต้องมีกรอบเวลาที่เงียบในเครือข่ายเป็นเวลา 5 วินาทีก่อนจึงจะคำนวณ TTI ได้ ในห้องทดลอง คุณสามารถเลือกยกเลิกการโหลดหน้านี้เมื่อใดก็ตามที่คุณมีข้อมูลทั้งหมดที่ต้องการ แต่จะไม่ต้องมีการตรวจสอบโดยผู้ใช้จริงในช่อง ผู้ใช้อาจเลือกออกจากหน้าเว็บหรือโต้ตอบกับหน้าเว็บได้ทุกเมื่อ โดยเฉพาะอย่างยิ่ง ผู้ใช้อาจเลือกออกจากหน้าเว็บที่ใช้เวล���โหลดนาน และ TTI ที่ถูกต้องจะไม่ได้รับการบันทึกในกรณีดังกล่าว เมื่อวัด TTI สำหรับผู้ใช้จริงใน Chrome เราพบว่ามีการโหลดหน้าเว็บเพียงครึ่งหนึ่งที่เข้าถึง TTI
เรากําลังพิจารณาการปรับปรุงอะไรบ้าง
เราต้องการพัฒนาเมตริกใหม่ที่ขยายสิ่งที่ FID ใช้วัดในปัจจุบัน แต่ยังคงรักษาความสัมพันธ์ที่แน่นแฟ้นกับประสบการณ์ของผู้ใช้ไว้ได้
เราต้องการให้เมตริกใหม่ทำงานต่อไปนี้
- พิจารณาการตอบสนองของอินพุตทั้งหมดของผู้ใช้ (ไม่ใช่แค่รายการแรก)
- จับภาพเต็มระยะเวลาของแต่ละเหตุการณ์ (ไม่ใช่แค่การหน่วงเวลา)
- จัดกลุ่มเหตุการณ์ที่เกิดขึ้นเป็นส่วนหนึ่งของการโต้ตอบของผู้ใช้เชิงตรรกะเดียวกัน และกำหนดเวลาในการตอบสนองของการโต้ตอบนั้นเป็นระยะเวลาสูงสุดของเหตุการณ์ทั้งหมด
- สร้างคะแนนรวมสำหรับการโต้ตอบทั้งหมดที่เกิดขึ้นในหน้าเว็บตลอดอายุการใช้งาน
ในการที่จะประสบความสำเร็จ เราควรสามารถบอกได้อย่างมั่นใจว่าหากเว็บไซต��ได้คะแนนต่ำสำหรับเมตริกใหม่นี้ เว็บไซต์ตอบสนองการโต้ตอบของผู้ใช้ได้ไม่ดีนัก
บันทึกระยะเวลาของเหตุการณ์ทั้งหมด
การปรับปรุงที่ชัดเจนอย่างแรกคือการพยายามตรวจจับเวลาในการตอบสนองจากต้นทางถึงปลายทางให้กว้างขึ้น ตามที่กล่าวไว้ข้างต้น FID จะบันทึกเฉพาะส่วนที่ล่าช้าของเหตุการณ์อินพุตเท่านั้น แต่ไม่ได้พิจารณาถึงเวลาที่เบราว์เซอร์ใช้ในการประมวลผลตัวแฮนเดิลเหตุการณ์
วงจรเหตุการณ์มีอยู่หลายขั้นตอน ดังที่แสดงในแผนภาพนี้
โดย Chrome จะประมวลผลอินพุตดังนี้
- ข้อมูลจากผู้ใช้จะปรากฏขึ้น เวลาที่เหตุการณ์นี้เกิดขึ้นคือ
timeStamp
ของกิจกรรม - เบราว์เซอร์จะทำการทดสอบ Hit เพื่อเลือกเฟรม HTML (เฟรมหลักหรือ iframe บางรายการ) ของเหตุการณ์ จากนั้นเบราว์เซอร์จะส่งเหตุการณ์ไปยังกระบวนการแสดงผลที่เหมาะสมซึ่งรับผิดชอบเฟรม HTML นั้น
- โหมดแสดงภาพจะรับเหตุการณ์และจัดคิวเพื่อให้ประมวลผลได้เมื่อพร้อม
- ตัวแสดงผลจะประมวลผลเหตุการณ์โดยการเรียกใช้เครื่องจัดการ เครื่องจัดการเหล่านี้อาจจัดคิวงานที่ไม่พร้อมกันเพิ่มเติม เช่น
setTimeout
และการดึงข้อมูล ซึ่งเป็นส่วนหนึ่งของการจัดการอินพุต แต่ในจุดนี้ งานพร้อมกันเสร็จสมบูรณ์แล้ว - มีการกำหนดเฟรมลงในหน้าจอที่สะท้อนถึงผลลัพธ์ของตัวแฮนเดิลเหตุการณ์ที่ทำงานอยู่ โปรดทราบว่างานแบบไม่พร้อมกันที่อยู่ในคิวโดยตัวแฮนเดิลเหตุการณ์อาจยังดำเนินการไม่เสร็จ
เวลาระหว่างขั้นตอน (1) ถึง (3) ด้านบนคือความล่าช้าของเหตุการณ์ ซึ่งเป็นสิ่งที่ FID วัด
เวลาระหว่างขั้นตอน (1) ถึง (5) ด้านบนคือระยะเวลาของเหตุการณ์ นี่คือสิ่งที่เมตริกใหม่ของเรา จะใช้วัด
ระยะเวลาของเหตุการณ์จะรวมการหน่วงเวลาด้วย แต่ก็ยังรวมงานที่เกิดขึ้นในเ��รื่องจัดการเหตุการณ์และงานที่เบราว์เซอร์ต้องทำเพื่อระบายสีเฟรมถัดไปหลังจากตัวแฮนเดิลเหล่านั้นทำงานแล้ว ปัจจุบันระยะเวลาของเหตุการณ์จะอยู่ใน Event Timing API ผ่านทางแอตทริบิวต์ duration ของรายการ
โดยหลักการแล้ว เราขอบันทึกงานที่ไม่พร้อมกันซึ่งเกิดจากเหตุการณ์ด้วย แต่ปัญหาคือคำจำกัดความของการทำงานแบบไม่พร้อมกันซึ่งเกิดจากเหตุการณ์นั้นเป็นเรื่องยากมากที่จะถูกต้อง ตัวอย่างเช่น นักพัฒนาซอฟต์แวร์อาจเลือกเริ่มภาพเคลื่อนไหวบางส่วนในตัวแฮนเดิลเหตุการณ์และใช้ setTimeout
เพื่อเริ่มภาพเคลื่อนไหวดังกล่าว หากเราบันทึกงานทั้งหมดที่โพสต์ในเครื่องจัดการ ภาพเคลื่อนไหวจะหน่วงเวลาการทำงานให้เสร็จตราบเท่าที่ภาพเคลื่อนไหวยังทำงานอยู่ เราเชื่อว่าการตรวจสอบทางเลือกต่างๆ ในการใช้การเรียนรู้วิทยาเพื่อตรวจจับงานที่ไม่พร้อมกันและควรทำให้เสร็จโดยเร็วที่สุดเป็นสิ่งที่คุ้มค่า อย่างไรก็ตาม เราต้องการระมัดระวังอย่างมากเมื่อดำเนินการดังกล่าว เนื่องจากเราไม่ต้องการลงโทษงานที่ตั้งใจจะใช้เวลานานจึงจะเสร็จ ดังนั้น ความพยายามระยะแรกเราจะดูที่ขั้นตอนที่ 5 เป็นจุดสิ้นสุด โดยจะพิจารณาเฉพาะงานแบบพร้อมกันและระยะเวลาที่ใช้ในการวาดรูปแบบหลังจากที่งานดังกล่าวเสร็จสมบูรณ์ กล่าวคือ เราจะไม่ใช้การเรียนรู้เพื่อคาดเดางานที่จะเกิดขึ้นแบบไม่พร้อมกันในขั้นตอนที่ 4 ในตอนแรกของเรา
ทั้งนี้ ในหลายกรณี งานควรดำเนินการแบบพร้อมกัน อันที่จริง กรณีนี้อาจหลีกเลี่ยงไม่ได้ เนื่องจากบางครั้งอาจมีการส่งเหตุการณ์ทีละรายการและตัวแฮนเดิลเหตุการณ์ต้องได้รับการดำเนินการตามลำดับ อย่างไรก็ตาม เราจะยังพลาดงานสำคัญ เช่น เหตุการณ์ที่ทริกเกอร์การดึงข้อมูล หรืองานที่ต้องอาศัยงานสำคัญที่ต้องทำในโค้ดเรียกกลับ requestAnimationFrame
���รั้ง��ัดไป เป็นต้น
จัดกลุ่มเหตุการณ์เป็นการโต้ตอบ
การขยายการวัดเมตริกจากล่าช้าเป็นระยะเวลาเป็นขั้นตอนแรกที่ดี แต่ยังคงทำให้เกิดช่องว่างสำคัญในเมตริก โดยเน้นที่เหตุการณ์แต่ละรายการ ไม่ใช่ประสบการณ์ของผู้ใช้ในการโต้ตอบกับหน้าเว็บ
เหตุการณ์ต่างๆ จำนวนมากสามารถเริ่มทำงานอันเป็นผลจากการโต้ตอบของผู้ใช้รายเดียว และการวัดผลแต่ละครั้งแยกกันไม่ได้สร้างภาพที่ชัดเจนของประสบการณ์ของผู้ใช้ เราอยากให้เมตริกของเราบันทึกระยะเวลาทั้งหมดที่ผู้ใช้ต้องรอการตอบสนองเมื่อแตะ กดปุ่ม เลื่อน และลากได้อย่างแม่นยำที่สุด เราจึงเปิดตัวแนวคิดของการโต้ตอบเพื่อวัดเวลาในการตอบสนองของแต่ละการโต้ตอบ
ประเภทการโต้ตอบ
ตารางต่อไปนี้แสดงการโต้ตอบ 4 รายการที่เราต้องการกำหนดพร้อมด้วยเหตุการณ์ DOM ที่เกี่ยวข้อง โปรดทราบว่าตัวเลขนี้ไม่เหมือนกับชุดเหตุการณ์ทั้งหมดที่ส่งเมื่อมีการโต้ตอบของผู้ใช้ดังกล่าวเกิดขึ้น ตัวอย่างเช่น เมื่อผู้ใช้เลื่อนหน้าจอ เหตุการณ์การเลื่อนจะถูกส่ง แต่จะเกิดขึ้นหลังจากที่หน้าจอได้รับการอัปเดตเพื่อแสดงการเลื่อนแล้ว ดังนั้นเราจะไม่ถือว่านี่เป็นเวลาในการตอบสนองของการโต้ตอบ
การโต้ตอบ | เริ่มต้น / สิ้นสุด | เหตุการณ์ในเดสก์ท็อป | เหตุการณ์ในอุปกรณ์เคลื่อนที่ |
---|---|---|---|
แป้นพิมพ์ | กดแป้นแล้ว | keydown |
keydown |
keypress |
keypress |
||
ปล่อยคีย์แล้ว | keyup |
keyup |
|
แตะหรือลาก | แตะเริ่มหรือลากจุดเริ่มต้น | pointerdown |
pointerdown |
mousedown |
touchstart |
||
แตะขึ้นหรือลากสิ้นสุด | pointerup |
pointerup |
|
mouseup |
touchend |
||
click |
mousedown |
||
mouseup |
|||
click |
|||
เลื่อน | ไม่มีข้อมูล |
ปัจจุบันการโต้ตอบ 3 รายการแรกที่แสดงด้านบน (แป้นพิมพ์ แตะ และลาก) อยู่ภายใต้ FID สำหรับเมตริกการตอบสนองใหม่ เราต้องการรวมการเลื่อนไว้ด้วย เนื่องจากการเลื่อนเป็นเรื่องที่พบได้บ่อยบนเว็บและเป็นส่วนสำคัญของการตอบสนองของหน้าเว็บสำหรับผู้ใช้
โปรดทราบว่าการโต้ตอบแต่ละครั้งจะมี 2 ส่วน ได้แก่ เมื่อผู้ใช้กดเมาส์ นิ้ว หรือแป้นลง และเมื่อผู้ใช้ยกนิ้วขึ้น เราต้องการให้เมตริกไม่นับเวลาที่ผู้ใช้ใช้นิ้วกดระหว่างการดำเนินการทั้ง 2 อย่างนี้เป็นส่วนหนึ่งของเวลาในการตอบสนองของหน้าเว็บ
แป้นพิมพ์
การโต้ตอบกับแป้นพิมพ์นั้นแบ่งออกเป็น 2 ส่วน ได้แก่ เมื่อผู้ใช้กดแป้นและเมื่อปล่อยมือ
การโต้ตอบของผู้ใช้นี้มี 3 เหตุการณ์ ได้แก่ keydown
, keyup
และ keypress
แผนภาพต่อไปนี้แสดงการหน่วงเวลาและระยะเวลาของ keydown
และ keyup
สำหรับการโต้ตอบกับแป้นพิมพ์
ในแผนภาพด้านบน ระยะเวลาไม่ต่อเนื่องกันเพราะมีการแสดงเฟรมจากการอัปเดต keydown
ก่อนที่ keyup
จะเกิดขึ้น แต่ไม่จำเป็นต้องเป็นเช่นนี้เสมอไป นอกจากนี้ โปรดทราบว่าคุณสามารถนำเสนอเฟรมระหว่างกระบวนการของโหมดแสดงภาพได้เนื่องจากขั้นตอนสุดท้ายที่จำเป็นในการสร้างเฟรมนั้นเสร็จสิ้นนอกกระบวนการของโหมดแสดงภาพ
keydown
และ keypress
จะเกิดขึ้นเมื่อผู้ใช้กดแป้น ส่วน keyup
จะเกิดขึ้นเมื่อผู้ใช้ปล่อย��ีย์ โดยปกติแล้ว การอัปเดตเนื้อหาหลักจะเกิดขึ้นเมื่อมีการกดแป้น เช่น ข้อความปรากฏขึ้นบนหน้าจอ หรือมีการใช้เอฟเฟกต์ตัวปรับแต่ง อย่างไรก็ตาม เราต้องการบันทึกกรณีที่เกิดขึ้นไม่บ่อยซึ่ง keyup
จะนำเสนอการอัปเดต UI ที่น่าสนใจด้วย เราจึงอยากดูเวลาโดยรวม
เราคำนวณระยะเวลาสูงสุดของเหตุการณ์ keydown
และ keyup
ได้เพื่อบันทึกเวลาโดยรวมที่ใช้การโต้ตอบทางแป้นพิมพ์
กรณีนี้มีความสําคัญอย่างยิ่งที่ควรกล่าวถึง อาจมีบางกรณีที่ผู้ใช้กดแป้นและใช้เวลาสักครู่จึงจะปล่อยแป้นได้ ในกรณีนี้ ลำดับของเหตุการณ์ที่จัดส่งอาจแตกต่างกัน ในกรณีเหล่านี้ เราจะถือว่ามีการโต้ตอบ 1 ครั้งต่อ keydown
ซึ่งอาจมีหรือไม่มี keyup
ที่สอดคล้องกัน
แตะ
การโต้ตอบที่สำคัญอีกอย่างของผู้ใช้คือเมื่อผู้ใช้แตะหรือคลิกเว็บไซต์ เช่นเดียวกับ keypress
เหตุการณ์บางอย่างจะเริ่มทำงานเมื่อผู้ใช้กดลง และเหตุการณ์อื่นๆ เมื่อปล่อยออกมา ดังที่แสดงในแผนภาพด้านบน โปรดทราบว่าเหตุการณ์ที่เกี่ยวข้องกับการแตะจะแตกต่างกันเล็กน้อยในเดสก์ท็อปและอุปกรณ์เคลื่อนที่
สำหรับการแตะหรือคลิก การเปิดตัวมักจะเป็นการโต้ตอบที่กระตุ้นให้เกิดรีแอ็กชันส่วนใหญ่ แต่เราต้องการจับการโต้ตอบให้ได้อย่างเต็มรูปแบบเช่นเดียวกับการโต้ตอบด้วยแป้นพิมพ์ และในกรณีนี้ก็นับว่าสำคัญกว่า เพราะการอัปเดต UI บางส่วนเมื่อกดการแตะนั้นไม่ใช่เรื่องผิดปกติ
เราต้องการรวมระยะเวลาของเหตุการณ์เหล่านี้ท��้งหมด แต่หลายเหตุการณ์ทับซ้อนกันอย่างมาก เราจึงต้องวัดเพียง pointerdown
, pointerup
และ click
เพื่อให้ครอบคลุมการโต้ตอบทั้งหมด
pointerdown
และ pointerup
ได้ไหมตอนแรกเราคิดว่าจะใช้เหตุการณ์ pointerdown
และ pointerup
และถือว่าเหตุการณ์เหล่านี้ครอบคลุมระยะเวลาทั้งหมดที่เราสนใจ ซึ่งไม่ใช่กรณีนี้ตามที่เคสขอบนี้แสดง ลองเปิดเว็บไซต์นี้ในอุปกรณ์เคลื่อนที่หรือใช้โปรแกรมจำลองอุปกรณ์เคลื่อนที่ แล้วแตะที่มีข้อความว่า "คลิกฉัน" เว็บไซต์นี้ทริกเกอร์การหน่วงเวลาการแตะเบราว์เซอร์ จากการตรวจสอบพบว่า pointerdown
, pointerup
และ touchend
จัดส่งอย่างรวดเร็ว ในขณะที่ mousedown
, mouseup
และ click
รอให้เกิดความล่าช้าก่อนที่จะจัดส่ง ซึ่งหมายความว่าหากเราดูเฉพาะ pointerdown
และ pointerup
เราคงจะพลาดระยะเวลาจากเหตุการณ์สังเคราะห์ ซึ่งมีขนาดใหญ่เนื่องจากความล่าช้าในการแตะของเบราว์เซอร์และควรรวมไว้ด้วย เราจึงควรวัด pointerdown
, pointerup
และ click
เพื่อให้ครอบคลุมการโต้ตอบทั้งหมด
ลาก
เราตัดสินใจรวมการลากด้วยเนื่องจากมีเหตุการณ์ที่เกี่ยวข้องที่คล้ายกัน และเนื่องจากโดยทั่วไปจะทำให้มีการอัปเดต UI ที่สำคัญต่อเว็บไซต์ แต่สำหรับเมตริกของเรา เราตั้งใจที่จะพิจารณาเฉพาะจุดเริ่มต้นของการลากและจุดสิ้นสุดการลาก ซึ่งเป็นส่วนเริ่มต้นและส่วนสุดท้ายของการลาก วิธีนี้จะช่วยให้คุณหาเหตุผลได้ง่ายขึ้น รวมถึงทำให้เวลาในการตอบสนองเทียบเท่ากับการโต้ตอบอื่นๆ ที่พิจารณา ซึ่งสอดคล้องกับการตัดสินใจของเราที่จะยกเว้นเหตุการณ์ต่อเนื่อง เช่น mouseover
นอกจากนี้ เราไม่พิจารณาการลากที่ใช้ผ่าน API การลากและวาง เนื่องจากการดำเนินการดั��กล่าวจะใช้งานได้เฉพาะบนเดสก์ท็อปเท่านั้น
การเลื่อน
หนึ่งในรูปแบบที่ใช้บ่อยที่สุดในการโต้ตอบกับเว็บไซต์คือการเลื่อน สำ��รับเมตริกใหม่ เราจะ ต้องวัดเวลาในการตอบสนองของการโต้ตอบแบบเลื่อนครั้งแรกของผู้ใช้ โดยเฉพาะอย่างยิ่ง เราให้ความสำคัญกับปฏิกิริยาเริ่มต้นของเบราว์เซอร์กับการที่ผู้ใช้ขอการเลื่อน เราจะไม่ครอบคลุมการเลื่อนดูเนื้อหาทั้งหมด การเลื่อนทำให้เกิดเฟรมจำนวนมาก และเราจะเน้น ความสนใจไปที่เฟรมแรกที่สร้างขึ้นเพื่อเป็นปฏิกิริยาต่อการเลื่อน
ทำไมถึงขอแค่รายการแรก สําหรับรายการหนึ่ง เฟรมต่อๆ ไปอาจได้รับมาจากข้อเสนอด้านความลื่นไหลแยกต่างหาก กล่าวคือ เมื่อผู้ใช้ได้เห็นผลการเลื่อนครั้งแรกแล้ว ควรวัดส่วนที่เหลือโดยพิจารณาจากความลื่นไหลของประสบการณ์ในการเลื่อน เราจึงคิดว่าการเพิ่มความลื่นไหล น่าจะตอบโจทย์ความต้องการนี้มากกว่า ดังนั้น เช่นเดียวกับ FID เราเลือกที่จะยึดประสบการณ์ของผู้ใช้ไว้แยกกันต่างหาก นั่นก็คือประสบการณ์ของผู้ใช้ที่มีจุดเกี่ยวข้องกับเวลาที่ชัดเจน ซึ่งทำให้เราสามารถคำนวณเวลาในการตอบสนองของผู้ใช้ได้โดยง่าย การเลื่อนทั้งหมดเป็นประสบการณ์ที่ต่อเนื่อง เราจึงไม่ตั้งใจที่จะวัดข้อมูลทั้งหมดในเมตริกนี้
แล้วเหตุใดจึงต้องวัดจำนวนการเลื่อน ประสิทธิภาพการเลื่อนที่เรารวบรวมไว้ใน Chrome แสดงให้เห็นว่าการเลื่อนมักจะเร็วมาก ถึงกระนั้นก็ตาม เรายังต้องการรวมเวลาในการตอบสนองเริ่มต้นในเมตริกใหม่ของเราด้วยเหตุผลหลายประการ อย่างแรกก็คือการเลื่อนจะเร็วก็ต่อเมื่อมีการเพิ่มประสิทธิภาพอย่างมากเท่านั้น เพราะเรื่องนี้สำคัญมาก ��ต่ก็ยังมีวิธีที่เว็บไซต์สามารถข้ามประโยชน์ด้านประสิทธิภาพบางประการที่เบราว์เซอร์มีให้ วิธีที่พบบ่อยที่สุดใน Chrome คือการบังคับให้เลื่อนในเทรดหลัก ดังนั้น เมตริกของเราก็น่าจะบอกได้เมื่อเกิดเหตุการณ์นี้ขึ้นและทำให้ประสิทธิภาพในการเลื่อนของผู้ใช้แย่ลง อย่างที่ 2 การเลื่อนดูเป็นสิ่งที่สำคัญมากจนพลาดไม่ได้ เรากังวลว่าหากยกเว้นการเลื่อน เราจะมีจุดบอดขนาดใหญ่ และประสิทธิภาพในการเลื่อนอาจลดลงเมื่อเวลาผ่านไปโดยที่นักพัฒนาเว็บไม่ทันสังเกตเห็น
มีเหตุการณ์จำนวนมากที่ระบบส่งเมื่อผู้ใช้เลื่อน เช่น touchstart
, touchmove
และ scroll
ยกเว้นเหตุการณ์การเลื่อน ส่วนใหญ่จะขึ้นอยู่กับอุปกรณ์ที่ใช้ในการเลื่อน นั่นคือระบบจะส่งเหตุการณ์การแตะเมื่อมีการเลื่อนด้วยนิ้วบนอุปกรณ์เคลื่อนที่ ในขณะที่เหตุการณ์จากล้อจะเกิดขึ้นเมื่อเลื่อนด้วยลูกกลิ้งเมาส์ เหตุการณ์การเลื่อนจะเริ่มทำงานหลังจากที่การเลื่อนครั้งแรกเสร็จสมบูรณ์แล้ว และโดยทั่วไปเหตุการณ์ DOM จะไม่บล็อกการเลื่อน เว้นแต่เว็บไซต์จะใช้ Listener เหตุการณ์แบบไม่พาสซีฟ เราจะถือว่าการเลื่อนแยกจากเหตุการณ์ DOM สิ่งที่เราต้องการวัดคือระยะเวลาตั้งแต่ที่ผู้ใช้เคลื่อนไหวมากพอจนเกิดท่าทางสัมผัสการเลื่อนจนถึงเฟรมแรกที่แสดงให้เห็นว่าการเลื่อนเกิดขึ้น
วิธีกำหนดเวลาในการตอบสนองของการโต้ตอบ
ดังที่กล่าวไว้ข้างต้น การโต้ตอบที่มีองค์ประกอบ "ลง" และ "ขึ้น" จะต้องมีการพิจารณาแยกกันเพื่อหลีกเลี่ยงการระบุเวลาที่ผู้ใช้ใช้นิ้วกดลง
สำหรับการโต้ตอบประเภทนี้ เราอยากให้เวลาในการตอบสนองเกี่ยวข้องกับระยะเวลาของทุกเหตุการณ์ที่เกี่ยวข้องกับการโต้ตอบเหล่านี้ เนื่องจาก��ะยะเวลาของ���ห��ุการณ์��ำหรับ��่���� "ลง" และ "ขึ้น" �����่ละส่วนของการโต้ตอบอาจทับซ้อนกัน คำจำกัดความที่ง่ายที่สุดของเวลาในการตอบสนองของการโต้ตอบที่เกิดขึ้นนี้คือระยะเวลาสูงสุดของเหตุการณ์ที่เชื่อมโยงกับระยะเวลานี้ กลับไปที่แผนภาพแป้นพิมพ์ก่อนหน้านี้ นี่จะเป็นระยะเวลา keydown
เนื่องจากยาวกว่า keyup
:
ระยะเวลาของ keydown
และ keyup
อาจทับซ้อนกันได้ ซึ่งอาจเกิดขึ้นเมื่อเฟรมที่แสดงสำหรับทั้ง 2 เหตุการณ์เหมือนกันตามแผนภาพต่อไปนี้
การใช้จำนวนสูงสุดมีทั้งข้อดีและข้อเสีย และเราอยากจะรับฟังความคิดเห็นของคุณ
- ข้อดี: สอดคล้องกับวิธีที่เราตั้งใจที่จะวัดการเลื่อนซึ่งเป็นการวัดค่าระยะเวลาเดียวเท่านั้น
- ข้อดี: มีจุดประสงค์เพื่อลดเสียงรบกวนในกรณีต่างๆ เช่น การโต้ตอบกับแป้นพิมพ์ ซึ่ง
keyup
มักจะไม่ทำอะไรเลย และเมื่อผู้ใช้กดแป้นแล้วปล่อยอย่างรวดเร็วหรือช้า - ข้อเสีย: ไม่ได้บันทึกเวลารอทั้งหมดของผู้ใช้ เช่น จะบันทึกจุดเริ่มต้นหรือจุดสิ้นสุดของการลาก แต่จะไม่จับทั้ง 2 แบบ
สำหรับการเลื่อน (ซึ่งมีเพียงเหตุการณ์เดียวที่เกี่ยวข้อง) เราต้องการกำหนดเวลาในการตอบสนองเป็นเวลาที่เบราว์เซอร์ใช้ในการสร้างเฟรมแรกอันเป็นผลมาจากการเลื่อน กล่าวคือ เวลาในการตอบสนองคือเดลต้าระหว่างเหตุการณ์ timeStamp
ของเหตุการณ์ DOM ���รก (เช่น touchmove
ถ้าใช้นิ้ว) ที่ใหญ่พอที่จะทริกเกอร์การเลื่อนและสีแรกซึ่งแสดงสถานที่ที่เลื่อน
รวมการโต้ตอบทั้งหมดต่อหน้า
เมื่อเราระบุเวลาในการตอบสนองของการโต้ตอบแล้ว เราจะต้องคำนวณค่ารวมสำหรับการโหลดหน้าเว็บซึ่งอาจมีการโต้ตอบของผู้ใช้หลายครั้ง การมีมูลค่าโดยรวมช่วยให้เราทำสิ่งต่อไปนี้ได้
- สร้างความสัมพันธ์กับเมตริกธุรกิจ
- ประเมินความสัมพันธ์กับเมตริกประสิทธิภาพอื่นๆ โดยหลักการแล้ว เมตริกใหม่ของเราจะมีอิสระเพียงพอในการเพิ่มคุณค่าให้กับเมตริกที่มีอยู่
- แสดงค่าต่างๆ ในเครื่องมือในรูปแบบที่เข้าใจง่าย
ในการรวบรวมข้อมูลนี้ เราต้องตอบคำถาม 2 ข้อต่อไปนี้
- เราพยายามรวบรวมตัวเลขใดบ้าง
- เราจะรวมตัวเลขเหล่านั้นได้อย่างไร
เรากำลังสำรวจและประเมินตัวเลือกต่างๆ เรายินดีรับฟังความคิดเห็นเกี่ยวกับการรวบรวมนี้
ทางเลือกหนึ่งคือการกำหนดงบประมาณสำหรับเวลาในการตอบสนองของการโต้ตอบ ซึ่งอาจขึ้นอยู่กับประเภท (การเลื่อน แป้นพิมพ์ แตะ หรือลาก) ตัวอย่างเช่น ถ้างบประมาณสำหรับการแตะคือ 100 มิลลิวินาที และเวลาในการตอบสนองของการแตะคือ 150 มิลลิวินาที จำนวนเงินที่เกินงบประมาณสำหรับการโต้ตอบนั้นจะเป็น 50 มิลลิวินาที จากนั้นเราจะคำนวณเวลาในการตอบสนองสูงสุดที่เกินงบประมาณสำหรับการโต้ตอบของผู้ใช้ในหน้าเว็บ
อีกทางเลือกหนึ่งคือการคำนวณเวลาในการตอบสนองเฉลี่ยหรือค่ามัธยฐานของการโต้ตอบตลอดอายุการใช้งานหน้าเว็บ ดังนั้นหากเวลาในการตอบสนองอยู่ที่ 80, 90 มิลลิวินาที และ 100 มิลลิวินาที เวลาในการตอบสนองโดยเฉลี่ยของหน้าเว็บก็จะเท่ากับ 90 มิลลิวินาที เราอาจพิจารณาค่าเฉลี่ยหรือค่���มัธยฐานของ "เกินงบประมาณ" เพื่ออธิบายความคาดหวังที่แตกต่างกัน โดยขึ้นอยู่กับประเภทของการโต้ตอบ
การดำเนินการนี้มีลักษณะอย่างไรใน API ประสิทธิภาพเว็บ
ตรงไหนในระยะเวลาของเหตุการณ์
แต่น่าเสียดายที่ Content Timing API จะไม่บันทึกแนวคิดทั้งหมดที่แสดงในโพสต์นี้ โดยเฉพาะอย่างยิ่ง ไม่มีวิธีง่ายๆ ที่จะทราบเหตุการณ์ที่เชื่อมโยงกับการโต้ตอบของผู้ใช้หนึ่งๆ กับ API ซึ่งเราได้เสนอให้เพิ่ม interactionID
ใน API แล้ว
ข้อบกพร่องอีกอย่างหนึ่งของ Event Timing API คือไม่มีวิธีวัดการโต้ตอบการเลื่อน เราจึงพยายามเปิดใช้การวัดผลเหล่านี้ (ผ่าน Event Timing หรือ API แยกต่างหาก)
สิ่งที่คุณทำได้ในตอนนี้
ในขณะนี้ คุณยังคำนวณเวลาในการตอบสนองสูงสุดสำหรับการแตะ/ลาก และการโต้ตอบของแป้นพิมพ์ได้ ข้อมูลโค้ดต่อไปนี้จะสร้างเมตริก 2 รายการนี้
let maxTapOrDragDuration = 0;
let maxKeyboardDuration = 0;
const observer = new PerformanceObserver(list => {
list.getEntries().forEach(entry => {
switch(entry.name) {
case "keydown":
case "keyup":
maxKeyboardDuration = Math.max(maxKeyboardDuration,
entry.duration);
break;
case "pointerdown":
case "pointerup":
case "click":
maxTapOrDragDuration = Math.max(maxTapOrDragDuration,
entry.duration);
break;
}
});
});
observer.observe({type: "event", durationThreshold: 16, buffered: true});
// We can report maxTapDragDuration and maxKeyboardDuration when sending
// metrics to analytics.
ความคิดเห็น
บอกให้เราทราบว่าคุณคิดอย่างไรเกี่ยวกับแนวคิดเหล่านี้ทางอีเมล: web-vitals-feedback@googlegroups.com