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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

วิธีระบุการหน่วงเวลาการป้อนข้อมูลนาน

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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