วินิจฉัยการโต้ตอบที่ช้าในห้องทดลองด้วยตนเอง

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

Jeremy Wagner

เผยแพร่: 9 พฤษภาคม 2023

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

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

จะเกิดอะไรขึ้นหากคุณไม่มีข้อมูลภาคสนาม

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

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

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

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

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

จำลองการโต้ตอบที่ช้าในห้องทดลอง

คุณจำลองการโต้ตอบที่ช้าในห้องทดลองผ่านการทดสอบด้วยตนเองได้หลายวิธี แต่ด้านล่างนี้คือเฟรมเวิร์กที่คุณลองใช้ได้

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

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

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

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

บันทึกการติดตาม

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

1. เปิดหน้าที่ต้องการทดสอบ
2. เปิดเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome แล้วไปที่แผงประสิทธิภาพ
3. คลิกปุ่มบันทึกที่ด้านซ้ายบนของแผงเพื่อเริ่มการติดตาม
4. ทําการโต้ตอบที่คุณต้องการแก้ปัญหา
5. คลิกปุ่มบันทึกอีกครั้งเพื่อหยุดติดตาม

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

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

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

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

ส่วนที่เป็นแถบของเวลาในการโต้ตอบแสดงระยะเวลาของการโต้ตอบที่เกิน 200 มิลลิวินาที ซึ่งเป็นขีดจํากัดบนของเกณฑ์ "ดี" สําหรับ INP ของหน้าเว็บ ส่วนของการโต้ตอบที่แสดง ได้แก่

1. ความล่าช้าของอินพุต ซึ่งแสดงเป็นเส้นขนแปรงด้านซ้าย
2. ระยะเวลาการประมวลผล ซึ่งจะแสดงเป็นแถบทึบระหว่างเส้นมวยซ้ายและขวา
3. การเลื่อนเวลาของข้อมูลที่แสดงด้วยเส้นขนแปรงด้านขวา

จากตรงนี้ คุณต้องเจาะลึกปัญหาที่ทําให้การโต้ตอบช้าลง ซึ่งจะอธิบายในคู่มือนี้ในภายหลัง

วิธีระบุว่าการโต้ตอบส่วนใดที่ช้า

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

วิธีระบุความล่าช้าของอินพุตยาว

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

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

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

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

วิธีระบุระยะเวลาการประมวลผลที่ยาวนาน

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

การค้นหา Callback ของเหตุการณ์ที่มีค่าใช้จ่ายสูงสามารถทำได้โดยสังเกตสิ่งต่อไปนี้ในการติดตามสำหรับการโต้ตอบที่เฉพาะเจาะจง

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

คุณลองใช้กลยุทธ์อย่างใดอย่างหนึ่งต่อไปนี้เพื่อลดระยะเวลาการประมวลผลของการโต้ตอบได้

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

กลยุทธ์เหล่านี้ควรช่วยเพิ่มประสิทธิภาพการเรียกกลับเหตุการณ์เพื่อให้ใช้เวลาในการเรียกใช้น้อยลง

วิธีระบุความล่าช้าในการนำเสนอ

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

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

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

• DOM ที่มีขนาดใหญ่ งานแสดงผลที่จําเป็นในการอัปเดตการแสดงผลของหน้าเว็บมักจะเพิ่มขึ้นตามขนาดของ DOM ของหน้า ดูข้อมูลเพิ่มเติมได้ที่ขนาด DOM ที่ใหญ่ส่งผลต่อการโต้ตอบอย่างไร และคุณทําอะไรได้บ้าง
• การบังคับให้จัดเรียงใหม่ ซึ่งจะเกิดขึ้นเมื่อคุณนำการเปลี่ยนแปลงรูปแบบไปใช้กับองค์ประกอบใน JavaScript แล้วค้นหาผลลัพธ์ของงานดังกล่าวทันที ผลที่ได้คือเบราว์เซอร์ต้องทำงานด้านเลย์เอาต์ก่อนที่จะทำอย่างอื่น เพื่อที่เบราว์เซอร์จะได้แสดงสไตล์ที่อัปเดตใหม่ ดูข้อมูลเพิ่มเติมและเคล็ดลับในการหลีกเลี่ยงการจัดเรียงใหม่แบบบังคับได้ที่หลีกเลี่ยงเลย์เอาต์ขนาดใหญ่ที่ซับซ้อนและการจัดเรียงที่เปลี่ยนแปลงบ่อย
• การทํางานที่ไม่จําเป็นหรือมากเกินไปใน requestAnimationFrame callbacks requestAnimationFrame() ระบบจะเรียกใช้การเรียกกลับระหว่างระยะการแสดงผลของลูปเหตุการณ์ และต้องดำเนินการให้เสร็จสมบูรณ์ก่อนจึงจะแสดงเฟรมถัดไปได้ หากคุณใช้ requestAnimationFrame() ในการทำงานที่ไม่เกี่ยวข้องกับการเปลี่ยนแปลงอินเทอร์เฟซผู้ใช้ โปรดทราบว่าคุณอาจทำให้เฟรมถัดไปล่าช้า
• ResizeObserver callbacks Callback ดังกล่าวจะทำงานก่อนการแสดงผล และอาจทำให้การนำเสนอเฟรมถัดไปล่าช้าหากงานในเฟรมดังกล่าวมีราคาแพง เช่นเดียวกับการเรียกกลับเหตุการณ์ ให้เลื่อนตรรกะที่ไม่จำเป็นสำหรับเฟรมถัดไป

จะเกิดอะไรขึ้นหากทำซ้ำการโต้ตอบที่ช้าไม่ได้

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

1. หากมีอุปกรณ์ Android จริง ให้ใช้การแก้ไขข้อบกพร่องระยะไกลเพื่อเปิดอินสแตนซ์เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome บนเครื่องโฮสต์ แล้วลองทําให้เกิดปัญหาการโต้ตอบที่ช้าขึ้นอีกครั้ง อุปกรณ์เคลื่อนที่มักจะทำงานช้ากว่าแล็ปท็อปหรือเดสก์ท็อป คุณจึงอาจสังเกตเห็นการโต้ตอบที่ช้าในอุปกรณ์เหล่านี้ได้ง่ายกว่า
2. หากคุณไม่มีอุปกรณ์จริง ให้เปิดใช้ฟีเจอร์การควบคุม CPU ในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
3. อาจเป็นไปได้ว่าคุณกำลังรอให้หน้าเว็บโหลดก่อนที่ผู้ใช้โต้ตอบกับหน้าเว็บ แต่ผู้ใช้ไม่ได้กดอยู่ หากคุณใช้เครือข่ายที่รวดเร็ว ให้จำลองสภาวะเครือข่ายที่ช้าลงโดยเปิดใช้การควบคุมเครือข่าย จากนั้นโต้ตอบกับหน้าเว็บทันทีที่แสดงผล คุณควรทำเช่นนี้เนื่องจากชุดข้อความหลักมักจะยุ่งที่สุดในช่วงเริ่มต้น และการทดสอบในช่วงเวลาดังกล่าวอาจแสดงให้เห็นสิ่งที่ผู้ใช้พบ

การแก้ปัญหา INP เป็นกระบวนการที่ต้องทำซ้ำ

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

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

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