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

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

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

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

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

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

ระบุและลดความล่าช้าในการป้อนข้อมูล

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

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

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

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

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

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

โค้ดเรียกกลับของเหตุการณ์ Optimize

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

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

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

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

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

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

ให้ความสามารถในการแสดงผลเร็วขึ้น

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

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

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

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

ย่อขนาด DOM

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

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

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

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

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

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

เมื่อมี HTML จะต้องมีการแยกวิเคราะห์ HTML และหลังจากที่เบราว์เซอร์แยกวิเคราะห์ HTML เป็น 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