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

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

Jeremy Wagner

Philip Walton

การโต้ตอบกับ Next Paint (INP) เป็นเมตริก Core Web Vitals ที่เสถียร ซึ่งจะประเมินการตอบสนองโดยรวมของหน้าเว็บต่อการโต้ตอบของผู้ใช้ โดยการสังเกตเวลาในการตอบสนองของการโต้ตอบที่มีคุณสมบัติทั้งหมดที่เกิดขึ้นตลอดอายุการเข้าชมหน้าเว็บของผู้ใช้ ค่า INP สุดท้ายคือการโต้ตอบที่ยาวที่สุดที่สังเกตได้ (บางครั้งไม่สนใจข้อมูลผิดปกติทางสถิติ)

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

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

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

หาสาเหตุที่ทําให้ INP ไม่ดี

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

ค้นหาการโต้ตอบที่ช้าในช่องข้อมูล

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

หากคุณไม่ได้พึ่งพาผู้ให้บริการ RUM ในการขอข้อมูลภาคสนาม คำแนะนำเกี่ยวกับข้อมูลฟิลด์ INP ขอแนะนำให้ใช้รายงานประสบการณ์ของผู้ใช้ Chrome (CrUX) ผ่าน PageSpeed Insights เพื่อช่วยอุดช่องโหว่ CrUX คือชุดข้อมูลอย่างเป็นทางการของโปรแกรม Core Web Vitals และให้ข้อมูลสรุประดับสูงเกี่ยวกับเมตริกของเว็บไซต์หลายล้านแห่ง รวมถึง INP อย่างไรก็ตาม CrUX มักไม่ระบุข้อมูลตามบริบทที่คุณจะได้รับจากผู้ให้บริการ RUM เพื่อช่วยในการวิเคราะห์ปัญหา ด้วยเหตุนี้ เราจึงยังคงแนะนําให้เว็บไซต์ใช้ผู้ให้บริการ RUM หากเป็นไปได้ หรือติดตั้งใช้งานโซลูชัน RUM ของตนเองเพื่อเสริมข้อมูลที่มีอยู่ใน CrUX

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

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

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

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

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

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

ระบุและลดเวลาในการตอบสนองของอินพุต

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

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

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

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

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

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

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

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

ให้เทรดหลักบ่อยครั้ง

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

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

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

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

ยอมให้งานแสดงผลเกิดขึ้นเร็วขึ้น

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

ตัวอย่างเช่น ลองนึกถึงเครื่องมือแก้ไขข้อความแบบริชมีเดียที่จัดรูปแบบข้อความขณะที่คุณพิมพ์ แต่อัปเดตแง่มุมอื่นๆ ของ 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 ที่อาจทําให้เกิดความผันผวนของเลย์เอาต์

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

รูปภาพหลักจาก Unsplash โดย David Pisnoy และแก้ไขตามสัญญาอนุญาต Unsplash