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

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

Jeremy Wagner
Philip Walton
Barry Pollard

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

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

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

ค่า INP ที่ดีคือ 200 มิลลิวินาทีหรือน้อยกว่า ค่าที่ไม่ดีคือมากกว่า 500 มิลลิวินาที และค่าที่อยู่ระหว่างนั้นต้องได้รับการปรับปรุง
เกณฑ์ INP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

setTimeout เป็นวิธีหนึ่งในการแบ่งงาน เนื่องจาก Callback ที่ส่งไปยังฟังก์ชันนี้จะทำงานในงานใหม่ คุณใช้ 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);
  });
});

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