INP คืออะไร ตัวชี้วัด Core Web Vitals ที่มาแทน FID

INP คืออะไร และวัดอะไรกันแน่

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

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

ที่สำคัญคือ INP ไม่ได้เอาค่าทั้งหมดมาหาค่าเฉลี่ย แต่รายงานค่าที่แย่เกือบสุดของหน้านั้นออกมา เพราะมุมมองของ Google คือถ้าผู้ใช้เจอจังหวะที่กดแล้วค้างแม้เพียงไม่กี่ครั้ง ความรู้สึกว่าเว็บนี้ช้าก็เกิดขึ้นแล้ว ถ้ายังไม่เห็นภาพว่า INP วางตัวอยู่ตรงไหนในชุดตัวชี้วัดทั้งหมด อ่านภาพรวมทั้งสามตัวได้ที่ Core Web Vitals คืออะไร LCP INP CLS ก่อนแล้วค่อยกลับมาเจาะตัวนี้

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

สามช่วงเวลาที่ประกอบกันเป็นค่า INP

เวลาที่ INP วัดแบ่งออกเป็นสามท่อน ท่อนแรกคือ input delay ช่วงที่ผู้ใช้กดแล้วเบราว์เซอร์ยังเริ่มทำงานไม่ได้เพราะ main thread ติดงานอื่นค้างอยู่ ท่อนที่สองคือ processing time เวลาที่ event handler ของเราทำงานจริง และท่อนที่สามคือ presentation delay เวลาที่ใช้คำนวณ layout ใหม่แล้ววาดเฟรมออกจอ

การรู้ว่าเวลาหายไปท่อนไหนสำคัญมากเวลาแก้ปัญหา เพราะวิธีแก้คนละเรื่องกันโดยสิ้นเชิง ถ้าเสียเวลาที่ input delay ปัญหาอยู่ที่สคริปต์อื่นที่ทำงานคาอยู่ก่อนผู้ใช้จะกด ถ้าเสียที่ processing time ปัญหาอยู่ที่โค้ดใน handler ของเราเอง และถ้าเสียที่ presentation delay ปัญหามักอยู่ที่ DOM ใหญ่เกินหรือ CSS ที่ทำให้เบราว์เซอร์ต้องคำนวณใหม่ทั้งหน้า

ทำไม INP ถึงสะท้อนความรู้สึกของผู้ใช้ได้ตรงกว่า

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

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

ทำไม Google ถึงเลิกใช้ FID แล้วเปลี่ยนมาเป็น INP

เพราะ FID วัดได้แคบเกินไปจนทำให้เว็บที่หน่วงจริงยังสอบผ่านได้สบาย FID วัดแค่ input delay ของการโต้ตอบครั้งแรกครั้งเดียว ไม่ได้ดูว่า handler ทำงานนานแค่ไหน และไม่ได้ดูการโต้ตอบครั้งที่สองเป็นต้นไปเลย

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

ข้อควรระวังในทางปฏิบัติคือ เอกสาร บทความ หรือปลั๊กอินที่ยังวัดผลและรายงานเป็น FID อยู่ถือว่าใช้ข้อมูลเก่าแล้ว เพราะ FID ถูกปลดออกจาก Core Web Vitals ไปตั้งแต่ปี 2024 ถ้าทีมยังตั้ง KPI ด้าน performance ด้วย FID อยู่ ควรเปลี่ยนมาวัด INP แทนทั้งหมด

เกณฑ์ INP เท่าไหร่ถึงถือว่าผ่าน

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

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

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

• ดี (Good) — ไม่เกิน 200 มิลลิวินาที
• ต้องปรับปรุง (Needs Improvement) — 200 ถึง 500 มิลลิวินาที
• แย่ (Poor) — มากกว่า 500 มิลลิวินาที
• วัดที่เปอร์เซ็นไทล์ 75 ของการโหลดหน้าจริง แยกมือถือกับเดสก์ท็อป
• ใช้ข้อมูลผู้ใช้จริง (field data) ไม่ใช่ผลจากการทดสอบในเครื่อง

จะวัด INP ของเว็บตัวเองยังไง

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

ระดับที่ลึกขึ้นคือ Chrome DevTools ที่ Performance panel ใช้ไล่ดูว่าเวลาหายไปท่อนไหนของการโต้ตอบ เห็นเป็นแถบยาวของงานที่บล็อกอยู่จริงๆ และไลบรารี web-vitals ที่ฝังในเว็บเพื่อเก็บค่า INP ของผู้ใช้จริงส่งเข้าระบบวิเคราะห์ของเราเอง วิธีหลังนี้มีประโยชน์มากเพราะระบุได้ว่า element ไหนบนหน้าเป็นตัวที่ทำให้ค่าแย่ ซึ่ง CrUX ไม่ได้บอกให้

ข้อควรระวังที่คนพลาดบ่อยที่สุดคือ คะแนนจากการทดสอบในแล็บไม่การันตีค่า INP จริง เพราะ INP ต้องอาศัยการโต้ตอบของคนจริงถึงจะเกิดค่าได้ คะแนน Lighthouse สวยแต่ผู้ใช้จริงเจอหน่วงเป็นเรื่องที่เกิดขึ้นได้ตลอด วิธีดูรายงาน Core Web Vitals และไล่ดูทีละกลุ่ม URL อ่านต่อได้ที่ คู่มือใช้งาน Google Search Console

• PageSpeed Insights — ดูค่า INP ของผู้ใช้จริงรายหน้า พร้อมคำแนะนำจากฝั่งแล็บ
• Google Search Console รายงาน Core Web Vitals — ดูภาพรวมทั้งเว็บว่า URL กลุ่มไหนตก INP
• Chrome UX Report (CrUX) — ฐานข้อมูลผู้ใช้จริงที่เครื่องมือข้างบนดึงไปใช้
• Chrome DevTools Performance panel — ไล่หางานที่บล็อกระหว่างการโต้ตอบทีละจังหวะ
• ไลบรารี web-vitals — ฝังในเว็บเพื่อเก็บค่า INP ของผู้ใช้จริงและระบุ element ต้นเหตุ

สาเหตุที่ทำให้ INP แย่มีอะไรบ้าง

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

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

งาน JavaScript ก้อนใหญ่ที่บล็อก main thread

งานที่ใช้เวลาเกิน 50 มิลลิวินาทีต่อชิ้นเรียกว่า long tasks ระหว่างที่งานพวกนี้ทำอยู่ เบราว์เซอร์ตอบสนองอะไรไม่ได้เลย ถ้าผู้ใช้เผอิญกดตรงจังหวะนั้น เวลาที่รอทั้งหมดจะถูกนับเข้าเป็น input delay ของ INP เต็มๆ

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

event handler ที่ทำงานนานเกินจำเป็น

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

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

third-party script ที่มากเกินไป

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

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

DOM ใหญ่และ layout ที่คำนวณใหม่ทั้งหน้า

ยิ่ง DOM มี element เยอะและซ้อนลึก เบราว์เซอร์ยิ่งใช้เวลานานในการคำนวณ layout และวาดเฟรมใหม่ เวลาส่วนนี้ตกเป็น presentation delay ของ INP หน้าที่โหลดรายการยาวเป็นพันแถวโดยไม่มีการแบ่งหน้าเลยคือตัวอย่างคลาสสิกของปัญหานี้

อีกรูปแบบคือ layout thrashing ที่โค้ดสลับกันอ่านค่าขนาด element แล้วเขียนค่าสไตล์กลับไปซ้ำๆ ในลูปเดียว ทำให้เบราว์เซอร์ถูกบังคับให้คำนวณ layout ใหม่หลายสิบรอบในการโต้ตอบครั้งเดียว ทั้งที่จริงควรอ่านให้ครบก่อนแล้วค่อยเขียนทีเดียว

การ re-render ซ้ำซ้อนในเฟรมเวิร์กอย่าง React หรือ Next.js

ในเว็บที่สร้างด้วยเฟรมเวิร์กสมัยใหม่ การกดปุ่มหนึ่งครั้งอาจทำให้คอมโพเนนต์จำนวนมากถูก render ใหม่พร้อมกัน ทั้งที่จริงมีแค่ไม่กี่จุดบนหน้าที่เปลี่ยนค่า ปัญหานี้มักมาจากการวาง state ไว้สูงเกินไปในต้นไม้คอมโพเนนต์ หรือส่ง props ที่สร้างใหม่ทุกรอบลงไป

อาการจะหนักขึ้นเมื่อหน้าเดียวกันมีทั้งฟอร์ม ตาราง และกราฟอยู่ด้วยกัน เพราะการพิมพ์ในฟอร์มทีละตัวอักษรอาจลาก render ของตารางและกราฟไปด้วยทุกครั้ง ทำให้ค่า INP ของการพิมพ์แย่ลงอย่างชัดเจน

วิธีแก้ INP ให้กลับมาอยู่ในเกณฑ์ดี

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

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

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

• แตกงาน JavaScript ก้อนใหญ่เป็นชิ้นเล็ก แล้วคืนคิวให้เบราว์เซอร์ระหว่างทาง (break up long tasks)
• ใช้ debounce หรือ throttle กับ event handler ที่ทำงานหนักอย่างช่องค้นหาและการเลื่อนปรับค่า
• เลื่อนงานที่ไม่ต้องเห็นผลทันทีไปทำทีหลังด้วย requestIdleCallback หรือการ yield ของ scheduler
• ทำ code splitting และ lazy load ให้โหลดเฉพาะโค้ดที่หน้านั้นต้องใช้จริง
• ลดขนาด JavaScript bundle รวม และถอด third-party script ที่ไม่มีใครใช้ประโยชน์ออก
• ใช้ virtualization กับรายการยาว ให้ render เฉพาะแถวที่อยู่ในสายตาผู้ใช้
• ตอบสนองบนจอให้ผู้ใช้เห็นก่อน แล้วค่อยทำงานหนักเบื้องหลังต่อ

INP มีผลกับ SEO มากแค่ไหน

INP เป็นหนึ่งในสามตัวของ Core Web Vitals ซึ่งเป็นสัญญาณด้านประสบการณ์หน้าเว็บที่ Google ใช้ประกอบการจัดอันดับ แต่เป็นสัญญาณน้ำหนักเบาเมื่อเทียบกับความตรงประเด็นและคุณภาพของเนื้อหา ไม่ใช่ปุ่มวิเศษที่กดแล้วอันดับขยับ

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

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

สรุป: ควรเริ่มจับ INP จากตรงไหนก่อน

เริ่มจากดูรายงาน Core Web Vitals ใน Search Console ว่ามีกลุ่ม URL ไหนตก INP บ้าง แล้วเลือกหน้าที่มีทราฟฟิกสูงหรือเกี่ยวข้องกับรายได้ขึ้นมาก่อน จากนั้นใช้ PageSpeed Insights และ DevTools ไล่ดูว่าเวลาหายไปที่ input delay, processing time หรือ presentation delay

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

ถ้าไม่แน่ใจว่าเว็บของตัวเองติดตรงไหนหรือควรแก้อะไรก่อน บริการ ตรวจสุขภาพเว็บ SEO Audit ของ SEONo1 ช่วยไล่ดูทั้ง Core Web Vitals และงาน Technical SEO ส่วนอื่นให้เป็นลำดับได้