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

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

Jeremy Wagner

Philip Walton

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

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

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

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

ค้นหาสาเหตุของ INP ที่แย่

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

วันที่

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

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

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

ลดขนาด DOM

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

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

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

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

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