INP คืออะไร ทำไมกดปุ่มแล้วหน้าเว็บตอบสนองช้า
อธิบาย INP (Interaction to Next Paint) คืออะไร ต่างจาก First Input Delay ที่เคยใช้อย่างไร เกณฑ์ดี-ต้องปรับปรุง-แย่ตาม web.dev และแนวทางลด INP
ทีม NOAH · เผยแพร่ 2 กันยายน 2569 · อัปเดต 2 กันยายน 2569 · อ่าน 16 นาที
สรุปสั้น
- ✓INP วัดเวลาตั้งแต่ผู้ใช้โต้ตอบกับหน้าเว็บ เช่นคลิกหรือพิมพ์ จนถึงตอนที่หน้าจอแสดงผลตอบกลับ
- ✓เกณฑ์ตาม web.dev คือดีที่ 200 มิลลิวินาทีหรือน้อยกว่า ต้องปรับปรุงที่ 200-500 มิลลิวินาที และแย่ที่มากกว่า 500 มิลลิวินาที
- ✓INP เข้ามาแทนที่ First Input Delay (FID) เพราะวัดการตอบสนองตลอดช่วงที่ผู้ใช้อยู่ในหน้า ไม่ใช่แค่การโต้ตอบครั้งแรก
- ✓สาเหตุหลักของ INP ช้ามักมาจาก JavaScript ที่ทำงานหนักบน main thread จนบล็อกการตอบสนองของเบราว์เซอร์
- ✓NOAH ไม่ได้วัดหรือแก้ค่า INP ของเว็บโดยตรง งานนี้เป็นหน้าที่ของทีมพัฒนาเว็บร่วมกับเครื่องมืออย่าง PageSpeed Insights
กดปุ่ม “เพิ่มลงตะกร้า” แล้วหน้าจอนิ่งไปครึ่งวินาทีก่อนมีอะไรเกิดขึ้น เป็นประสบการณ์ที่ทำให้ผู้ใช้กดซ้ำเพราะคิดว่าไม่ทำงาน สุดท้ายกลายเป็นสั่งซื้อซ้ำโดยไม่ตั้งใจ ปัญหานี้วัดได้ด้วยค่าที่ชื่อว่า INP ซึ่งเป็นหนึ่งในสามค่าของ Core Web Vitals
INP เป็นค่าที่ค่อนข้างใหม่เมื่อเทียบกับ LCP และ CLS เพราะเข้ามาแทนที่ First Input Delay (FID) ที่เคยใช้ในอดีต บทความนี้อธิบายว่า INP วัดอะไรต่างจาก FID อย่างไร และแนวทางลดค่านี้ที่ใช้ได้จริง ดูบทความอื่นในหมวดTechnical SEO เพิ่มเติมได้ที่นี่
แม้เจ้าของธุรกิจส่วนใหญ่จะไม่ได้เขียนโค้ดเอง แต่การเข้าใจว่า INP คืออะไรและกระทบธุรกิจอย่างไร ช่วยให้คุยกับทีมพัฒนาเว็บหรือฟรีแลนซ์ที่จ้างมาได้ตรงประเด็นมากขึ้น แทนที่จะได้ยินแค่คำว่า 'เว็บช้า' แบบกว้าง ๆ โดยไม่รู้ว่าช้าตรงจุดไหนกันแน่
INP คืออะไร
INP คืออะไร
INP หรือ Interaction to Next Paint คือหนึ่งในสามค่าของ Core Web Vitals ที่วัดระยะเวลาตั้งแต่ผู้ใช้โต้ตอบกับหน้าเว็บ เช่นคลิกปุ่ม แตะหน้าจอ หรือกดปุ่มคีย์บอร์ด จนถึงตอนที่เบราว์เซอร์แสดงผลการตอบสนองกลับมาให้เห็น ตามเกณฑ์ของ web.dev ค่า INP ที่ดีคือ 200 มิลลิวินาทีหรือน้อยกว่า ต้องปรับปรุงคือ 200 ถึง 500 มิลลิวินาที และแย่คือมากกว่า 500 มิลลิวินาที
จุดสำคัญของ INP คือมันวัด “ทุกการโต้ตอบ” ตลอดช่วงที่ผู้ใช้อยู่ในหน้า แล้วรายงานค่าที่แย่ที่สุด (หรือใกล้แย่ที่สุด) จากทั้งหมด ไม่ใช่วัดแค่ครั้งแรกครั้งเดียว หมายความว่าหน้าเว็บที่โต้ตอบเร็วตอนแรกแต่ช้าลงหลังโหลด JavaScript เพิ่มเติม ก็ยังนับว่ามีปัญหา INP อยู่ดี ดูภาพรวมทั้งสามค่าที่ Core Web Vitals คือ
ลองนึกภาพร้านอาหารที่พนักงานรับออเดอร์เร็วมากในตอนที่ลูกค้าเข้ามาคนแรก แต่พอร้านเริ่มมีลูกค้าหลายโต๊ะพร้อมกัน พนักงานเริ่มรับออเดอร์ช้าลงเพราะมืองานเยอะขึ้น INP ก็เหมือนการวัดว่าพนักงานร้านนี้ (เบราว์เซอร์) ตอบสนองลูกค้าได้เร็วแค่ไหนตลอดทั้งมื้อ ไม่ใช่แค่ตอนต้อนรับลูกค้าคนแรกเท่านั้น
INP ต่างจาก First Input Delay (FID) อย่างไร
| ประเด็น | FID (เดิม) | INP (ปัจจุบัน) |
|---|---|---|
| วัดอะไร | ความล่าช้าก่อนเบราว์เซอร์เริ่มประมวลผลการโต้ตอบครั้งแรก | เวลาทั้งหมดตั้งแต่โต้ตอบจนหน้าจอแสดงผลตอบกลับ ตลอดทั้งเซสชัน |
| จำนวนครั้งที่วัด | ครั้งแรกที่ผู้ใช้โต้ตอบเท่านั้น | ทุกการโต้ตอบตลอดที่อยู่ในหน้า |
| สะท้อนปัญหาได้ครบแค่ไหน | จำกัด อาจพลาดปัญหาที่เกิดหลังโหลดหน้าเสร็จไปแล้ว | ครอบคลุมกว่า สะท้อนประสบการณ์จริงตลอดการใช้งาน |
เหตุผลที่ Google เปลี่ยนมาใช้ INP แทน FID คือทีมงานพบว่าเว็บจำนวนมากผ่านเกณฑ์ FID ได้สบาย ๆ เพราะวัดแค่การโต้ตอบครั้งแรก แต่ผู้ใช้จริงกลับบ่นว่าเว็บ 'หน่วง' เวลาคลิกปุ่มอื่น ๆ ต่อไป โดยเฉพาะเว็บที่โหลด JavaScript เพิ่มขึ้นเรื่อย ๆ หลังหน้าแรกแสดงผล FID จึงไม่สะท้อนปัญหาจริงที่ผู้ใช้เจอ INP จึงถูกออกแบบมาให้ครอบคลุมประสบการณ์ทั้งหมด ไม่ใช่แค่ช่วงเวลาสั้น ๆ ตอนเริ่มต้น
อะไรทำให้ INP ช้า
- JavaScript ที่ทำงานหนักบน main thread ระหว่างที่ผู้ใช้กำลังโต้ตอบ ทำให้เบราว์เซอร์ไม่ว่างมาตอบสนอง
- event handler ที่ทำงานซับซ้อนเกินจำเป็น เช่นคำนวณหรือประมวลผลข้อมูลจำนวนมากทุกครั้งที่มีการคลิก
- การอัปเดต DOM จำนวนมากพร้อมกันหลังการโต้ตอบหนึ่งครั้ง ทำให้เบราว์เซอร์ต้องคำนวณการแสดงผลใหม่ทั้งหมด
- สคริปต์จากบุคคลที่สาม เช่นโฆษณาหรือเครื่องมือติดตามพฤติกรรม ที่แย่งการประมวลผลของ main thread
- รูปภาพหรือฟอนต์ที่ยังโหลดไม่เสร็จตอนผู้ใช้เริ่มโต้ตอบ ทำให้เบราว์เซอร์ต้องจัดการหลายงานพร้อมกัน
ตัวอย่างสมมติ: เว็บร้านขายเสื้อผ้าออนไลน์
สมมติเว็บร้าน 'แฟชั่นเทรนด์' มีปุ่ม 'เพิ่มลงตะกร้า' ที่ทำงานหลายอย่างพร้อมกันตอนคลิก เช่น อัปเดตจำนวนสินค้าในตะกร้าที่มุมบนขวา แสดง popup แจ้งเตือน และส่งข้อมูลไปเก็บสถิติการตลาดพร้อมกันทั้งหมด ถ้าทั้งสามงานนี้ทำงานแบบต่อเนื่องบน main thread โดยไม่มีการแบ่งจังหวะ ผู้ใช้จะเห็นว่าปุ่มค้างไปครึ่งวินาทีก่อนมีอะไรเกิดขึ้น ทำให้บางคนกดซ้ำเพราะคิดว่าปุ่มไม่ทำงาน กลายเป็นเพิ่มสินค้าซ้ำสองชิ้นโดยไม่ตั้งใจ
เชื่อมโยงกับ JavaScript SEO
เว็บที่พึ่งพา JavaScript หนักตั้งแต่การ render เนื้อหาไปจนถึงการโต้ตอบ มักเจอปัญหาทั้งเรื่อง index และเรื่อง INP พร้อมกัน อ่านความเชื่อมโยงเพิ่มเติมที่ JavaScript SEO
แนวทางลด INP
แนวทางที่ทีมพัฒนาเว็บใช้ลด INP
- 1
แบ่งงาน JavaScript ก้อนใหญ่ออกเป็นชิ้นเล็ก
แทนที่จะรันโค้ดยาวต่อเนื่องจนบล็อก main thread ให้แบ่งเป็นงานย่อยที่คืน control ให้เบราว์เซอร์เป็นระยะ เพื่อให้ยังตอบสนองการโต้ตอบของผู้ใช้ได้
- 2
ลดงานที่ไม่จำเป็นออกจาก event handler
ตรวจว่า event handler ทำงานเฉพาะสิ่งที่จำเป็นจริงต่อการตอบสนองทันที ส่วนงานที่รอได้ให้เลื่อนไปทำภายหลัง
- 3
ลดจำนวนสคริปต์จากบุคคลที่สาม
ทบทวนว่าสคริปต์ติดตามหรือโฆษณาที่ติดตั้งไว้ยังจำเป็นทั้งหมดหรือไม่ และโหลดเฉพาะที่จำเป็นด้วยวิธีที่ไม่บล็อก main thread
- 4
ใช้เทคนิคอัปเดต DOM อย่างมีประสิทธิภาพ
รวมการเปลี่ยนแปลง DOM หลายจุดให้เกิดพร้อมกันในรอบเดียว แทนที่จะสั่งอัปเดตทีละจุดหลายรอบ ซึ่งทำให้เบราว์เซอร์คำนวณ layout ซ้ำโดยไม่จำเป็น
- 5
ทดสอบซ้ำหลังแก้ไขทุกครั้ง
ใช้ PageSpeed Insights หรือ Chrome DevTools วัดค่า INP ใหม่หลังแก้ไขแต่ละจุด เพื่อยืนยันว่าการแก้ไขได้ผลจริงก่อนไปแก้จุดถัดไป
แล้วเว็บที่ใช้ปลั๊กอินสำเร็จรูปล่ะ เจอปัญหานี้ไหม
เว็บที่สร้างจาก WordPress หรือแพลตฟอร์มสำเร็จรูปอื่น ๆ ก็เจอปัญหา INP ได้เช่นกัน โดยเฉพาะเมื่อติดตั้งปลั๊กอินจำนวนมากที่แต่ละตัวแทรก JavaScript ของตัวเองเข้าไปในหน้าเว็บ ยิ่งปลั๊กอินเยอะ ยิ่งมีโอกาสที่สคริปต์หลายตัวแย่งกันทำงานบน main thread พร้อมกัน ทำให้ปุ่มหรือฟอร์มต่าง ๆ ตอบสนองช้าลงโดยที่เจ้าของเว็บอาจไม่รู้ตัวว่าสาเหตุมาจากปลั๊กอินที่ติดตั้งไว้ ทางแก้เบื้องต้นคือทบทวนว่าปลั๊กอินที่ติดตั้งไว้ทั้งหมดยังจำเป็นจริงหรือไม่ แล้วปิดหรือถอดตัวที่ไม่ได้ใช้งานแล้วออก
ผลกระทบของ INP ต่อธุรกิจจริง
แม้ INP จะเป็นค่าทางเทคนิคที่ฟังดูไกลตัว แต่ผลกระทบที่เกิดขึ้นจริงกับธุรกิจนั้นชัดเจนมาก โดยเฉพาะเว็บที่มีการซื้อขายหรือกรอกฟอร์มออนไลน์ ปุ่มที่ตอบสนองช้าทำให้ลูกค้ารู้สึกไม่มั่นใจว่าระบบทำงานถูกต้อง บางคนอาจปิดหน้าเว็บไปเลยก่อนที่จะกดยืนยันคำสั่งซื้อสำเร็จ ซึ่งหมายถึงยอดขายที่เสียไปโดยที่เจ้าของธุรกิจอาจไม่รู้สาเหตุที่แท้จริง
ปัญหาที่มองไม่เห็นด้วยตาเปล่าเสมอไป
บางครั้งเจ้าของธุรกิจทดสอบเว็บเองบนคอมพิวเตอร์ที่แรงและอินเทอร์เน็ตดี แล้วรู้สึกว่าเว็บเร็วดี ทั้งที่ลูกค้าจริงส่วนใหญ่ใช้มือถือรุ่นทั่วไปที่ประมวลผลได้ช้ากว่า ทำให้ปัญหา INP ที่ลูกค้าเจอจริงไม่ถูกตรวจพบจนกว่าจะดูข้อมูล Field Data จาก PageSpeed Insights ซึ่งเก็บจากผู้ใช้จริง
ข้อผิดพลาดที่เจอบ่อย
- ยังอ้างอิงค่า FID เดิมในการประเมินความเร็ว ทั้งที่ Google เปลี่ยนมาใช้ INP เป็นตัวชี้วัดหลักแล้ว
- ทดสอบ INP เฉพาะการคลิกครั้งแรกของหน้า โดยไม่ทดสอบการโต้ตอบซ้ำหลายครั้งที่ผู้ใช้จริงมักทำ
- ไม่ตรวจสอบผลกระทบของสคริปต์บุคคลที่สามที่เพิ่มเข้ามาทีหลัง เช่นตัวติดตามการตลาดใหม่ ๆ
- แก้ปัญหาที่ frontend อย่างเดียว โดยไม่ได้ดูว่าโครงสร้างข้อมูลหรือ state management ของแอปทำให้ต้องคำนวณซ้ำซ้อนโดยไม่จำเป็น
- ทดสอบเฉพาะบนคอมพิวเตอร์แรง ๆ ของทีมพัฒนา โดยไม่ทดสอบบนมือถือระดับกลางถึงล่างที่ลูกค้าส่วนใหญ่ใช้จริง
เช็กลิสต์สรุปสำหรับเจ้าของธุรกิจที่จ้างทีมพัฒนาเว็บ
| สิ่งที่ควรถาม | คำตอบที่ดี |
|---|---|
| ตรวจ INP ล่าสุดเมื่อไร | มีการตรวจสอบเป็นระยะ ไม่ใช่แค่ตอนส่งมอบงานครั้งแรก |
| ค่า INP ปัจจุบันอยู่ระดับไหน | ตอบได้ชัดเจนว่าดี ต้องปรับปรุง หรือแย่ ตามเกณฑ์ของ web.dev |
| สคริปต์บุคคลที่สามมีกี่ตัว | รู้จำนวนและเหตุผลที่ต้องใช้แต่ละตัวชัดเจน |
| ทดสอบบนอุปกรณ์แบบไหน | ทดสอบครอบคลุมทั้งมือถือระดับกลางและคอมพิวเตอร์ |
คำถามที่พบบ่อย
INP มาแทน FID ตั้งแต่เมื่อไร+
Google ประกาศให้ INP เข้ามาแทนที่ FID ในกลุ่ม Core Web Vitals อย่างเป็นทางการ หลังจากเก็บข้อมูลและทดสอบมาระยะหนึ่ง เพราะ INP สะท้อนประสบการณ์การโต้ตอบได้ครอบคลุมกว่า
การโต้ตอบแบบไหนบ้างที่ถูกนับในการวัด INP+
ครอบคลุมการคลิกด้วยเมาส์ การแตะบนหน้าจอสัมผัส และการกดปุ่มคีย์บอร์ด ไม่รวมการเลื่อนหน้าจอ (scroll) หรือการซูม เพราะสองอย่างหลังนี้เบราว์เซอร์จัดการแยกต่างหากอยู่แล้ว
เว็บที่มี JavaScript น้อยจะมี INP ดีเสมอไปไหม+
โดยทั่วไปมีแนวโน้มดีกว่า เพราะมี main thread ว่างมากกว่า แต่ก็ไม่ใช่การันตีเสมอไป ถ้าโค้ดที่มีอยู่เขียนไม่มีประสิทธิภาพ เช่นมี loop ที่หนักผิดปกติ ก็ยังทำให้ INP แย่ได้แม้โค้ดจะมีปริมาณน้อย
ตรวจ INP ของเว็บได้จากที่ไหน+
ตรวจได้จาก PageSpeed Insights ซึ่งแสดงค่า INP จากข้อมูล Field Data จริงถ้าเว็บมีทราฟฟิกเพียงพอ อ่านวิธีใช้เครื่องมือนี้ที่ PageSpeed SEO
INP มีผลกับเว็บที่มีเนื้อหาเป็นบทความอ่านอย่างเดียวไหม+
มีผลน้อยกว่าเว็บที่มีการโต้ตอบเยอะ เช่นแบบฟอร์มหรือระบบสั่งซื้อ แต่ยังมีความสำคัญกับส่วนที่ผู้อ่านโต้ตอบได้ เช่นเมนู ช่องค้นหา หรือปุ่มแชร์บทความ ซึ่งพบได้ในเกือบทุกเว็บ
ธุรกิจที่ไม่มีทีมพัฒนาเว็บเอง ควรทำอย่างไรกับปัญหา INP+
เริ่มจากตรวจค่า INP ผ่าน PageSpeed Insights ก่อนเพื่อรู้ว่าเว็บอยู่ระดับไหน แล้วนำผลลัพธ์ไปปรึกษากับทีมพัฒนาเว็บหรือฟรีแลนซ์ที่ดูแลเว็บอยู่ เพื่อให้แก้ไขตรงจุดโดยไม่ต้องเดา
สรุป
INP คือค่าที่วัดว่าเว็บ “ตอบสนอง” ต่อผู้ใช้เร็วแค่ไหนตลอดช่วงที่ใช้งาน ไม่ใช่แค่ครั้งแรกครั้งเดียวเหมือน FID ในอดีต การลด INP ต้องโฟกัสที่การจัดการ JavaScript บน main thread และลดงานที่ไม่จำเป็นออกจากการโต้ตอบแต่ละครั้ง ตรวจค่านี้เบื้องต้นได้ด้วยเครื่องมือ SEO
สำหรับเจ้าของธุรกิจที่ไม่ได้ลงมือแก้โค้ดเอง สิ่งที่ทำได้คือหมั่นตรวจค่า INP เป็นระยะผ่าน PageSpeed Insights และนำผลไปคุยกับทีมพัฒนาเว็บอย่างตรงจุด แทนที่จะรอให้ลูกค้าบ่นเรื่องเว็บช้าก่อนถึงจะรู้ว่ามีปัญหา การตรวจเป็นประจำช่วยจับปัญหาได้ตั้งแต่ยังเล็ก ก่อนที่จะกระทบยอดขายในวงกว้าง
เว็บตอบสนองเร็วต้องมาคู่กับเนื้อหาที่ตรงใจผู้ค้นหา
ขณะที่ทีมพัฒนาดูแลเรื่องการตอบสนองของเว็บ NOAH ช่วยวางแผนคีย์เวิร์ดและผลิตเนื้อหา SEO ให้พร้อมนำไปเผยแพร่ควบคู่กัน
เริ่มต้นใช้งาน