การโต้ตอบกับ Next Paint (INP)

Jeremy Wagner

Barry Pollard

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

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

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

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

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

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

คู่มือนี้จะอธิบายวิธีการทำงานของ INP วิธีวัดค่า และชี้ไปยังแหล่งข้อมูลสำหรับการปรับปรุง

INP คืออะไร

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

การโต้ตอบคือกลุ่มตัวแฮนเดิลเหตุการณ์ที่เริ่มทำงานระหว่างท่าทางสัมผัสของผู้ใช้แบบตรรกะเดียวกัน ตัวอย่างเช่น การโต้ตอบ "แตะ" ในอุปกรณ์หน้าจอสัมผัสประกอบด้วยเหตุการณ์หลายอย่าง เช่น pointerup, pointerdown และ click การโต้ตอบอาจเกิดจาก JavaScript, CSS, ตัวควบคุมเบราว์เซอร์ในตัว (เช่น องค์ประกอบของแบบฟอร์ม) หรือการผสมผสานกัน

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

คะแนน INP ที่ดีคืออะไร

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

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

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

การโต้ตอบประกอบด้วยอะไรบ้าง

โดยทั่วไปแล้ว JavaScript มักเป็นตัวขับเคลื่อนหลักของการโต้ตอบ แม้ว่าเบราว์เซอร์จะมีการโต้ตอบผ่านตัวควบคุมที่ไม่ได้ขับเคลื่อนด้วย JavaScript เช่น ช่องทำเครื่องหมาย ปุ่มตัวเลือก และตัวควบคุมที่ขับเคลื่อนด้วย CSS

เนื่องจากวัตถุประสงค์ของ INP จึงสังเกตเฉพาะการโต้ตอบประเภทต่อไปนี้

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

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

การโต้ตอบอาจประกอบด้วยเหตุการณ์หลายอย่าง เช่น การกดแป้นจะรวมถึงเหตุการณ์ keydown, keypress และ keyup การแตะประกอบด้วยเหตุการณ์ pointerup และ pointerdown เหตุการณ์ที่มีระยะเวลานานที่สุดในการโต้ตอบคือเหตุการณ์ที่ทำให้เกิดเวลาในการตอบสนองทั้งหมดของการโต้ตอบ

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

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

INP แตกต่างจาก First Input Delay (FID) อย่างไร

INP เป็นเมตริกที่ต่อจาก First Input Delay (FID) แม้ว่าทั้ง 2 อย่างจะเป็นเมตริกการตอบสนอง แต่ FID จะวัดเฉพาะความล่าช้าในการป้อนข้อมูลของการโต้ตอบครั้งแรกในหน้าเว็บ INP ปรับปรุง FID โดยสังเกตการโต้ตอบทั้งหมดในหน้าเว็บ ตั้งแต่เวลาหน่วงของการป้อนข้อมูล ไปจนถึงเวลาที่ใช้ในการเรียกใช้ตัวแฮนเดิลเหตุการณ์ และสุดท้ายจนกว่าเบราว์เซอร์จะแสดงเฟรมถัดไป

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

จะเกิดอะไรขึ้นหากไม่มีการรายงานค่า INP

หน้าเว็บอาจไม่แสดงค่า INP ปัญหานี้อาจเกิดขึ้นได้จากหลายสาเหตุ เช่น

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

วิธีวัด INP

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

ในฟิลด์

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

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

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

ในห้องทดลอง

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

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

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

วัด INP ใน JavaScript

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

ในกรณีส่วนใหญ่ ค่า INP ปัจจุบัน ณ เวลาที่เลิกโหลดหน้าเว็บคือค่า INP สุดท้ายของหน้านั้น แต่ก็มีข้อยกเว้นที่สำคัญบางประการตามที่ระบุไว้ในส่วนถัดไป web vitals ไลบรารี JavaScript จะพิจารณาถึงเรื่องนี้ให้มากที่สุดภายในข้อจำกัดของ Web API

ความแตกต่างระหว่างเมตริกกับ API

• eventรายการที่ต่ำกว่า 104 มิลลิวินาทีจะไม่รายงานโดยค่าเริ่มต้นเมื่อใช้ Performance Observer ค่าเริ่มต้นนี้จะเปลี่ยนแปลงได้เมื่อลงทะเบียนเครื่องมือสังเกตการณ์ประสิทธิภาพโดยใช้พารามิเตอร์ durationThreshold แต่ค่านี้ก็ยังมีค่าต่ำสุดอยู่ที่ 16 มิลลิวินาที ด้วยเหตุนี้ เราจึงขอแนะนำให้สังเกตfirst-inputรายการด้วย ซึ่งเป็นรายการเวลาของเหตุการณ์เช่นกัน แต่รับประกันว่าจะสังเกตได้แม้ว่าระยะเวลาจะน้อยกว่า durationThreshold ซึ่งจะช่วยให้มั่นใจได้ว่าหน้าเว็บที่มีการโต้ตอบจะรายงานค่า INP เสมอ
• ในทางเทคนิคแล้ว การคำนวณเปอร์เซ็นไทล์อย่างสมบูรณ์แบบต้องเก็บตัวอย่างทั้งหมดไว้ในหน่วยความจำ ซึ่งอาจมีค่าใช้จ่ายสูง แต่คุณสามารถประมาณเปอร์เซ็นไทล์ได้ โดยเฉพาะเปอร์เซ็นไทล์ที่สูงมาก เช่น p98 เพียงแค่เก็บรายการเล็กๆ ของการโต้ตอบที่แย่ที่สุด N รายการ โดย 10 เป็นตัวเลือกที่นิยมใช้
• หากมีการกู้คืนหน้าเว็บจาก Back/Forward Cache ค่า INP ของหน้าเว็บนั้นควรได้รับการรีเซ็ตเป็น 0 เนื่องจากผู้ใช้จะถือว่าเป็นการเข้าชมหน้าเว็บที่แตกต่างกัน
• API ไม่รายงานรายการ event สำหรับการโต้ตอบที่เกิดขึ้นภายใน iframe แต่เมตริกจะรายงานเนื่องจากเป็นส่วนหนึ่งของประสบการณ์ของผู้ใช้ในหน้าเว็บ ซึ่งอาจแสดงเป็นความแตกต่างระหว่าง CrUX กับ RUM คุณควรพิจารณาเมตริกเหล่านี้เพื่อวัด INP อย่างเหมาะสม เฟรมย่อยสามารถใช้ API เพื่อรายงานรายการ event-timing ไปยังเฟรมหลักได้

นอกเหนือจากข้อยกเว้นเหล่านี้ INP ยังมีความซับซ้อนเพิ่มขึ้นเนื่องจากข้อเท็จจริงที่ว่าเมตริกนี้จะวัดอายุการใช้งานทั้งหมดของหน้าเว็บ

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

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

นักพัฒนาแอปสามารถใช้web-vitalsไลบรารี JavaScript เพื่อวัด INP ซึ่งจะพิจารณาทุกอย่างที่กล่าวถึงก่อนหน้านี้ ยกเว้นกรณี iframe แทนที่จะจดจำและจัดการกับกรณีเหล่านี้ด้วยตนเอง

import {onINP} from 'web-vitals';

// Measure and log INP in all situations
// where it needs to be reported.
onINP(console.log);

วิธีปรับปรุง INP

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

บันทึกการเปลี่ยนแปลง

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

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

หากมีความคิดเห็นเกี่ยวกับเมตริกเหล่านี้ โปรดแสดงความคิดเห็นใน Google Group web-vitals-feedback

ทดสอบความรู้ของคุณ