มุ่งสู่เมตริกการตอบสนองที่ดีขึ้น

เรียนรู้เกี่ยวกับความคิดของเราเกี่ยวกับการวัดการตอบสนองและแสดงความคิดเห็น

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

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

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

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 ไม่ได้เน้นผู้ใช้เป็นหลักทำให้ตัวเลือกที่ไม่รัดกุมเหล่านี้ลดลง

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

เรากําลังพิจารณาการปรับปรุงอะไรบ้าง

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

เราต้องการให้เมตริกใหม่ทำงานต่อไปนี้

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

ในการที่จะประสบความสำเร็จ เราควรสามารถบอกได้อย่างมั่นใจว่าหากเว็บไซต์ได้คะแนนต่ำสำหรับเมตริกใหม่นี้ เว็บไซต์ตอบสนองการโต้ตอบของผู้ใช้ได้ไม่ดีนัก

บันทึกระยะเวลาของเหตุการณ์ทั้งหมด

การปรับปรุงที่ชัดเจนอย่างแรกคือการพยายามตรวจจับเวลาในการตอบสนองจากต้นทางถึงปลายทางให้กว้างขึ้น ตามที่กล่าวไว้ข้างต้น FID จะบันทึกเฉพาะส่วนที่ล่าช้าของเหตุการณ์อินพุตเท่านั้น แต่ไม่ได้พิจารณาถึงเวลาที่เบราว์เซอร์ใช้ในการประมวลผลตัวแฮนเดิลเหตุการณ์

วงจรเหตุการณ์มีอยู่หลายขั้นตอน ดังที่แสดงในแผนภาพนี้

โดย Chrome จะประมวลผลอินพุตดังนี้

1. ข้อมูลจากผู้ใช้จะปรากฏขึ้น เวลาที่เหตุการณ์นี้เกิดขึ้นคือ timeStamp ของกิจกรรม
2. เบราว์เซอร์จะทำการทดสอบ Hit เพื่อเลือกเฟรม HTML (เฟรมหลักหรือ iframe บางรายการ) ของเหตุการณ์ จากนั้นเบราว์เซอร์จะส่งเหตุการณ์ไปยังกระบวนการแสดงผลที่เหมาะสมซึ่งรับผิดชอบเฟรม HTML นั้น
3. โหมดแสดงภาพจะรับเหตุการณ์และจัดคิวเพื่อให้ประมวลผลได้เมื่อพร้อม
4. ตัวแสดงผลจะประมวลผลเหตุการณ์โดยการเรียกใช้เครื่องจัดการ เครื่องจัดการเหล่านี้อาจจัดคิวงานที่ไม่พร้อมกันเพิ่มเติม เช่น setTimeout และการดึงข้อมูล ซึ่งเป็นส่วนหนึ่งของการจัดการอินพุต แต่ในจุดนี้ งานพร้อมกันเสร็จสมบูรณ์แล้ว
5. มีการกำหนดเฟรมลงในหน้าจอที่สะท้อนถึงผลลัพธ์ของตัวแฮนเดิลเหตุการณ์ที่ทำงานอยู่ โปรดทราบว่างานแบบไม่พร้อมกันที่อยู่ในคิวโดยตัวแฮนเดิลเหตุการณ์อาจยังดำเนินการไม่เสร็จ

เวลาระหว่างขั้นตอน (1) ถึง (3) ด้านบนคือความล่าช้าของเหตุการณ์ ซึ่งเป็นสิ่งที่ FID วัด

เวลาระหว่างขั้นตอน (1) ถึง (5) ด้านบนคือระยะเวลาของเหตุการณ์ นี่คือสิ่งที่เมตริกใหม่ของเรา จะใช้วัด

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

จัดกลุ่มเหตุการณ์เป็นการโต้ตอบ

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

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

ประเภทการโต้ตอบ

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

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

แป้นพิมพ์

การโต้ตอบกับแป้นพิมพ์นั้นแบ่งออกเป็น 2 ส่วน ได้แก่ เมื่อผู้ใช้กดแป้นและเมื่อปล่อยมือ การโต้ตอบของผู้ใช้นี้มี 3 เหตุการณ์ ได้แก่ keydown, keyup และ keypress แผนภาพต่อไปนี้แสดงการหน่วงเวลาและระยะเวลาของ keydown และ keyup สำหรับการโต้ตอบกับแป้นพิมพ์

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

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

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

แตะ

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

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

เราต้องการรวมระยะเวลาของเหตุการณ์เหล่านี้ทั้งหมด แต่หลายเหตุการณ์ทับซ้อนกันอย่างมาก เราจึงต้องวัดเพียง 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 ข้อต่อไปนี้

1. เราพยายามรวบรวมตัวเลขใดบ้าง
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