เพิ่มประสิทธิภาพการโต้ตอบกับ Next Paint

ดูวิธีเพิ่มประสิทธิภาพ Interaction to Next Paint ของเว็บไซต์

Jeremy Wagner

Philip Walton

Barry Pollard

เผยแพร่เมื่อวันที่ 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 ส่วนย่อย ดังนี้

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

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

ระบุและลดความล่าช้าของอินพุต

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

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

ความสัมพันธ์ระหว่างการประเมินสคริปต์และงานที่ใช้เวลานานระหว่างการเริ่มต้นระบบ

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

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

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

เพิ่มประสิทธิภาพ Callback ของเหตุการณ์

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

ส่งต่อการควบคุมไปยังเทรดหลักบ่อยๆ

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

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

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

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

Yield เพื่อให้การแสดงผลเกิดขึ้นเร็วขึ้น

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

ตัวอย่างเช่น ลองนึกถึงเครื่องมือแก้ไขข้อความ Rich Text ที่จัดรูปแบบข้อความขณะที่คุณพิมพ์ แต่ยังอัปเดตแง่มุมอื่นๆ ของ UI เพื่อตอบสนองต่อสิ่งที่คุณเขียนด้วย (เช่น จำนวนคำ การไฮไลต์ข้อผิดพลาดในการสะกด และการแสดงผลที่สำคัญอื่นๆ) นอกจากนี้ แอปพลิเคชันอาจต้องบันทึกสิ่งที่คุณเขียนไว้ด้วย เพื่อให้คุณไม่สูญเสียงานใดๆ หากออกจากแอปพลิเคชันและกลับมาอีกครั้ง

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

1. อัปเดตกล่องข้อความด้วยสิ่งที่ผู้ใช้พิมพ์และใช้การจัดรูปแบบที่จำเป็น
2. อัปเดตส่วนของ UI ที่แสดงจำนวนคำปัจจุบัน
3. เรียกใช้ตรรกะเพื่อตรวจสอบข้อผิดพลาดในการสะกดคำ
4. บันทึกการเปลี่ยนแปลงล่าสุด (ในเครื่องหรือในฐานข้อมูลระยะไกล)

โค้ดที่ใช้ดำเนินการนี้อาจมีลักษณะดังนี้

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() ในตัวอย่างโค้ดก่อนหน้านี้อาจเข้าใจยากไปสักหน่อย แต่ก็เป็นวิธีที่มีประสิทธิภาพซึ่งใช้ได้ในทุกเบราว์เซอร์เพื่อป้องกันไม่ให้โค้ดที่ไม่สำคัญบล็อกเฟรมถัดไป

หลีกเลี่ยงการทำลายเลย์เอาต์

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

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

ลดความล่าช้าของงานนำเสนอ

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

ลดขนาด DOM

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

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

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

ใช้ content-visibility เพื่อแสดงผลองค์ประกอบนอกหน้าจอแบบ Lazy

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

โปรดระวังต้นทุนด้านประสิทธิภาพเมื่อแสดงผล HTML โดยใช้ JavaScript

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

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

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

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

บทสรุป

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

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