ดูวิธีเพิ่มประสิทธิภาพ Interaction to Next Paint ของเว็บไซต์
เผยแพร่เมื่อ: 19 พฤษภาคม 2023, อัปเดตล่าสุด: 2 กันยายน 2025
Interaction to Next Paint (INP) เป็นเมตริก Core Web Vitals ที่เสถียร ซึ่งประเมินการตอบสนองโดยรวมของหน้าเว็บต่อการโต้ตอบของผู้ใช้ โดยสังเกตระยะเวลาในการตอบสนองของการโต้ตอบที่มีสิทธิ์ทั้งหมดที่เกิดขึ้นตลอดอายุการเข้าชมหน้าเว็บของผู้ใช้ ค่า INP สุดท้ายคือการโต้ตอบที่ยาวที่สุดที่สังเกตได้ (บางครั้งไม่ได้สนใจข้อมูลผิดปกติทางสถิติ)
เพื่อให้ผู้ใช้ได้รับประสบการณ์ที่ดี เว็บไซต์ต้องพยายามให้มี Interaction to Next Paint ไม่เกิน 200 มิลลิวินาที เพื่อให้บรรลุเป้าหมายนี้สำหรับผู้ใช้ส่วนใหญ่ เกณฑ์ที่ดีในการวัดคือเปอร์เซ็นไทล์ที่ 75 ของการโหลดหน้าเว็บ โดยแบ่งตามอุปกรณ์มือถือและเดสก์ท็อป
เว็บไซต์บางแห่งอาจมีการโต้ตอบน้อยหรือไม่มีเลย เช่น หน้าเว็บที่มีข้อความและรูปภาพเป็นส่วนใหญ่โดยมีองค์ประกอบแบบโต้ตอบน้อยหรือไม่มีเลย หรือในกรณีของเว็บไซต์ เช่น โปรแกรมแก้ไขข้อความหรือเกม อาจมีการโต้ตอบหลายร้อยรายการหรือหลายพันรายการ ไม่ว่ากรณีใดก็ตาม หาก INP สูง ผู้ใช้จะได้รับประสบการณ์การใช้งานที่ไม่ดี
การปรับปรุง INP ต้องใช้เวลาและความพยายาม แต่ผลตอบแทนที่ได้คือประสบการณ์การใช้งานที่ดีขึ้น ในคู่มือนี้ เราจะสำรวจเส้นทางในการปรับปรุง INP
หาสาเหตุที่ทำให้ INP ไม่ดี
ก่อนที่จะแก้ไขการโต้ตอบที่ช้า คุณจะต้องมีข้อมูลเพื่อบอกว่า INP ของเว็บไซต์ไม่ดีหรือต้องปรับปรุง เมื่อมีข้อมูลดังกล่าวแล้ว คุณจะย้ายไปที่ห้องทดลองเพื่อเริ่มวินิจฉัยการโต้ตอบที่ช้า และหาวิธีแก้ปัญหา
ค้นหาการโต้ตอบที่ช้าในข้อมูลภาคสนาม
โดยหลักการแล้ว การเดินทางของคุณในการเพิ่มประสิทธิภาพ INP จะเริ่มต้นด้วย ข้อมูลภาคสนาม ข้อมูลภาคสนามจากผู้ให้บริการ Real User Monitoring (RUM) จะให้ค่า INP ของหน้าเว็บ รวมถึงข้อมูลตามบริบทที่ไฮไลต์การโต้ตอบที่เฉพาะเจาะจงซึ่งเป็นสาเหตุของค่า INP เอง ไม่ว่าการโต้ตอบจะเกิดขึ้นระหว่างหรือหลังการโหลดหน้าเว็บ ประเภทของการโต้ตอบ (คลิก กดแป้น หรือแตะ) และข้อมูลที่เป็นประโยชน์อื่นๆ
หากคุณไม่ได้ใช้ผู้ให้บริการ RUM เพื่อรับข้อมูลภาคสนาม คู่มือข้อมูลภาคสนาม INP แนะนำให้ ใช้ PageSpeed Insights เพื่อดูข้อมูลรายงานประสบการณ์ของผู้ใช้ Chrome (CrUX) เพื่อช่วยเติมเต็มช่องว่าง CrUX คือชุดข้อมูลของ Google เกี่ยวกับโปรแกรม Core Web Vitals และให้ข้อมูลสรุปเมตริกระดับสูงสำหรับเว็บไซต์หลายล้านเว็บไซต์ รวมถึง INP อย่างไรก็ตาม CrUX มักจะไม่ได้ให้ข้อมูลตามบริบทที่คุณจะได้รับจากผู้ให้บริการ RUM เพื่อช่วยคุณวิเคราะห์ปัญหา ด้วยเหตุนี้ เราจึงยังคงแนะนำให้เว็บไซต์ใช้ผู้ให้บริการ RUM หากเป็นไปได้ หรือใช้โซลูชัน RUM ของตนเองเพื่อเสริมสิ่งที่พร้อมใช้งานใน CrUX
วินิจฉัยการโต้ตอบที่ช้าในห้องทดลอง
โดยหลักการแล้ว คุณควรเริ่มทดสอบในห้องทดลองเมื่อมีข้อมูลภาคสนามที่บ่งชี้ว่าคุณมีการโต้ตอบที่ช้า หากไม่มีข้อมูลภาคสนาม คุณสามารถใช้กลยุทธ์บางอย่างเพื่อระบุการโต้ตอบที่ช้าในห้องทดลอง กลยุทธ์ดังกล่าวรวมถึงการทำตามโฟลว์ของผู้ใช้ทั่วไปและการทดสอบการโต้ตอบไปพร้อมกัน รวมถึงการโต้ตอบกับหน้าเว็บระหว่างการโหลด ซึ่งเป็นช่วงที่เทรดหลักมักจะทำงานมากที่สุด เพื่อระบุการโต้ตอบที่ช้าในส่วนสำคัญของประสบการณ์การใช้งานของผู้ใช้
เพิ่มประสิทธิภาพการโต้ตอบ
เมื่อระบุการโต้ตอบที่ช้าและจำลองการโต้ตอบนั้นด้วยตนเองในห้องทดลองได้แล้ว ขั้นตอนถัดไปคือการเพิ่มประสิทธิภาพ
การโต้ตอบสามารถแบ่งออกเป็น 3 ส่วนย่อย ได้แก่
- ระยะเวลาในการตอบสนองต่ออินพุต ซึ่งเริ่มขึ้นเมื่อผู้ใช้เริ่มการโต้ตอบกับหน้าเว็บ และสิ้นสุดลงเมื่อการเรียกกลับเหตุการณ์สำหรับการโต้ตอบเริ่มทำงาน
- ระยะเวลาการประมวลผล ซึ่งประกอบด้วยระยะเวลาที่การเรียกกลับเหตุการณ์ใช้ในการทำงานจนเสร็จสมบูรณ์
- ระยะเวลาในการแสดงผล ซึ่งเป็นระยะเวลาที่เบราว์เซอร์ใช้ในการแสดงเฟรมถัดไปที่มีผลลัพธ์ภาพของการโต้ตอบ
ผลรวมของส่วนย่อยทั้ง 3 นี้คือระยะเวลาในการตอบสนองทั้งหมดของการโต้ตอบ ส่วนย่อยแต่ละส่วนของการโต้ตอบจะใช้เวลาในการตอบสนองทั้งหมดของการโต้ตอบ ดังนั้นคุณจึงต้องทราบวิธีเพิ่มประสิทธิภาพการโต้ตอบแต่ละส่วนเพื่อให้การโต้ตอบใช้เวลาน้อยที่สุด
ระบุและลดระยะเวลาในการตอบสนองต่ออินพุต
เมื่อผู้ใช้โต้ตอบกับหน้าเว็บ ส่วนแรกของการโต้ตอบนั้นคือ ระยะเวลาในการตอบสนองต่ออินพุต ระยะเวลาในการตอบสนองต่ออินพุตอาจยาวนานมาก ทั้งนี้ขึ้นอยู่กับกิจกรรมอื่นๆ ในหน้าเว็บ ซึ่งอาจเกิดจากกิจกรรมที่เกิดขึ้นในเทรดหลัก (อาจเกิดจากการโหลด แยกวิเคราะห์ และคอมไพล์สคริปต์) การจัดการการดึงข้อมูล ฟังก์ชันตัวจับเวลา หรือแม้แต่จากการโต้ตอบอื่นๆ ที่เกิดขึ้นอย่างรวดเร็วและซ้อนทับกัน
ไม่ว่าแหล่งที่มาของระยะเวลาในการตอบสนองต่ออินพุตของการโต้ตอบจะเป็นอะไรก็ตาม คุณควรลดระยะเวลาในการตอบสนองต่ออินพุตให้เหลือน้อยที่สุดเพื่อให้การโต้ตอบเริ่มเรียกกลับเหตุการณ์ได้โดยเร็วที่สุด
ความสัมพันธ์ระหว่างการประเมินสคริปต์กับงานที่ใช้เวลานานระหว่างการเริ่มต้น
ลักษณะสำคัญของการโต้ตอบในวงจรการทำงานของหน้าเว็บคือระหว่างการเริ่มต้น เมื่อหน้าเว็บโหลด หน้าเว็บจะแสดงผลในตอนแรก แต่คุณต้องจำไว้ว่าหน้าเว็บที่ แสดงผล แล้วไม่ได้หมายความว่าหน้าเว็บ โหลด เสร็จแล้ว หน้าเว็บอาจต้องใช้ทรัพยากรจำนวนมากเพื่อให้ทำงานได้อย่างเต็มที่ ดังนั้นผู้ใช้อาจพยายามโต้ตอบกับหน้าเว็บในขณะที่หน้าเว็บยังโหลดอยู่
สิ่งหนึ่งที่อาจทำให้ระยะเวลาในการตอบสนองต่ออินพุตของการโต้ตอบนานขึ้นขณะที่หน้าเว็บโหลดอยู่คือการประเมินสคริปต์ หลังจากที่ดึงข้อมูลไฟล์ JavaScript จากเครือข่ายแล้ว เบราว์เซอร์ยังต้องทำงานอีกก่อนที่จะเรียกใช้ JavaScript นั้นได้ ซึ่งงานดังกล่าวรวมถึงการแยกวิเคราะห์สคริปต์เพื่อตรวจสอบว่าไวยากรณ์ถูกต้อง คอมไพล์สคริปต์เป็นไบต์โค้ด และสุดท้ายคือการเรียกใช้สคริปต์
งานนี้อาจทำให้เกิดงานที่ใช้เวลานานในเทรดหลัก ซึ่งจะทำให้เบราว์เซอร์ตอบสนองต่อการโต้ตอบอื่นๆ ของผู้ใช้ได้ช้าลง ทั้งนี้ขึ้นอยู่กับขนาดของสคริปต์ เพื่อให้หน้าเว็บตอบสนองต่อข้อมูลจากผู้ใช้ระหว่างการโหลดหน้าเว็บ คุณต้องเข้าใจสิ่งที่คุณทำได้เพื่อลดโอกาสที่จะเกิดงานที่ใช้เวลานานระหว่างการโหลดหน้าเว็บ เพื่อให้หน้าเว็บทำงานได้อย่างรวดเร็ว
เพิ่มประสิทธิภาพการเรียกกลับเหตุการณ์
ระยะเวลาในการตอบสนองต่ออินพุตเป็นเพียงส่วนแรกของสิ่งที่ INP วัด คุณต้องตรวจสอบด้วยว่าการเรียกกลับเหตุการณ์ที่ทำงานเพื่อตอบสนองต่อการโต้ตอบของผู้ใช้สามารถดำเนินการให้เสร็จสมบูรณ์ได้โดยเร็วที่สุด
ส่งงานไปยังเทรดหลักบ่อยๆ
คำแนะนำทั่วไปที่ดีที่สุดในการเพิ่มประสิทธิภาพการเรียกกลับเหตุการณ์คือการทำงานให้น้อยที่สุดในการเรียกกลับเหตุการณ์ อย่างไรก็ตาม ตรรกะการโต้ตอบอาจซับซ้อน และคุณอาจลดงานที่การเรียกกลับเหตุการณ์ทำได้เพียงเล็กน้อย
หากเว็บไซต์ของคุณเป็นเช่นนี้ สิ่งถัดไปที่คุณลองทำได้คือการแบ่งงานในการเรียกกลับเหตุการณ์ออกเป็นงานแยกกัน วิธีนี้จะป้องกันไม่ให้งานทั้งหมดกลายเป็นงานที่ใช้เวลานานซึ่งบล็อกเทรดหลัก ทำให้การโต้ตอบอื่นๆ ที่รอเทรดหลักอยู่สามารถทำงานได้เร็วขึ้น
setTimeout เป็นวิธีหนึ่งในการแบ่งงาน เนื่องจากฟังก์ชันเรียกกลับที่ส่งไปยังฟังก์ชันนี้จะทำงานในงานใหม่ คุณสามารถ ใช้ setTimeout ด้วยตัวเอง หรือแยกการใช้งานฟังก์ชันนี้ออกเป็นฟังก์ชันแยกกัน เพื่อให้การส่งงานไปยังเทรดหลักทำได้ง่ายขึ้น
การส่งงานไปยังเทรดหลักโดยไม่เลือกปฏิบัติย่อมดีกว่าการไม่ส่งงานเลย อย่างไรก็ตาม มีวิธีที่ละเอียดกว่าในการส่งงานไปยังเทรดหลัก ซึ่งเกี่ยวข้องกับการส่งงานทันทีหลังจากฟังก์ชันเรียกกลับเหตุการณ์ที่อัปเดตอินเทอร์เฟซผู้ใช้ เพื่อให้ตรรกะการแสดงผลทำงานได้เร็วขึ้น
ส่งงานเพื่อให้งานการแสดงผลเกิดขึ้นได้เร็วขึ้น
เทคนิคการส่งงานขั้นสูงกว่านั้นเกี่ยวข้องกับการจัดโครงสร้างโค้ดในการเรียกกลับเหตุการณ์เพื่อจำกัดสิ่งที่ทำงานให้เหลือเพียงตรรกะที่จำเป็นในการใช้การอัปเดตภาพสำหรับเฟรมถัดไป ส่วนอื่นๆ ทั้งหมดสามารถเลื่อนออกไปเป็นงานในภายหลังได้ วิธีนี้ไม่เพียงทำให้การเรียกกลับมีขนาดเล็กและทำงานได้อย่างรวดเร็วเท่านั้น แต่ยังช่วยลดเวลาการแสดงผลสำหรับการโต้ตอบด้วยการไม่อนุญาตให้การอัปเดตภาพบล็อกโค้ดการเรียกกลับเหตุการณ์
ตัวอย่างเช่น ลองนึกภาพโปรแกรมแก้ไขข้อความ Rich Text ที่จัดรูปแบบข้อความขณะที่คุณพิมพ์ แต่ยังอัปเดตส่วนอื่นๆ ของ UI เพื่อตอบสนองต่อสิ่งที่คุณเขียนด้วย (เช่น จำนวนคำ การไฮไลต์การสะกดคำผิด และความคิดเห็นภาพที่สำคัญอื่นๆ) นอกจากนี้ แอปพลิเคชันอาจต้องบันทึกสิ่งที่คุณเขียนด้วย เพื่อให้คุณไม่สูญเสียงานหากออกจากแอปพลิเคชันแล้วกลับมาอีกครั้ง
ในตัวอย่างนี้ สิ่งต่อไปนี้ 4 อย่างต้องเกิดขึ้นเพื่อตอบสนองต่ออักขระที่ผู้ใช้พิมพ์ อย่างไรก็ตาม คุณต้องทำเฉพาะรายการแรกก่อนที่จะแสดงเฟรมถัดไป
- อัปเดตช่องข้อความด้วยสิ่งที่ผู้ใช้พิมพ์และใช้การจัดรูปแบบที่จำเป็น
- อัปเดตส่วนของ UI ที่แสดงจำนวนคำปัจจุบัน
- เรียกใช้ตรรกะเพื่อตรวจสอบการสะกดคำผิด
- บันทึกการเปลี่ยนแปลงล่าสุด (ในเครื่องหรือในฐานข้อมูลระยะไกล)
โค้ดที่ใช้ทำเช่นนี้อาจมีลักษณะดังนี้
textBox.addEventListener('input', (inputEvent) => {
// Update the UI immediately, so the changes the user made
// are visible as soon as the next frame is presented.
updateTextBox(inputEvent);
// Use `setTimeout` to defer all other work until at least the next
// frame by queuing a task in a `requestAnimationFrame()` callback.
requestAnimationFrame(() => {
setTimeout(() => {
const text = textBox.textContent;
updateWordCount(text);
checkSpelling(text);
saveChanges(text);
}, 0);
});
});
ภาพต่อไปนี้แสดงให้เห็นว่าการเลื่อนการอัปเดตที่ไม่สำคัญออกไปจนกว่าจะถึงเฟรมถัดไปจะช่วยลดระยะเวลาการประมวลผลและระยะเวลาในการตอบสนองทั้งหมดของการโต้ตอบได้อย่างไร
แม้ว่าการใช้ setTimeout() ภายในการเรียก requestAnimationFrame() ในตัวอย่างโค้ดก่อนหน้านี้จะดูซับซ้อนไปบ้าง แต่ก็เป็นวิธีที่มีประสิทธิภาพซึ่งทำงานได้ในเบราว์เซอร์ทั้งหมดเพื่อป้องกันไม่ให้โค้ดที่ไม่สำคัญบล็อกเฟรมถัดไป
หลีกเลี่ยงการเปลี่ยนแปลงเลย์เอาต์ซ้ำๆ
Layout thrashing หรือบางครั้งเรียกว่า forced synchronous layout เป็นปัญหาด้านประสิทธิภาพการแสดงผลที่การเปลี่ยนแปลงเลย์เอาต์เกิดขึ้นแบบซิงโครนัส ปัญหานี้เกิดขึ้นเมื่อคุณอัปเดตสไตล์ใน JavaScript แล้วอ่านสไตล์เหล่านั้นในงานเดียวกัน และ มีพร็อพเพอร์ตี้จำนวนมากใน JavaScript ที่อาจทำให้เกิดการเปลี่ยนแปลงเลย์เอาต์ซ้ำๆ
การ Thrash เลย์เอาต์เป็นจุดคอขวดด้านประสิทธิภาพ เนื่องจากเมื่ออัปเดตสไตล์แล้วขอค่าของสไตล์เหล่านั้นใน JavaScript ทันที เบราว์เซอร์จะถูกบังคับให้ทำงานการเปลี่ยนแปลงเลย์เอาต์แบบซิงโครนัส ซึ่งเบราว์เซอร์อาจรอเพื่อดำเนินการแบบอะซิงโครนัสในภายหลังหลังจากที่ Callback เหตุการณ์ทำงานเสร็จแล้ว
ลดระยะเวลาในการแสดงผล
ระยะเวลาในการแสดงผล ของการโต้ตอบจะเริ่มขึ้นเมื่อการเรียกกลับเหตุการณ์ของการโต้ตอบทำงานเสร็จแล้ว ไปจนถึงจุดที่เบราว์เซอร์สามารถวาดเฟรมถัดไปที่แสดงการเปลี่ยนแปลงภาพที่เกิดขึ้น
ลดขนาด DOM
เมื่อ DOM ของหน้าเว็บมีขนาดเล็ก งานการแสดงผลมักจะเสร็จเร็ว อย่างไรก็ตาม เมื่อ DOM มีขนาดใหญ่มาก งานการแสดงผลมักจะเพิ่มขึ้นตามขนาด DOM ที่เพิ่มขึ้น ความสัมพันธ์ระหว่างงานการแสดงผลกับขนาด DOM ไม่ใช่ความสัมพันธ์เชิงเส้น แต่ DOM ขนาดใหญ่ต้องใช้ทรัพยากรมากกว่าในการแสดงผลเมื่อเทียบกับ DOM ขนาดเล็ก DOM ขนาดใหญ่เป็นปัญหาใน 2 กรณีต่อไปนี้
- ระหว่างการแสดงผลหน้าเว็บครั้งแรก ซึ่ง DOM ขนาดใหญ่ต้องใช้ทรัพยากรจำนวนมากในการแสดงผลสถานะเริ่มต้นของหน้าเว็บ
- เพื่อตอบสนองต่อการโต้ตอบของผู้ใช้ ซึ่ง DOM ขนาดใหญ่อาจทำให้การอัปเดตการแสดงผลใช้ทรัพยากรจำนวนมาก และทำให้เบราว์เซอร์ใช้เวลามากขึ้นในการแสดงเฟรมถัดไป
โปรดทราบว่ามีบางกรณีที่คุณไม่สามารถลดขนาด DOM ขนาดใหญ่ได้อย่างมาก แม้ว่าจะมีแนวทางที่คุณใช้เพื่อลดขนาด DOM ได้ เช่น การทำให้ DOM แบนลง หรือ เพิ่มองค์ประกอบลงใน DOM ระหว่างการโต้ตอบของผู้ใช้ เพื่อให้ DOM เริ่มต้นมีขนาดเล็ก แต่เทคนิคเหล่านั้นอาจช่วยได้เพียงบางส่วนเท่านั้น
ใช้ content-visibility เพื่อแสดงผลองค์ประกอบนอกหน้าจอแบบเลื่อนการโหลด
วิธีหนึ่งที่คุณใช้เพื่อจำกัดปริมาณงานการแสดงผลระหว่างการโหลดหน้าเว็บและงานการแสดงผลเพื่อตอบสนองต่อการโต้ตอบของผู้ใช้คือการใช้พร็อพเพอร์ตี้ CSS content-visibility ซึ่งเทียบเท่ากับการแสดงผลองค์ประกอบแบบเลื่อนการโหลดเมื่อองค์ประกอบเข้าใกล้วิวพอร์ต แม้ว่า content-visibility อาจต้องใช้การฝึกฝนเพื่อให้ใช้งานได้อย่างมีประสิทธิภาพ แต่ก็คุ้มค่าที่จะลองใช้หากผลลัพธ์ที่ได้คือเวลาการแสดงผลที่ลดลงซึ่งอาจช่วยปรับปรุง INP ของหน้าเว็บ
โปรดทราบถึงค่าใช้จ่ายด้านประสิทธิภาพเมื่อแสดงผล HTML โดยใช้ JavaScript
เมื่อมี HTML ก็ต้องมีการแยกวิเคราะห์ HTML และหลังจากที่เบราว์เซอร์แยกวิเคราะห์ HTML เป็น DOM เสร็จแล้ว เบราว์เซอร์จะต้องใช้สไตล์กับ DOM นั้น ทำการคำนวณเลย์เอาต์ และแสดงผลเลย์เอาต์นั้นในภายหลัง นี่คือค่าใช้จ่ายที่หลีกเลี่ยงไม่ได้ แต่ วิธี ที่คุณใช้ในการแสดงผล HTML นั้นสำคัญ
เมื่อเซิร์ฟเวอร์ส่ง HTML, HTML จะมาถึงเบราว์เซอร์เป็นสตรีม การสตรีมหมายความว่าการตอบสนอง HTML จากเซิร์ฟเวอร์จะมาถึงเป็นชิ้นๆ เบราว์เซอร์จะเพิ่มประสิทธิภาพวิธีจัดการสตรีมโดยการแยกวิเคราะห์ชิ้นส่วนของสตรีมนั้นทีละน้อยเมื่อชิ้นส่วนมาถึง และแสดงผลชิ้นส่วนเหล่านั้นทีละเล็กทีละน้อย นี่คือการเพิ่มประสิทธิภาพด้านประสิทธิภาพ เนื่องจากเบราว์เซอร์จะส่งงานไปยังเทรดหลักเป็นระยะๆ และโดยอัตโนมัติระหว่างการโหลดหน้าเว็บ และคุณจะได้รับประโยชน์นี้โดยไม่มีค่าใช้จ่าย
แม้ว่าการเข้าชมเว็บไซต์ครั้งแรกจะต้องเกี่ยวข้องกับ HTML จำนวนหนึ่ง เสมอ แต่แนวทางทั่วไปจะเริ่มต้นด้วย HTML เริ่มต้นจำนวนน้อยที่สุด จากนั้นใช้ JavaScript เพื่อป้อนข้อมูลในพื้นที่เนื้อหา การอัปเดตพื้นที่เนื้อหาดังกล่าวในภายหลังจะเกิดขึ้นจากการโต้ตอบของผู้ใช้ด้วย โดยปกติแล้วเราจะเรียกรูปแบบนี้ว่าโมเดลแอปพลิเคชันหน้าเว็บเดียว (SPA) ข้อเสียอย่างหนึ่งของรูปแบบนี้คือการแสดงผล HTML ด้วย JavaScript ในฝั่งไคลเอ็นต์ คุณไม่เพียงต้องเสียค่าใช้จ่ายในการประมวลผล JavaScript เพื่อสร้าง HTML นั้นเท่านั้น แต่เบราว์เซอร์จะ ไม่ ส่งงานไปยังเทรดหลักจนกว่าจะแยกวิเคราะห์ HTML นั้นเสร็จและแสดงผล HTML นั้น
อย่างไรก็ตาม สิ่งสำคัญที่ต้องจำไว้คือแม้แต่เว็บไซต์ที่ ไม่ใช่ SPA ก็อาจเกี่ยวข้องกับการแสดงผล HTML จำนวนหนึ่งผ่าน JavaScript อันเป็นผลมาจากการโต้ตอบ โดยทั่วไปแล้ววิธีนี้ใช้ได้ตราบใดที่คุณไม่ได้แสดงผล HTML จำนวนมากในฝั่งไคลเอ็นต์ ซึ่งอาจทำให้การแสดงเฟรมถัดไปล่าช้า อย่างไรก็ตาม คุณต้องเข้าใจผลกระทบด้านประสิทธิภาพของแนวทางนี้ในการแสดงผล HTML ในเบราว์เซอร์ และวิธีที่แนวทางนี้อาจส่งผลต่อการตอบสนองของเว็บไซต์ต่อข้อมูลจากผู้ใช้หากคุณแสดงผล HTML จำนวนมากโดยใช้ JavaScript
บทสรุป
การปรับปรุง INP ของเว็บไซต์เป็นกระบวนการแบบวนซ้ำ เมื่อคุณแก้ไขการโต้ตอบที่ช้าในข้อมูลภาคสนาม มีโอกาสสูงที่คุณจะเริ่มพบการโต้ตอบที่ช้าอื่นๆ และคุณจะต้องเพิ่มประสิทธิภาพการโต้ตอบเหล่านั้นด้วย โดยเฉพาะอย่างยิ่งหากเว็บไซต์ของคุณมีการโต้ตอบจำนวนมาก
กุญแจสำคัญในการปรับปรุง INP คือความพยายามอย่างต่อเนื่อง เมื่อเวลาผ่านไป คุณจะทำให้การตอบสนองของหน้าเว็บอยู่ในระดับที่ผู้ใช้พึงพอใจกับประสบการณ์การใช้งานที่คุณมอบให้ นอกจากนี้ ยังมีโอกาสสูงที่คุณจะต้องทำตามกระบวนการเดียวกันในการเพิ่มประสิทธิภาพการโต้ตอบที่เฉพาะเจาะจงเมื่อพัฒนาฟีเจอร์ใหม่ๆ ให้ผู้ใช้ ซึ่งต้องใช้เวลาและความพยายาม แต่ก็คุ้มค่า
รูปภาพหลักจาก Unsplash โดย David Pisnoy และแก้ไขตาม ใบอนุญาต Unsplash