เรียนรู้วิธีนำข้อมูลภาคสนามของคุณไปไว้ในห้องทดลองเพื่อทำซ้ำและระบุสาเหตุที่ทำให้เกิดการโต้ตอบช้าผ่านการทดสอบด้วยตนเอง
ส่วนที่ท้าทายในการเพิ่มประสิทธิภาพ Interaction to Next Paint (INP) คือการค้นหาสาเหตุที่ทำให้ INP ไม่ดี มีหลายสาเหตุที่เป็นไปได้ เช่น สคริปต์ของบุคคลที่สามที่ตั้งเวลางานหลายอย่างในเทรดหลัก, ขนาด DOM ขนาดใหญ่, Callback ของเหตุการณ์ราคาแพง และสาเหตุอื่นๆ
การปรับปรุง INP อาจเป็นเรื่องยาก ในการเริ่มต้น คุณต้องทราบว่าการโต้ตอบใดมีแนวโน้มที่จะส่งผลต่อ INP ของหน้าเว็บ หากไม่ทราบว่าการโต้ตอบใดในเว็บไซต์ที่มีแนวโน้มจะช้าที่สุดจากมุมมองของผู้ใช้จริง โปรดอ่านหัวข้อค้นหาการโต้ตอบที่ช้าในฟิลด์นี้ เมื่อมีข้อมูลภาคสนามแล้ว คุณสามารถทดสอบการโต้ตอบที่เฉพาะเจาะจงเหล่านั้นด้วยตนเองในเครื่องมือห้องทดลองเพื่อค้นหาสาเหตุที่ทำให้การโต้ตอบเหล่านั้นล่าช้า
หากคุณไม่มีข้อมูลภาคสนาม
การมีข้อมูลภาคสนามมีความสำคัญอย่างยิ่ง เนื่องจากจะทำให้คุณประหยัดเวลาในการค้นหาว่าการโต้ตอบใดบ้างที่ต้องเพิ่มประสิทธิภาพ อย่างไรก็ตาม คุณอาจอยู่ในตำแหน่งที่ไม่มีข้อมูลฟิลด์ หากเหตุการณ์นั้นตรงกับสถานการณ์ของคุณ ก็มีความเป็นไปได้ที่การโต้ตอบนั้นจะปรับปรุงให้ดีขึ้นได้ แม้ว่าจะต้องใช้ความพยายามมากขึ้นและใช้วิธีอื่นก็ตาม
Total Block Time (TBT) เป็นเมตริกของห้องทดลองที่ประเมินการตอบสนองของหน้าเว็บระหว่างการโหลด และสัมพันธ์กับ INP ได้ดี หากหน้าเว็บมี TBT สูง นั่นอาจเป็นสัญญาณว่าหน้าเว็บอาจไม่ได้ตอบสนองต่อการโต้ตอบของผู้ใช้มากนักเมื่อโหลดหน้าเว็บ
หากต้องการกำหนด TBT ของหน้าเว็บ ให้ใช้ Lighthouse หาก TBT ของหน้าเว็บสูง มีโอกาสที่เทรดหลักจะทำงานมากเกินไประหว่างการโหลดหน้าเว็บและส่งผลต่อการตอบสนองของหน้าเว็บในระหว่างช่วงเวลาที่สำคัญในวงจรของหน้า
หากต้องการค้นหาการโต้ตอบที่ช้าหลังจากหน้าเว็บโหลดแล้ว คุณอาจต้องใช้ข้อมูลประเภทอื่นๆ เช่น การไหลเวียนของผู้ใช้ทั่วไปที่คุณอาจระบุแล้วใน Analytics ของเว็บไซต์ ตัวอย่างเช่น หากคุณทำงานในเว็บไซต์อีคอมเมิร์ซ ขั้นตอนทั่วไปของผู้ใช้จะเป็นการกระทำที่ผู้ใช้ทำเมื่อเพิ่มสินค้าลงในรถเข็นช็อปปิ้งออนไลน์และชำระเงิน
ไม่ว่าจะมีข้อมูลภาคสนามหรือไม่ ขั้นตอนต่อไปคือการทดสอบและทำให้เกิดการโต้ตอบช้าด้วยตนเอง เนื่องจากคุณสามารถแก้ไขการโต้ตอบที่ช้าได้ก็ต่อเมื่อคุณสร้างการโต้ตอบที่ช้าเท่านั้น
จำลองการโต้ตอบที่ช้าในห้องทดลอง
คุณสามารถทำซ้ำการโต้ตอบช้าในห้องทดลองผ่านการทดสอบด้วยตนเองได้หลายวิธี แต่คุณสามารถลองใช้เฟรมเวิร์กนี้ได้
บันทึกการติดตาม
เครื่องมือสร้างโปรไฟล์ประสิทธิภาพของ Chrome เป็นเครื่องมือที่แนะนำสำหรับการวินิจฉัยและแก้ปัญหาการโต้ตอบช้า หากต้องการสร้างโปรไฟล์การโต้ตอบในเครื่องมือสร้างโปรไฟล์ประสิทธิภาพของ Chrome ให้ทำตามขั้นตอนต่อไปนี้
- เปิดหน้าที่ต้องการทดสอบ
- เปิดเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome แล้วไปที่แผงประสิทธิภาพ
- คลิกปุ่มบันทึกที่ด้านซ้ายบนของแผงเพื่อเริ่มการติดตาม
- ทําการโต้ตอบที่คุณต้องการแก้ปัญหา
- คลิกปุ่มบันทึกอีกครั้งเพื่อหยุดติดตาม
เมื่อป้อนข้อมูลเครื่องมือสร้างโปรไฟล์ สิ่งแรกที่ควรดูคือสรุปกิจกรรมที่อยู่ด้านบนของเครื่องมือสร้างโปรไฟล์ สรุปกิจกรรมจะแสดงแถบสีแดงที่ด้านบนบริเวณที่มีงานที่ใช้เวลานานในการบันทึก ซึ่งจะช่วยให้คุณซูมเข้าในพื้นที่ที่เกิดปัญหาได้อย่างรวดเร็ว
![สรุปกิจกรรมตามที่ปรากฏในบริเวณด้านบนของแผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome กิจกรรมที่แสดงส่วนใหญ่มาจาก JavaScript ที่ทำให้เกิดงานที่ใช้เวลานาน ซึ่งจะมีการไฮไลต์เป็นสีแดงเหนือแผนภูมิ Flame Chart](https://web.dev/static/articles/manually-diagnose-slow-interactions-in-the-lab/image/a-screenshot-the-activit-2f86d26e58372.png?authuser=6&hl=th)
คุณสามารถโฟกัสบริเวณที่เป็นปัญหาได้อย่างรวดเร็วด้วยการลากและเลือกพื้นที่ในสรุปกิจกรรม คุณสามารถเลือกใช้ฟีเจอร์เบรดครัมบ์ในเครื่องมือสร้างโปรไฟล์เพื่อช่วยจำกัดไทม์ไลน์ให้แคบลงและละเว้นกิจกรรมที่ไม่เกี่ยวข้องได้
เมื่อคุณโฟกัสที่ตำแหน่งที่การโต้ตอบเกิดขึ้น แทร็กการโต้ตอบจะช่วยให้คุณจัดการโต้ตอบและกิจกรรมที่เกิดขึ้นในแทร็กชุดข้อความหลักด้านล่าง
![การโต้ตอบดังที่แสดงในแผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome แทร็กการโต้ตอบเหนือแทร็กเทรดหลักแสดงระยะเวลาของการโต้ตอบ ซึ่งสามารถสอดคล้องกับกิจกรรมเทรดหลักที่ด้านล่าง](https://web.dev/static/articles/manually-diagnose-slow-interactions-in-the-lab/image/devtools-interaction.png?authuser=6&hl=th)
คุณสามารถดูรายละเอียดเพิ่มเติมว่าการโต้ตอบส่วนใดนานที่สุดได้โดยการวางเมาส์เหนือการทำซ้ำในแทร็กการโต้ตอบ ดังนี้
![เคล็ดลับเครื่องมือแบบวางเมาส์เหนือสำหรับการโต้ตอบที่แสดงในแผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome เคล็ดลับเครื่องมือจะแสดงระยะเวลาที่ใช้ในการโต้ตอบและส่วน ซึ่งรวมถึงความล่าช้าในการป้อนข้อมูลของการโต้ตอบ ระยะเวลาการประมวลผล และความล่าช้าในการนำเสนอ](https://web.dev/static/articles/manually-diagnose-slow-interactions-in-the-lab/image/devtools-whiskers.png?authuser=6&hl=th)
ส่วนที่เป็นลายเส้นของการโต้ตอบหมายถึงเวลาของการโต้ตอบที่เกิน 200 มิลลิวินาที ซึ่งเป็นขีดจำกัดสูงสุดของ "ดี" เกณฑ์สำหรับ INP ของหน้าเว็บ การโต้ตอบที่ปรากฏเป็นส่วนๆ ได้แก่
- ความล่าช้าของอินพุต ซึ่งดูได้จากเส้นเชือกด้านซ้าย
- ระยะเวลาการประมวลผล ซึ่งจะแสดงเป็นแถบทึบระหว่างเส้นมวยซ้ายและขวา
- ความล่าช้าในการนำเสนอ - แสดงภาพโดยมือขวา
หลังจากนี้ เราจะเจาะลึกปัญหาต่างๆ ที่เป็นสาเหตุให้เกิดการโต้ตอบช้า ซึ่งจะกล่าวถึงในภายหลังในคู่มือนี้
ส่วนขยาย Web Vitals ใน Chrome
เครื่องมือสร้างโปรไฟล์ประสิทธิภาพเป็นวิธีที่แนะนำในการวิเคราะห์การโต้ตอบที่ทราบว่าทำงานช้า แต่ก็อาจใช้เวลาสักระยะในการระบุการโต้ตอบที่ช้าเมื่อคุณไม่ทราบว่าการโต้ตอบใดเป็นการโต้ตอบที่เป็นปัญหา วิธีหนึ่งที่ควรพิจารณาคือการใช้ส่วนขยาย Web Vitals ใน Chrome คุณสามารถใช้ส่วนขยายนี้เพื่อลองใช้การโต้ตอบต่างๆ เพื่อค้นหาปัญหาที่เป็นปัญหาก่อนที่คุณจะเปลี่ยนไปใช้เครื่องมือสร้างโปรไฟล์ประสิทธิภาพ
เมื่อติดตั้งแล้ว ส่วนขยาย Web Vitals จะแสดงข้อมูลการโต้ตอบในคอนโซลเครื่องมือสำหรับนักพัฒนาเว็บหากคุณทำตามขั้นตอนต่อไปนี้
- ใน Chrome ให้คลิกไอคอนส่วนขยายทางด้านขวาของแถบที่อยู่
- ค้นหาส่วนขยาย Web Vitals ในเมนูแบบเลื่อนลง
- คลิกไอคอนทางด้านขวาเพื่อเปิดการตั้งค่าของส่วนขยาย
- คลิกตัวเลือก
- เปิดใช้ช่องทำเครื่องหมายการบันทึก Console ในหน้าจอผลลัพธ์ แล้วคลิกบันทึก
หลังจากทำตามขั้นตอนเหล่านี้แล้ว ให้เปิดคอนโซลในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome และเริ่มต้นทดสอบการโต้ตอบที่น่าสงสัยในหน้าเว็บ เมื่อคุณโต้ตอบ ข้อมูลการวินิจฉัยจะปรากฏในคอนโซล
![ลักษณะที่บันทึกสำหรับ INP จากส่วนขยาย Web Vitals จะปรากฏในคอนโซลสำหรับเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome มีข้อมูลการบันทึกโดยละเอียด ซึ่งรวมถึงส่วนของการโต้ตอบที่ใช้เวลานานที่สุด ตลอดจนข้อมูลการระบุแหล่งที่มาโดยละเอียดจาก API ประสิทธิภาพต่างๆ](https://web.dev/static/articles/manually-diagnose-slow-interactions-in-the-lab/image/web-vitals-console.png?authuser=6&hl=th)
แม้ว่าส่วนขยาย Web Vitals จะช่วยระบุการโต้ตอบที่ช้า และให้รายละเอียดบางอย่างเพื่อช่วยแก้ไขข้อบกพร่องของ INP แต่คุณยังคงต้องใช้เครื่องมือสร้างโปรไฟล์ประสิทธิภาพเพื่อวิเคราะห์การโต้ตอบที่ช้า เพราะมีข้อมูลโดยละเอียดที่คุณจำเป็นต้องใช้ในการไปยังส่วนต่างๆ ในโค้ดที่ใช้งานจริงของเว็บไซต์เพื่อหาสาเหตุของการโต้ตอบที่ช้า
วิธีระบุว่าการโต้ตอบส่วนใดที่ช้า
การโต้ตอบประกอบด้วย 3 ส่วน ได้แก่ ความล่าช้าของอินพุต ระยะเวลาในการประมวลผล และความล่าช้าในการนำเสนอ วิธีเพิ่มประสิทธิภาพการโต้ตอบเพื่อลด INP ของหน้าเว็บจะขึ้นอยู่กับว่าส่วนไหนใช้เวลามากที่สุด
วิธีระบุความล่าช้าของอินพุตยาว
ความล่าช้าของอินพุตอาจทำให้เวลาในการตอบสนองของการโต้ตอบสูง ความล่าช้าของอินพุตคือส่วนแรกของการโต้ตอบ นี่คือระยะเวลาตั้งแต่ที่ระบบปฏิบัติการได้รับการดำเนินการของผู้ใช้เป็นครั้งแรกจนถึงเวลาที่เบราว์เซอร์เริ่มประมวลผล Callback ของตัวแฮนเดิลเหตุการณ์แรกของการโต้ตอบนั้นได้
การระบุความล่าช้าของอินพุตในเครื่องมือสร้างโปรไฟล์ประสิทธิภาพของ Chrome ทำได้โดยการค้นหาการโต้ตอบในแทร็กการโต้ตอบ ความยาวของเส้นด้ายซ้ายแสดงถึงส่วนของความล่าช้าในการป้อนข้อมูลของการโต้ตอบ และดูค่าที่แม่นยำได้จากเคล็ดลับเครื่องมือด้วยการวางเมาส์เหนือการโต้ตอบในเครื่องมือสร้างโปรไฟล์ประสิทธิภาพ
ความล่าช้าของอินพุตไม่สามารถเป็น 0 ได้ แต่คุณสามารถควบคุมระยะเวลาระยะเวลาของอินพุตได้ สิ่งสำคัญคือการตรวจสอบว่ามีงานที่ยังทำงานอยู่ในเทรดหลักที่ทำให้ Callback ทำงานทันทีที่ควรจะเป็นหรือไม่
![การหน่วงเวลาการป้อนข้อมูลดังที่แสดงในแผงประสิทธิภาพของ Chrome การเริ่มต้นการโต้ตอบเกิดขึ้นก่อนการเรียกกลับของเหตุการณ์ เนื่องจากความล่าช้าของอินพุตเพิ่มขึ้นเนื่องจากตัวจับเวลาที่เริ่มทํางานจากสคริปต์ของบุคคลที่สาม](https://web.dev/static/articles/manually-diagnose-slow-interactions-in-the-lab/image/input-delay.png?authuser=6&hl=th)
ในรูปก่อนหน้านี้ งานจากสคริปต์ของบุคคลที่สามกำลังทำงานอยู่ในขณะที่ผู้ใช้พยายามโต้ตอบกับหน้าเว็บ ทำให้อินพุตยิ่งล่าช้าออกไป ความล่าช้าของอินพุตที่เพิ่มขึ้นจะส่งผลต่อเวลาในการตอบสนองของการโต้ตอบ จึงอาจส่งผลต่อ INP ของหน้าเว็บ
วิธีระบุระยะเวลาการประมวลผลที่ยาวนาน
การเรียกกลับของเหตุการณ์จะทำงานทันทีหลังจากที่เกิดความล่าช้าในการอินพุต และเวลาที่ใช้ในการดำเนินการจะเรียกว่าระยะเวลาการประมวลผล หาก Callback ของเหตุการณ์ทำงานนานเกินไป จะทำให้เบราว์เซอร์แสดงเฟรมถัดไปล่าช้า และอาจทำให้เวลาในการตอบสนองรวมของการโต้ตอบเพิ่มขึ้นอย่างมาก ระยะเวลาการประมวลผลที่ยาวนานอาจเป็นผลมาจาก JavaScript ของบุคคลที่หนึ่งหรือบุคคลที่สามที่มีราคาแพงสำหรับการคำนวณ และในบางกรณีอาจมีทั้ง 2 อย่าง ในเครื่องมือสร้างโปรไฟล์ประสิทธิภาพ ข้อมูลนี้จะแสดงในส่วนการโต้ตอบที่สำคัญในแทร็กการโต้ตอบ
![ภาพงาน Callback ของเหตุการณ์ในแผงประสิทธิภาพของ Chrome เคล็ดลับเครื่องมือการวางเมาส์เหนือการโต้ตอบบนไทม์ไลน์จะแสดงระยะเวลาการประมวลผลที่นาน](https://web.dev/static/articles/manually-diagnose-slow-interactions-in-the-lab/image/processing-duration.png?authuser=6&hl=th)
การค้นหา Callback ของเหตุการณ์ที่มีค่าใช้จ่ายสูงสามารถทำได้โดยสังเกตสิ่งต่อไปนี้ในการติดตามสำหรับการโต้ตอบที่เฉพาะเจาะจง
- พิจารณาว่างานที่เชื่อมโยงกับ Callback ของเหตุการณ์เป็นงานที่ใช้เวลานานหรือไม่ หากต้องการให้แสดงงานที่ใช้เวลานานในการตั้งค่าห้องทดลองได้อย่างน่าเชื่อถือมากขึ้น คุณอาจต้องเปิดใช้การควบคุม CPU ในแผงประสิทธิภาพ หรือเชื่อมต่ออุปกรณ์ Android ตั้งแต่ระดับต่ำถึงระดับกลางและใช้การแก้ไขข้อบกพร่องระยะไกล
- หากงานที่เรียกใช้ Callback ของเหตุการณ์เป็นงานที่ใช้เวลานาน ให้มองหารายการตัวแฮนเดิลเหตุการณ์ เช่น รายการที่มีชื่อ เช่น Event: click ในสแต็กการเรียกใช้ที่มีสามเหลี่ยมสีแดงที่มุมขวาบนของรายการ
คุณสามารถลองใช้กลยุทธ์ต่อไปนี้เพื่อลดระยะเวลาการประมวลผลของการโต้ตอบได้
- ทำงานให้น้อยที่สุดเท่าที่จะทำได้ ทุกอย่างที่เกิดขึ้นในการเรียกกลับของเหตุการณ์ที่มีค่าใช้จ่ายสูงจำเป็นอย่างมากหรือไม่ หากไม่ ให้ลองนำโค้ดนั้นออกทั้งหมดหากเป็นไปได้ หรือเลื่อนการดำเนินการของโค้ดไปช่วงเวลาหนึ่งหากคุณทำไม่ได้ นอกจากนี้ คุณยังใช้ประโยชน์จากฟีเจอร์เฟรมเวิร์กได้ด้วย เช่น ฟีเจอร์การบันทึกของ React อาจข้ามการแสดงผลที่ไม่จำเป็นของคอมโพเนนต์เมื่อไม่มีการเปลี่ยนแปลงอุปกรณ์ประกอบฉาก
- เลื่อนงานที่ไม่มีการแสดงผลใน Callback ของเหตุการณ์ไปยังช่วงเวลาในภายหลัง แบ่งงานที่ใช้เวลานานออกได้โดยการตอบกลับเทรดหลัก เมื่อใดก็ตามที่คุณส่งไปยังเทรดหลัก จะเป็นการสิ้นสุดการดำเนินการงานปัจจุบันและแยกงานที่เหลือออกเป็นงานแยกต่างหาก วิธีนี้ช่วยให้ตัวแสดงผลมีโอกาสประมวลผลการอัปเดตอินเทอร์เฟซผู้ใช้ซึ่งดำเนินการก่อนหน้านี้ใน Callback ของเหตุการณ์ หากคุณใช้ React ให้ใช้ฟีเจอร์การเปลี่ยนของฟีเจอร์ดังกล่าว
กลยุทธ์เหล่านี้น่าจะช่วยเพิ่มประสิทธิภาพ Callback ของเหตุการณ์ได้ เพื่อให้ใช้เวลาในการเรียกใช้น้อยลง
วิธีระบุความล่าช้าของงานนำเสนอ
ความล่าช้าของอินพุตที่ใช้เวลานานและระยะเวลาในการประมวลผลไม่ใช่สาเหตุเดียวของ INP ที่ไม่ดี บางครั้งการอัปเดตการแสดงผลที่เกิดขึ้นเพื่อตอบสนองต่อโค้ด Callback ของเหตุการณ์แม้เพียงเล็กน้อยก็อาจมีค่าใช้จ่ายสูง เวลาที่เบราว์เซอร์ใช้ในการแสดงผลการอัปเดตภาพในอินเทอร์เฟซผู้ใช้เพื่อแสดงถึงผลของการโต้ตอบเรียกว่าความล่าช้าในการนำเสนอ
![การแสดงผลงานตามที่แสดงในแผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome การแสดงผลงานจะเกิดขึ้นหลังจากการเรียกกลับของเหตุการณ์เพื่อวาดภาพเฟรมถัดไป](https://web.dev/static/articles/manually-diagnose-slow-interactions-in-the-lab/image/presentation-delay.png?authuser=6&hl=th)
การแสดงภาพมักประกอบด้วยงานต่างๆ เช่น การคำนวณสไตล์ใหม่ เลย์เอาต์ การลงสี และการผสมองค์ประกอบ และแสดงเป็นบล็อกสีม่วงและเขียวในแผนภูมิแผนภูมิเปลวไฟของเครื่องมือสร้างโปรไฟล์ ความล่าช้าของการนำเสนอทั้งหมดจะแสดงด้วยเส้นขวาของการโต้ตอบในแทร็กการโต้ตอบ
ในบรรดาสาเหตุที่เป็นไปได้ทั้งหมดที่ทําให้เวลาในการตอบสนองของการโต้ตอบสูง การนําเสนอที่ล่าช้าอาจเป็นการแก้ปัญหาและแก้ไขได้ยากที่สุด การแสดงผลมากเกินไปอาจเกิดจากสาเหตุใดๆ ต่อไปนี้
- ขนาด DOM ขนาดใหญ่ งานการแสดงผลที่จำเป็นต่อการอัปเดตการนำเสนอของหน้าเว็บมักจะเพิ่มขึ้นตามขนาดของ DOM ของหน้าเว็บ อ่านข้อมูลเพิ่มเติมได้ที่หัวข้อขนาด DOM ที่มีขนาดใหญ่ส่งผลต่อการโต้ตอบและสิ่งที่คุณทำได้
- การบังคับให้จัดเรียงใหม่ ซึ่งจะเกิดขึ้นเมื่อคุณนำการเปลี่ยนแปลงรูปแบบไปใช้กับองค์ประกอบใน JavaScript แล้วค้นหาผลลัพธ์ของงานดังกล่าวทันที ผลที่ได้คือเบราว์เซอร์ต้องทำงานเลย์เอาต์ก่อนที่จะทำอย่างอื่น เพื่อที่เบราว์เซอร์จะได้แสดงสไตล์ที่อัปเดตใหม่ ดูข้อมูลเพิ่มเติมและเคล็ดลับเกี่ยวกับการหลีกเลี่ยงการบังคับให้จัดเรียงใหม่ได้จากบทความหลีกเลี่ยงเลย์เอาต์ขนาดใหญ่และซับซ้อน รวมถึงการสลับเลย์เอาต์
- งานมากเกินไปหรือไม่จำเป็นใน Callback ของ
requestAnimationFrame
requestAnimationFrame()
Callback จะทำงานในขั้นตอนการแสดงผลของลูปเหตุการณ์ และต้องเสร็จสมบูรณ์ก่อนที่จะแสดงเฟรมถัดไปได้ หากคุณใช้requestAnimationFrame()
เพื่อทำงานที่ไม่เกี่ยวข้องกับการเปลี่ยนแปลงอินเทอร์เฟซผู้ใช้ โปรดทราบว่าคุณอาจหน่วงเวลาเฟรมถัดไป - Callback ของ
ResizeObserver
Callback ดังกล่าวจะทำงานก่อนการแสดงผล และอาจทำให้การนำเสนอเฟรมถัดไปล่าช้าหากงานในเฟรมดังกล่าวมีราคาแพง เลื่อนลอจิกที่ไม่จำเป็นสำหรับเฟรมถัดไปออกไป เช่นเดียวกับ Callback ของเหตุการณ์
จะเกิดอะไรขึ้นหากคุณทำให้เกิดการโต้ตอบช้าไม่ได้
จะเกิดอะไรขึ้นหากข้อมูลภาคสนามของคุณชี้ให้เห็นว่าการโต้ตอบเกิดขึ้นช้า แต่คุณไม่สามารถทำให้เกิดปัญหาซ้ำในห้องทดลองได้ มีสาเหตุสองประการที่อาจทำให้เกิดปัญหานี้
ประการแรก สถานการณ์ขณะที่ทดสอบการโต้ตอบจะขึ้นอยู่กับฮาร์ดแวร์และการเชื่อมต่อเครือข่ายของคุณ คุณอาจใช้อุปกรณ์ที่ทำงานเร็วและมีการเชื่อมต่อที่รวดเร็ว แต่ไม่ได้หมายความว่าผู้ใช้จะยังใช้งานอยู่ คุณสามารถลองทำตาม 1 ใน 3 วิธีต่อไปนี้ หากกรณีนี้ตรงกับคุณ
- หากคุณมีอุปกรณ์ Android ที่เป็นอุปกรณ์จริง ให้ใช้การแก้ไขข้อบกพร่องระยะไกลเพื่อเปิดอินสแตนซ์ Chrome DevTools ในเครื่องโฮสต์และพยายามจำลองการโต้ตอบที่ช้า อุปกรณ์เคลื่อนที่มักยังไม่เร็วเท่ากับแล็ปท็อปหรือเครื่องเดสก์ท็อป ดังนั้นคุณจะเห็นการโต้ตอบที่ช้ามากกว่าบนอุปกรณ์เหล่านี้
- หากคุณไม่มีอุปกรณ์จริง ให้เปิดใช้ฟีเจอร์การควบคุม CPU ในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
อีกสาเหตุหนึ่งอาจเป็นเพราะคุณกําลังรอให้หน้าเว็บโหลดก่อนโต้ตอบกับหน้านั้น แต่ผู้ใช้ไม่ได้โหลด หากคุณใช้เครือข่ายที่รวดเร็ว ให้จำลองสภาพเครือข่ายที่ช้ากว่าด้วยการเปิดใช้การควบคุมเครือข่าย แล้วโต้ตอบกับหน้าเว็บทันทีที่แสดงผล คุณควรทำเช่นนี้เนื่องจากเทรดหลักมักจะมีการใช้งานมากที่สุดในช่วงเริ่มต้น และการทดสอบในช่วงเวลาดังกล่าวอาจเผยให้เห็นว่าผู้ใช้กำลังประสบปัญหาอะไรบ้าง
การแก้ปัญหา INP เป็นกระบวนการที่ต้องทำซ้ำ
การค้นหาสาเหตุของเวลาในการตอบสนองของการโต้ตอบที่สูงซึ่งก่อให้เกิด INP ที่ไม่ดีนั้นต้องใช้ความพยายามอย่างมาก แต่หากคุณสามารถหาสาเหตุได้ ก็ถือว่าคุณมาถึงครึ่งทางแล้ว การทำตามแนวทางที่เป็นระบบในการแก้ปัญหา INP ที่ด้อยประสิทธิภาพจะช่วยให้คุณระบุสิ่งที่ทำให้เกิดปัญหาได้อย่างถูกต้อง และให้แก้ไขปัญหาที่เหมาะสมได้เร็วขึ้น วิธีตรวจสอบมีดังนี้
- อาศัยข้อมูลภาคสนามเพื่อค้นหาการโต้ตอบที่ช้า
- ทดสอบการโต้ตอบในช่องที่เป็นปัญหาด้วยตนเองในห้องทดลองเพื่อดูว่าเกิดปัญหาซ้ำอยู่หรือไม่
- ระบุว่าสาเหตุมาจากความล่าช้าในการป้อนข้อมูลที่ใช้เวลานาน การเรียกกลับของเหตุการณ์ที่มีค่าใช้จ่ายสูง หรือการแสดงผลที่มีราคาแพง
- ทำซ้ำ
ข้อสุดท้ายคือสิ่งที่สำคัญที่สุด การแก้ปัญหาและการปรับปรุง INP เป็นกระบวนการที่วนซ้ำเช่นเดียวกับงานอื่นๆ ส่วนใหญ่ที่คุณทำเพื่อปรับปรุงประสิทธิภาพของหน้าเว็บ เมื่อคุณแก้ไขการโต้ตอบที่ช้า 1 รายการ ให้เลื่อนไปทำรายการถัดไป และทำซ้ำจนกว่าคุณจะเริ่มเห็นผลลัพธ์