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

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

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

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

จะทำอย่างไรหากคุณไม่มีข้อมูลภาคสนาม

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

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

หากต้องการทราบ TBT ของหน้าเว็บ ให้ใช้ Lighthouse หรือ PageSpeed Insights หาก TBT ของหน้าเว็บไม่ตรงตามเกณฑ์ "ที่ดี" ก็เป็นไปได้ว่าเทรดหลักไม่ว่างในระหว่างการโหลดหน้าเว็บ และอาจส่งผลกระทบต่อความเร็วในการโต้ตอบที่เกิดขึ้นในช่วงเวลาสำคัญในวงจรของหน้า

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

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

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

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

ไม่สามารถเข้าถึงเครื่องมือสร้างโปรไฟล์ประสิทธิภาพทันที

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

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

ใช้ส่วนขยาย Web Vitals ใน Chrome

ส่วนขยาย Chrome ของ Web Vitals ใช้ความพยายามน้อยที่สุดในการทดสอบเวลาในการตอบสนองของการโต้ตอบด้วยตนเอง เมื่อติดตั้งแล้ว ส่วนขยายจะแสดงข้อมูลการโต้ตอบในคอนโซล DevTools โดยคุณต้องทำดังต่อไปนี้ก่อน

1. ใน Chrome ให้คลิกไอคอนส่วนขยายทางด้านขวาของแถบที่อยู่
2. ค้นหาส่วนขยาย Web Vitals ในเมนูแบบเลื่อนลง
3. คลิกไอคอนทางด้านขวาเพื่อเปิดการตั้งค่าของส่วนขยาย
4. คลิกตัวเลือก
5. เลือกช่องทำเครื่องหมายการบันทึกคอนโซลในหน้าจอผลลัพธ์ แล้วคลิกบันทึก

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

ใช้ข้อมูลโค้ด JavaScript

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

อีกวิธีหนึ่งในการใช้ส่วนขยาย Web Vitals คือการคัดลอกและวาง JavaScript บางส่วนลงในคอนโซลเครื่องมือสำหรับนักพัฒนาเว็บ โค้ดต่อไปนี้ให้เอาต์พุตคอนโซลเช่นเดียวกับส่วนขยาย Web Vitals สําหรับการโต้ตอบแต่ละครั้ง

let worstInp = 0;

const observer = new PerformanceObserver((list, obs, options) => {
  for (let entry of list.getEntries()) {
    if (!entry.interactionId) continue;

    entry.renderTime = entry.startTime + entry.duration;
    worstInp = Math.max(entry.duration, worstInp);

    console.log('[Interaction]', entry.duration, `type: ${entry.name} interactionCount: ${performance.interactionCount}, worstInp: ${worstInp}`, entry, options);
  }
});

observer.observe({
  type: 'event',
  durationThreshold: 0, // 16 minimum by spec
  buffered: true
});

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

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

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

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

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

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

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

หากต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับสาเหตุที่การโต้ตอบล่าช้า ขั้นตอนถัดไปคือการใช้เครื่องมือโปรไฟล์ประสิทธิภาพใน Chrome DevTools ในการสร้างโปรไฟล์การโต้ตอบ ในเครื่องมือสร้างโปรไฟล์ประสิทธิภาพของ Chrome ให้ทำดังต่อไปนี้

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

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

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

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

ใช้ระยะเวลาของ Lighthouse แทนการติดตาม

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

1. เมื่อเปิดเครื่องมือสำหรับนักพัฒนาเว็บ ให้ไปที่แท็บ Lighthouse ในเครื่องมือสำหรับนักพัฒนาเว็บ
2. ในส่วนโหมด ให้เลือกตัวเลือกระยะเวลา
3. เลือกประเภทอุปกรณ์เดสก์ท็อปหรืออุปกรณ์เคลื่อนที่ในส่วนอุปกรณ์
4. ตรวจสอบว่าได้เลือกช่องทำเครื่องหมายประสิทธิภาพภายใต้ป้ายกำกับหมวดหมู่เป็นอย่างน้อย
5. คลิกปุ่มเริ่มช่วงเวลา
6. ทดสอบการโต้ตอบบนหน้าเว็บที่คุณต้องการรับข้อมูล
7. คลิกปุ่มสิ้นสุดช่วงเวลา และรอให้การตรวจสอบปรากฏขึ้น
8. เมื่อการตรวจสอบปรากฏในแท็บ Lighthouse แล้ว คุณจะกรองการตรวจสอบตาม IINP ได้โดยคลิกลิงก์ INP ข้างป้ายกำกับที่เขียนว่าแสดงการตรวจสอบที่เกี่ยวข้องกับ

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

วิธีระบุความล่าช้าในการป้อนข้อมูลที่ใช้เวลานาน

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

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

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

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

วิธีระบุโค้ดเรียกกลับเหตุการณ์ที่มีราคาสูง

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

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

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

หากต้องการจัดการกับโค้ดเรียกกลับของเหตุการณ์ที่มีราคาสูง ให้ลองใช้หนึ่งในกลยุทธ์ต่อไปนี้

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

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

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

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

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

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

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

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

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

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