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

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

Jeremy Wagner

Philip Walton

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 แนะนำให้ใช้รายงานประสบการณ์ของผู้ใช้ 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 ทันที ทำให้เบราว์เซอร์ต้องทำงานการจัดวางแบบซิงค์ ซึ่งควรจะรอทำงานแบบแอซิงค์ในภายหลังหลังจากที่การเรียกกลับเหตุการณ์ทำงานเสร็จแล้ว

ลดเวลาในการตอบสนองของงานนำเสนอ

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

ลดขนาด DOM

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

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

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

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

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