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

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

Jeremy Wagner

Philip Walton

Barry Pollard

เผยแพร่: 19 พฤษภาคม 2023, อัปเดตล่าสุด: 9 กันยายน 2025

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

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

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

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

ค้นหาสาเหตุที่ทำให้ INP ต่ำ

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

ค้นหาการโต้ตอบที่ช้าในฟิลด์

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

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

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

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

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

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

การโต้ตอบแบ่งออกเป็น 3 ส่วนย่อยได้ดังนี้

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

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

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

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

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

ความสัมพันธ์ระหว่างการประเมินสคริปต์และ Long Task ระหว่างการเริ่มต้น

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

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

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

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

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

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

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

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

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

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

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

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

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

หลีกเลี่ยงการสลับเลย์เอาต์

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

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

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

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

ลดขนาด DOM

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

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

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

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

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