ดูวิธีนําข้อมูลภาคสนามไปไว้ในห้องทดลองเพื่อสร้างปัญหาให้เกิดขึ้นอีกครั้งและระบุสาเหตุที่ทําให้การโต้ตอบช้าผ่านการทดสอบด้วยตนเอง
เผยแพร่: 9 พฤษภาคม 2023
สิ่งที่ทําให้การเพิ่มประสิทธิภาพ Interaction to Next Paint (INP) เป็นเรื่องยากคือการหาสาเหตุที่ทําให้ INP ไม่ดี สาเหตุที่เป็นไปได้มีมากมาย เช่น สคริปต์ของบุคคลที่สามที่กำหนดเวลางานหลายรายการในเธรดหลัก DOM ขนาดใหญ่ การเรียกกลับเหตุการณ์ที่มีค่าใช้จ่ายสูง และสาเหตุอื่นๆ
การปรับปรุง INP อาจเป็นเรื่องยาก ในการเริ่มต้น คุณต้องทราบว่าการโต้ตอบใดมีแนวโน้มที่จะทำให้เกิด INP ของหน้าเว็บ หากไม่ทราบว่าการโต้ตอบใดในเว็บไซต์มีแนวโน้มที่จะช้าที่สุดจากมุมมองของผู้ใช้จริง โปรดอ่านค้นหาการโต้ตอบที่ช้าในสนาม เมื่อคุณมีข้อมูลภาคสนามเป็นแนวทางแล้ว คุณสามารถทดสอบการโต้ตอบที่เฉพาะเจาะจงเหล่านั้นด้วยตนเองในเครื่องมือทดสอบเพื่อหาสาเหตุที่การโต้ตอบเหล่านั้นช้า
จะเกิดอะไรขึ้นหากคุณไม่มีข้อมูลภาคสนาม
การมีข้อมูลภาคสนามเป็นสิ่งสําคัญ เนื่องจากจะช่วยประหยัดเวลาได้มากในการพยายามหาการโต้ตอบที่ต้องเพิ่มประสิทธิภาพ อย่างไรก็ตาม คุณอาจอยู่ในตำแหน่งที่ไม่มีข้อมูลภาคสนาม หากเป็นเช่นนั้น คุณก็ยังคงค้นหาการโต้ตอบเพื่อปรับปรุงได้ แม้ว่าจะต้องใช้ความพยายามมากขึ้นและใช้แนวทางอื่น
เวลาในการบล็อกทั้งหมด (TBT) คือเมตริกในเวอร์ชันทดลองที่ประเมินการตอบสนองของหน้าเว็บระหว่างการโหลด และมีความเกี่ยวข้องอย่างมากกับ INP หากหน้าเว็บมี TBT สูง อาจเป็นสัญญาณว่าหน้าเว็บอาจตอบสนองต่อการโต้ตอบของผู้ใช้ขณะโหลดหน้าเว็บได้ไม่ดีนัก
หากต้องการทราบ TBT ของหน้าเว็บ คุณสามารถใช้ Lighthouse หาก TBT ของหน้าเว็บสูง แสดงว่าอาจมีบางสิ่งทำให้เธรดหลักทำงานหนักเกินไปในระหว่างการโหลดหน้าเว็บ ซึ่งอาจส่งผลต่อความสามารถในการตอบสนองของหน้าเว็บในช่วงเวลาสําคัญในวงจรชีวิตของหน้าเว็บ
หากต้องการค้นหาการโต้ตอบที่ช้าหลังจากโหลดหน้าเว็บแล้ว คุณอาจต้องใช้ข้อมูลประเภทอื่นๆ เช่น เส้นทางที่พบบ่อยของผู้ใช้ซึ่งคุณอาจระบุไว้ในข้อมูลวิเคราะห์ของเว็บไซต์แล้ว ตัวอย่างเช่น หากคุณทํางานในเว็บไซต์อีคอมเมิร์ซ โฟลว์ผู้ใช้ทั่วไปอาจเป็นการดําเนินการที่ผู้ใช้ทําเมื่อเพิ่มสินค้าลงในรถเข็นช็อปปิ้งออนไลน์และชําระเงิน
ไม่ว่าคุณจะมีพารามิเตอร์ที่ได้จากผู้ใช้จริงหรือไม่ ขั้นตอนถัดไปคือการทดสอบและทําให้เกิดปัญหาการโต้ตอบที่ช้าด้วยตนเอง เนื่องจากคุณจะแก้ไขปัญหาได้ก็ต่อเมื่อทําให้เกิดปัญหาการโต้ตอบที่ช้าซ้ำได้
จำลองการโต้ตอบที่ช้าในห้องทดลอง
คุณจำลองการโต้ตอบที่ช้าในห้องทดลองผ่านการทดสอบด้วยตนเองได้หลายวิธี แต่ด้านล่างนี้เป็นเฟรมเวิร์กที่คุณลองใช้ได้
เมตริกแบบเรียลไทม์ของแผงประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บ
เราขอแนะนําให้ใช้เครื่องมือวิเคราะห์ประสิทธิภาพของ DevTools เพื่อวินิจฉัยการโต้ตอบที่ทราบว่าช้า แต่อาจใช้เวลาในการระบุการโต้ตอบที่ช้าเมื่อคุณไม่ทราบว่าการโต้ตอบใดเป็นปัญหา
เมื่อเปิดแผงประสิทธิภาพเป็นครั้งแรก คุณจะเห็นมุมมองเมตริกแบบเรียลไทม์ ซึ่งสามารถใช้เพื่อลองการโต้ตอบหลายรายการอย่างรวดเร็วเพื่อค้นหารายการที่มีปัญหา ก่อนที่จะเปลี่ยนไปใช้เครื่องมือวิเคราะห์ประสิทธิภาพที่ละเอียดยิ่งขึ้น ขณะที่คุณโต้ตอบ ข้อมูลการวินิจฉัยจะปรากฏในบันทึกการโต้ตอบ (โดยไฮไลต์การโต้ตอบ INP) คุณสามารถขยายการโต้ตอบเหล่านี้เพื่อดูรายละเอียดของระยะต่างๆ ได้