เรียนรู้วิธีนำข้อมูลภาคสนามของคุณไปไว้ที่ห้องทดลองเพื่อทำซ้ำและระบุสาเหตุของการโต้ตอบที่ช้าผ่านการทดสอบด้วยตนเอง
ส่วนที่ท้าทายในการเพิ่มประสิทธิภาพ 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 โดยคุณต้องทำดังต่อไปนี้ก่อน
- ใน Chrome ให้คลิกไอคอนส่วนขยายทางด้านขวาของแถบที่อยู่
- ค้นหาส่วนขยาย Web Vitals ในเมนูแบบเลื่อนลง
- คลิกไอคอนทางด้านขวาเพื่อเปิดการตั้งค่าของส่วนขยาย
- คลิกตัวเลือก
- เลือกช่องทำเครื่องหมายการบันทึกคอนโซลในหน้าจอผลลัพธ์ แล้วคลิกบันทึก
เมื่อทำเสร็จแล้ว ให้เปิดคอนโซลใน 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 วิธีต่อไปนี้
- หากคุณมีอุปกรณ์จริงที่ขับเคลื่อนโดย Android ให้ใช้การแก้ไขข้อบกพร่องระยะไกลเพื่อเปิดอินสแตนซ์ Chrome DevTools บนเครื่องโฮสต์และพยายามจำลองการโต้ตอบที่ช้า อุปกรณ์เคลื่อนที่มักใช้งานไม่เร็วเท่าแล็ปท็อปหรือเดสก์ท็อป การโต้ตอบที่ช้าจึงอาจมองเห็นได้ง่ายกว่าในสภาวะเช่นนี้
- หากคุณไม่มีอุปกรณ์จริง ให้เปิดใช้ฟีเจอร์การควบคุม CPU ใน Chrome DevTools
- ลองใช้ทั้ง 1 ขั้นตอนที่ 1 และ 2 ร่วมกัน เนื่องจากคุณเปิดใช้การควบคุม CPU บนอินสแตนซ์ DevTools สำหรับอุปกรณ์ที่ใช้ Android ได้
อีกสาเหตุหนึ่งอาจเป็นเพราะคุณรอให้หน้าเว็บโหลดก่อนที่จะโต้ตอบกับหน้าเว็บ แต่ผู้ใช้ไม่โหลด หากคุณใช้เครือข่ายที่เร็ว ให้จำลองสภาพเครือข่ายที่ช้าลงโดยเปิดใช้การควบคุมเครือข่าย จากนั้นจะโต้ตอบกับหน้าเว็บทันทีที่แสดงผล คุณควรทำเช่นนี้เนื่องจากเทรดหลักมักจะยุ่งที่สุดในช่วงเริ่มต้น และการทดสอบ ณ เวลานั้นอาจเปิดเผยประสบการณ์ของผู้ใช้
บันทึกการติดตาม
หากต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับสาเหตุที่การโต้ตอบล่าช้า ขั้นตอนถัดไปคือการใช้เครื่องมือโปรไฟล์ประสิทธิภาพใน Chrome DevTools ในการสร้างโปรไฟล์การโต้ตอบ ในเครื่องมือสร้างโปรไฟล์ประสิทธิภาพของ Chrome ให้ทำดังต่อไปนี้
- เปิดหน้าที่คุณต้องการทดสอบ
- เปิดเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome แล้วไปที่แผงประสิทธิภาพ
- คลิกปุ่มบันทึกที่ด้านซ้ายบนของแผงเพื่อเริ่มการติดตาม
- โต้ตอบที่ต้องการสร้างโปรไฟล์
- คลิกปุ่มบันทึกอีกครั้งเพื่อหยุดการติดตาม
เมื่อเครื่องมือสร้างโปรไฟล์ป้อนข้อมูลแล้ว ที่แรกที่ควรดูคือสรุปกิจกรรมที่ด้านบนของเครื่องมือสร้างโปรไฟล์ สรุปกิจกรรมจะแสดงแถบสีแดงที่ด้านบนซึ่งมีงานที่ใช้เวลานานในการบันทึก วิธีนี้ช่วยให้คุณซูมเข้า พื้นที่ที่เป็นปัญหาได้อย่างรวดเร็ว
โฟกัสพื้นที่ที่มีปัญหาได้อย่างรวดเร็วด้วยการลากและเลือกเขตในสรุปกิจกรรม เมื่อคุณมุ่งเน้นที่ตำแหน่งที่การโต้ตอบเกิดขึ้น แทร็กการโต้ตอบจะช่วยให้คุณจัดเรียงการโต้ตอบและกิจกรรมที่เกิดขึ้นในแทร็กเทรดหลักที่อยู่ใต้แทร็กได้
จากตรงนี้คือการทำความเข้าใจปัญหาที่ทำให้การโต้ตอบได้ช้า มีหลายปัจจัยที่อาจทำให้เกิดเวลาในการตอบสนองสูง ซึ่งบางหัวข้อเราจะอธิบายเพิ่มเติมต่อไปในคู่มือนี้
ใช้ระยะเวลาของ Lighthouse แทนการติดตาม
เครื่องมือสร้างโปรไฟล์ประสิทธิภาพของ Chrome ที่แม้จะมีข้อมูลการวินิจฉัยอาจน่าสยดสยองสำหรับผู้ที่ยังไม่ได้เริ่มใช้งาน อีกทางเลือกหนึ่งสำหรับเครื่องมือสร้างโปรไฟล์ประสิทธิภาพ คือโหมดช่วงเวลาของ Lighthouse หากต้องการใช้โหมดนี้ ให้ทำดังนี้
- เมื่อเปิดเครื่องมือสำหรับนักพัฒนาเว็บ ให้ไปที่แท็บ Lighthouse ในเครื่องมือสำหรับนักพัฒนาเว็บ
- ในส่วนโหมด ให้เลือกตัวเลือกระยะเวลา
- เลือกประเภทอุปกรณ์เดสก์ท็อปหรืออุปกรณ์เคลื่อนที่ในส่วนอุปกรณ์
- ตรวจสอบว่าได้เลือกช่องทำเครื่องหมายประสิทธิภาพภายใต้ป้ายกำกับหมวดหมู่เป็นอย่างน้อย
- คลิกปุ่มเริ่มช่วงเวลา
- ทดสอบการโต้ตอบบนหน้าเว็บที่คุณต้องการรับข้อมูล
- คลิกปุ่มสิ้นสุดช่วงเวลา และรอให้การตรวจสอบปรากฏขึ้น
- เมื่อการตรวจสอบปรากฏในแท็บ Lighthouse แล้ว คุณจะกรองการตรวจสอบตาม IINP ได้โดยคลิกลิงก์ INP ข้างป้ายกำกับที่เขียนว่าแสดงการตรวจสอบที่เกี่ยวข้องกับ
ณ จุดนี้ รายการแบบเลื่อนลงสำหรับการตรวจสอบที่ไม่ผ่านหรือผ่านควรปรากฏขึ้น เมื่อคุณขยายเมนูแบบเลื่อนลง ควรมีรายละเอียดของระยะเวลาที่ใช้ในระหว่างการโต้ตอบ
วิธีระบุความล่าช้าในการป้อนข้อมูลที่ใช้เวลานาน
สิ่งหนึ่งที่อาจมีส่วนทำให้เวลาในการตอบสนองของการโต้ตอบสูงคือความล่าช้าของอินพุต ความล่าช้าในการป้อนข้อมูลคือระยะแรกของการโต้ตอบ คือระยะเวลานับจากที่ระบบปฏิบัติการได้รับการดำเนินการของผู้ใช้เป็นครั้งแรกจนถึงจุดที่เบราว์เซอร์สามารถเริ่มประมวลผลเหตุการณ์แรกที่อินพุตนั้นทริกเกอร์ การหน่วงเวลาอินพุตจะสิ้นสุดลงเมื่อการเรียกกลับของเหตุการณ์สำหรับการโต้ตอบเริ่มทำงาน
การระบุความล่าช้าของอินพุตในเครื่องมือสร้างโปรไฟล์ประสิทธิภาพของ Chrome ทำได้โดยค้นหาจุดเริ่มต้นของการโต้ตอบในแทร็กการโต้ตอบ จากนั้นหาจุดเริ่มต้นของเวลาที่โค้ดเรียกกลับของเหตุการณ์สำหรับการโต้ตอบนั้นเริ่มทำงาน
ควรคาดหวังความล่าช้าของอินพุตบางส่วนเสมอ เนื่องจากระบบปฏิบัติการต้องใช้เวลาพอสมควรในการส่งเหตุการณ์อินพุตไปยังเบราว์เซอร์ แต่คุณจะสามารถควบคุมระยะเวลาความล่าช้าของอินพุตได้ ข้อสำคัญคือต้องหาว่าการทำงานในเทรดหลักที่ทำให้เรียกใช้กลับไม่ได้หรือไม่
ในรูปก่อนหน้านี้ งานจากสคริปต์ของบุคคลที่สามกำลังทำงานเมื่อผู้ใช้พยายามโต้ตอบกับหน้าเว็บ ซึ่งจะขยายการหน่วงเวลาอินพุต ความล่าช้าของอินพุตที่มากขึ้นส่งผลต่อเวลาในการตอบสนองของการโต้ตอบ ดังนั้นจึงอาจส่งผลต่อ INP ของหน้าเว็บ
วิธีระบุโค้ดเรียกกลับเหตุการณ์ที่มีราคาสูง
โค้ดเรียกกลับของเหตุการณ์จะทำงานทันทีหลังจากความล่าช้าของอินพุต หากการเรียกกลับของเหตุการณ์ทำงานนานเกินไปจะทำให้เบราว์เซอร์ไม่ต้องแสดงเฟรมถัดไป และอาจทำให้เวลาในการตอบสนองรวมของการโต้ตอบมีนัยสำคัญ โค้ดเรียกกลับของเหตุการณ์ที่ใช้เวลานานอาจเป็นผลมาจาก JavaScript ของบุคคลที่หนึ่งหรือบุคคลที่สามที่มีการคำนวณราคาแพง และในบางกรณีก็เป็นทั้ง 2 อย่าง
ค้นหาโค้ดเรียกกลับเหตุการณ์ที่มีราคาสูงได้ด้วยการสังเกตสิ่งต่อไปนี้ในการติดตามการโต้ตอบที่เฉพาะเจาะจง
- พิจารณาว่างานที่เชื่อมโยงกับโค้ดเรียกกลับของเหตุการณ์เป็นงานที่ใช้เวลานานหรือไม่ หากต้องการเปิดเผยงานที่ใช้เวลานานในการตั้งค่าห้องทดลองให้เสถียรมากขึ้น คุณอาจต้องเปิดใช้การควบคุม CPU ในแผงประสิทธิภาพ หรือเชื่อมต่ออุปกรณ์ Android ระดับต่ำถึงระดับกลางและใช้การแก้ไขข้อบกพร่องระยะไกล
- หากงานที่เรียกใช้โค้ดเรียกกลับของเหตุการณ์เป็นงานที่ใช้เวลานาน ให้มองหารายการเครื่องจัดการเหตุการณ์ เช่น รายการที่มีชื่อ อย่างเช่น เหตุการณ์: คลิก ในสแต็กการเรียกใช้ที่มีรูปสามเหลี่ยมสีแดงที่มุมขวาบนของรายการ นี่เป็นการเรียกกลับของเหตุการณ์ที่มีราคาแพง
หากต้องการจัดการกับโค้ดเรียกกลับของเหตุการณ์ที่มีราคาสูง ให้ลองใช้หนึ่งในกลยุทธ์ต่อไปนี้
- ทำงานให้น้อยที่สุดเท่าที่จะเป็นไปได้ ทุกสิ่งที่เกิดขึ้นในการติดต่อกลับ
กิจกรรมที่มีราคาแพงนั้นจำเป็นมากไหม หากไม่ ให้ลองนำโค้ดดังกล่าวออกพร้อมกันหากทำได้ หรือเลื่อนการดำเนินการของโค้ดออกไปในภายหลังหากทำไม่ได้ นอกจากนี้ คุณยังใช้ประโยชน์จากฟีเจอร์เฟรมเวิร์กได้เช่นกัน เช่น คลาส
PureComponent
และฟีเจอร์การบันทึกเนื้อหาของ React อาจข้ามการแสดงผลที่ไม่จำเป็นเมื่อพร็อพเพอร์และสถานะไม่มีการเปลี่ยนแปลงสำหรับคอมโพเนนต์ - เลื่อนงานการไม่แสดงผลในการเรียกกลับเหตุการณ์ไปยังช่วงเวลาในภายหลัง งานที่ใช้เวลานานสามารถแบ่งย่อยได้โดยการปฏิเสธไปยังเทรดหลัก เมื่อใดก็ตามที่ระบบตอบกลับไปยังเทรดหลัก จะเป็นการสิ้นสุดการดำเนินการของงานปัจจุบันและแยกงานที่เหลือออกเป็นงานแยกต่างหาก วิธีนี้ช่วยให้ผู้แสดงผลมีโอกาสประมวลผลการอัปเดตอินเทอร์เฟซผู้ใช้ที่เกิดขึ้นก่อนหน้านี้ในโค้ดเรียกกลับของเหตุการณ์ หากใช้ React ฟีเจอร์การเปลี่ยน ฟีเจอร์นี้ช่วยคุณได้
การนำกลยุทธ์เหล่านี้ไปใช้ คุณควรทำให้โค้ดเรียกกลับของกิจกรรมอยู่ในที่ที่ตอบสนองต่อข้อมูลจากผู้ใช้ได้เร็วขึ้น
วิธีระบุความล่าช้าของงานนำเสนอ
ความล่าช้าในการป้อนข้อมูลที่ยาวนานและการเรียกกลับของเหตุการณ์ที่มีราคาแพงไม่ใช่สาเหตุของปัญหาที่เป็นไปได้เพียงอย่างเดียวของ INP ที่ไม่ดี บางครั้งการอัปเดตการแสดงผลที่เกิดขึ้นเพื่อตอบสนองต่อโค้ดเรียกกลับของเหตุการณ์ที่มีจำนวนน้อยอาจมีค่าใช้จ่ายสูง เวลาที่เบราว์เซอร์ใช้ในการแสดงผลการอัปเดตด้วยภาพในอินเทอร์เฟซผู้ใช้เพื่อแสดงผลของการโต้ตอบเรียกว่าความล่าช้าของงานนำเสนอ
จากสาเหตุที่เป็นไปได้ทั้งหมดของเวลาในการตอบสนองของการโต้ตอบที่สูง การแสดงผลอาจเป็นเรื่องยากที่สุดที่จะแก้ไขและแก้ไขได้ แต่ผลลัพธ์ที่ได้ก็คุ้มค่ากับความพยายาม การแสดงผลมากเกินไปอาจเกิดจากสาเหตุต่อไปนี้
- DOM ขนาดใหญ่ ต้องมีการแสดงผลเพิ่มขึ้นเพื่ออัปเดตงานนำเสนอของหน้าเว็บมักจะเพิ่มขึ้นตามขนาด DOM ของหน้าเว็บ อ่านข้อมูลเพิ่มเติมได้ที่วิธีที่ DOM ขนาดใหญ่ส่งผลต่อการโต้ตอบและสิ่งที่คุณทำได้
- การบังคับให้จัดเรียงใหม่ กรณีนี้เกิดขึ้นเมื่อคุณใช้การเปลี่ยนแปลงรูปแบบกับองค์ประกอบใน JavaScript และแล้วค้นหาผลลัพธ์ของงานนั้น ผลที่ได้คือเบราว์เซอร์ต้องทำงานเลย์เอาต์ก่อนทำอย่างอื่น เพื่อให้เบราว์เซอร์แสดงสไตล์ที่อัปเดตได้ ดูข้อมูลเพิ่มเติมและเคล็ดลับเกี่ยวกับการหลีกเลี่ยงการบังคับให้จัดเรียงใหม่ได้ในหลีกเลี่ยงเลย์เอาต์ขนาดใหญ่และซับซ้อนที่มีการสลับเลย์เอาต์
- การทำงานที่มากเกินไปหรือไม่จำเป็นในโค้ดเรียกกลับของ
requestAnimationFrame
โค้ดเรียกกลับrequestAnimationFrame()
จะทำงานระหว่างช่วงการแสดงผลของลูปเหตุการณ์ และต้องเสร็จสมบูรณ์ก่อนจึงจะนำเสนอเฟรมถัดไปได้ หากคุณใช้requestAnimationFrame()
เพื่อทำงานที่ไม่เกี่ยวข้องกับการเปลี่ยนแปลงอินเทอร์เฟซผู้ใช้ โปรดทราบว่าคุณอาจหน่วงเวลาเฟรมถัดไปไว้ ResizeObserver
callback โค้ดเรียกกลับดังกล่าวจะทำงานก่อนการแสดงผล และอาจทำให้การนำเสนอเฟรมถัดไปล่าช้าหากงานในเฟรมนั้นมีราคาสูง เช่นเดียวกับโค้ดเรียกกลับเหตุการณ์ เลื่อนลอจิกที่ไม่จำเป็นสำหรับเฟรมถัดไป
INP ของการแก้ปัญหาเป็นกระบวนการที่ต้องทำซ้ำ
การจะหาสาเหตุที่ทำให้เวลาในการตอบสนองของการโต้ตอบสูงและ INP ไม่ดีนั้นต้องใช้ความพยายามอย่างมาก แต่หากคุณสามารถระบุสาเหตุได้ ก็มาถึงครึ่งทางแล้ว การทำตามแนวทางที่เป็นระบบในการแก้ปัญหา INP ที่ไม่ดีจะช่วยให้คุณปักหมุดสิ่งที่เป็นต้นเหตุได้อย่างวางใจและมาถึงวิธีแก้ไขที่เหมาะสมได้เร็วขึ้น วิธีตรวจสอบมีดังนี้
- อาศัยข้อมูลภาคสนามเพื่อหาการโต้ตอบที่ช้า
- ทดสอบการโต้ตอบในช่องที่เป็นปัญหาในห้องทดลองด้วยตนเองเพื่อดูว่าสามารถทำให้เกิดซ้ำได้หรือไม่
- ระบุว่าสาเหตุเกิดจากความล่าช้าของอินพุตที่นาน การเรียกกลับของเหตุการณ์ราคาแพง หรือการแสดงผลที่มีราคาแพง
- ทำซ้ำ
ข้อสุดท้ายคือสิ่งที่สำคัญที่สุด การแก้ปัญหาและการปรับปรุง INP เป็นกระบวนการแบบวนซ้ำเช่นเดียวกับงานอื่นๆ ส่วนใหญ่ที่คุณทำเพื่อปรับปรุงประสิทธิภาพของหน้าเว็บ เมื่อแก้ไขการโต้ตอบที่ช้าแล้ว 1 รายการ ให้ไปยังการโต้ตอบถัดไปและทำซ้ำจนกว่าจะเริ่มเห็นผลลัพธ์ คอยระวังตัว!