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

Jeremy Wagner

การสนับสนุนเบราว์เซอร์

  • 96
  • 96
  • x
  • x

แหล่งที่มา

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

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

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

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

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

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

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

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

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

ประเด็นสำคัญ: สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับวิธีวัด INP โปรดดู "สิ่งที่อยู่ในการโต้ตอบ"

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

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

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

สิ่งที่อยู่ในการโต้ตอบ

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

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

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

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

ประเด็นสำคัญ: การวางเมาส์และการเลื่อนจะไม่ส่งผลต่อ INP อย่างไรก็ตาม การเลื่อนด้วยแป้นพิมพ์ (แป้นเว้นวรรค, Page Up, Page Down ฯลฯ) เกี่ยวข้องกับการกดแป้นพิมพ์ ซึ่งอาจทริกเกอร์เหตุการณ์อื่นๆ ที่ INP วัดได้ การเลื่อนที่ได้จะไม่มีผลต่อการคำนวณ INP

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

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

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

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

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

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

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

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

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

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

วิธีวัด INP

INP สามารถวัดได้ทั้งในภาคสนามและในห้องทดลองโดยใช้เครื่องมือที่หลากหลาย

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

ในพื้นที่

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

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

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

ในห้องทดลอง

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

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

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

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

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

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

หากคุณมีความคิดเห็นเกี่ยวกับเมตริกเหล่านี้ โปรดระบุไว้ในกลุ่ม Google web-vitals-feedback