เคยไหม คุณกดเมนูบนเว็บไซต์แล้วหน้าจอนิ่ง กดปุ่มสั่งซื้อแต่ไม่มีอะไรเกิดขึ้นทันที หรือพิมพ์ในช่องค้นหาแล้วตัวอักษรตามหลังนิ้วเป็นจังหวะ อาการเหล่านี้คือสิ่งที่ INP หรือ Interaction to Next Paint ใช้วัด โดยดูว่าเว็บไซต์ตอบสนองและแสดงผลหลังการโต้ตอบของผู้ใช้ได้เร็วเพียงใด ปัจจุบัน INP เป็นหนึ่งใน Core Web Vitals และเข้ามาแทน FID อย่างเป็นทางการตั้งแต่วันที่ 12 มีนาคม 2024
อ้างอิงแนวทางการวัดและปรับปรุง INP อย่างเป็นทางการเพิ่มเติมได้ที่ web.dev ของ Google
INP คืออะไร และวัดอะไรบนเว็บไซต์?
INP ย่อมาจาก Interaction to Next Paint เป็นตัวชี้วัดความเร็วในการตอบสนองของหน้าเว็บ ตั้งแต่ผู้ใช้เริ่มคลิก แตะหน้าจอ หรือกดแป้นพิมพ์ จนถึงเวลาที่เบราว์เซอร์วาดผลลัพธ์ใหม่ให้ผู้ใช้มองเห็น
ตัวอย่างเช่น เมื่อคุณกดปุ่ม “เพิ่มลงตะกร้า” ระบบอาจต้องประมวลผล JavaScript คำนวณราคา อัปเดตจำนวนสินค้า และแสดงข้อความยืนยัน INP จะนับเวลาตั้งแต่เริ่มกดปุ่มจนกระทั่งการเปลี่ยนแปลงปรากฏบนหน้าจอ ไม่ได้วัดแค่เวลาที่ระบบเริ่มรับคำสั่งเท่านั้น
การตอบสนองหนึ่งครั้งประกอบด้วยเวลาหลักสามช่วง ได้แก่
- Input delay: เวลาที่คำสั่งต้องรอก่อนเบราว์เซอร์เริ่มประมวลผล
- Processing time: เวลาที่ JavaScript และ event handler ใช้ทำงาน
- Presentation delay: เวลาที่เบราว์เซอร์คำนวณเลย์เอาต์และวาดผลลัพธ์ใหม่
INP พิจารณาการโต้ตอบที่เกิดขึ้นตลอดช่วงเวลาที่ผู้ใช้เปิดหน้าเว็บ เช่น การคลิก การแตะ และการใช้คีย์บอร์ด จากนั้นรายงานค่าการตอบสนองที่ช้าที่สุดหรือใกล้เคียงค่าที่ช้าที่สุด โดยมีการตัดค่าผิดปกติบางส่วนเมื่อหน้ามีการโต้ตอบจำนวนมาก แนวคิดนี้ทำให้ INP สะท้อนประสบการณ์จริงได้ครอบคลุมกว่าเดิม
ทำไม INP จึงเข้ามาแทน FID?
FID หรือ First Input Delay มีข้อจำกัดสำคัญ เพราะวัดเพียงความล่าช้าก่อนเริ่มประมวลผลของ การโต้ตอบครั้งแรก เท่านั้น หากหน้าเว็บตอบสนองเร็วตอนผู้ใช้กดครั้งแรก แต่เริ่มช้าเมื่อเปิดเมนู เลือกสินค้า หรือกรอกแบบฟอร์มภายหลัง ค่า FID อาจยังดูดีอยู่
นอกจากนี้ FID ไม่ได้รวมเวลาที่ JavaScript ใช้ทำงานหรือเวลาที่เบราว์เซอร์วาดหน้าจอใหม่ จึงอาจเกิดสถานการณ์ที่รายงานบอกว่าเว็บไซต์เร็ว แต่ผู้ใช้กลับรู้สึกว่าปุ่มกดแล้วค้าง
INP แก้ข้อจำกัดนี้ด้วยการวัดวงจรการตอบสนองตั้งแต่ต้นจนผู้ใช้เห็นผล และติดตามการโต้ตอบตลอดการเข้าชมหน้า Google จึงนำ INP มาแทน FID ใน Core Web Vitals อย่างเป็นทางการเมื่อวันที่ 12 มีนาคม 2024 และยุติการรองรับ FID ในเครื่องมือของ Chrome ภายหลัง
สรุปความต่างระหว่าง INP และ FID แบบง่าย
- FID: วัดเฉพาะระยะรอก่อนเริ่มจัดการ interaction ครั้งแรก
- INP: วัดการตอบสนองตั้งแต่เริ่มโต้ตอบจนหน้าจอแสดงผลใหม่
- FID: อาจพลาดปัญหาที่เกิดขึ้นหลังผู้ใช้ใช้งานหน้าเว็บไปแล้ว
- INP: ตรวจการโต้ตอบตลอดช่วงเวลาที่ผู้ใช้เปิดหน้าเว็บ
ดังนั้น เว็บไซต์ที่เคยผ่าน FID ไม่ได้หมายความว่าจะผ่าน INP โดยอัตโนมัติ โดยเฉพาะเว็บ WordPress ที่มีปลั๊กอินและสคริปต์ทำงานหลังโหลดหน้าเสร็จแล้ว
ค่า INP เท่าไรจึงถือว่าดี?
Google แบ่งระดับ INP ตามเวลาตอบสนองดังนี้
- ไม่เกิน 200 มิลลิวินาที: ดี
- มากกว่า 200 ถึง 500 มิลลิวินาที: ควรปรับปรุง
- มากกว่า 500 มิลลิวินาที: ไม่ดี
การประเมิน Core Web Vitals ใช้ข้อมูลเปอร์เซ็นไทล์ที่ 75 หรือพูดง่าย ๆ ว่า เว็บไซต์ควรทำคะแนนได้ดีสำหรับผู้ใช้อย่างน้อยประมาณ 75% โดยแยกข้อมูลระหว่างอุปกรณ์มือถือและเดสก์ท็อป
อย่าดูเฉพาะค่าเฉลี่ย เพราะผู้ใช้มือถือระดับกลาง อินเทอร์เน็ตช้า หรือเครื่องที่มี CPU ไม่แรง อาจได้รับประสบการณ์ต่างจากคอมพิวเตอร์ที่คุณใช้ทดสอบในสำนักงานอย่างมาก
INP มีผลต่อ SEO และธุรกิจอย่างไร?
Core Web Vitals เป็นหนึ่งในสัญญาณที่ระบบจัดอันดับของ Google ใช้ประเมินประสบการณ์หน้าเว็บ แต่การทำคะแนนดีไม่ได้รับประกันว่าเว็บไซต์จะขึ้นอันดับหนึ่ง เนื้อหา ความเกี่ยวข้อง ความน่าเชื่อถือ และลิงก์ยังคงมีความสำคัญกว่าในหลายกรณี
ผลกระทบทางธุรกิจของ INP มักเห็นชัดกว่าเรื่องอันดับเสียอีก ลองนึกถึงผู้ใช้ที่กดปุ่มชำระเงินแล้วไม่มีการตอบสนองภายในครึ่งวินาที หลายคนจะกดซ้ำ ย้อนกลับ หรือคิดว่าระบบเสีย สิ่งที่ตามมาอาจเป็นคำสั่งซื้อซ้ำ แบบฟอร์มถูกส่งหลายครั้ง หรือผู้ใช้เลิกซื้อกลางทาง
หน้าเว็บที่ควรให้ความสำคัญเป็นพิเศษ ได้แก่
- หน้าสินค้าและปุ่มเพิ่มลงตะกร้า
- หน้าชำระเงินและเลือกวิธีจัดส่ง
- แบบฟอร์มติดต่อ สมัครสมาชิก และจองบริการ
- เมนูมือถือ ตัวกรองสินค้า และระบบค้นหา
- หน้าแดชบอร์ดหรือเว็บแอปที่มีการคลิกจำนวนมาก
อย่างไรก็ตาม คะแนน INP ต่ำไม่ใช่ Google Penalty และไม่ได้หมายความว่าเว็บถูกลงโทษโดยตรง แต่เป็นสัญญาณว่าประสบการณ์ใช้งานบางส่วนยังช้ากว่าที่ควร
ตรวจค่า INP ได้จากเครื่องมืออะไรบ้าง?
1. Google Search Console
รายงาน Core Web Vitals ใน Search Console เหมาะสำหรับดูภาพรวมจากผู้ใช้จริง ระบบจะแบ่ง URL ออกเป็นกลุ่มดี ควรปรับปรุง และไม่ดี ช่วยให้คุณเห็นว่าปัญหาเกิดเฉพาะบางหน้า หรือกระทบทั้งรูปแบบหน้าเว็บไซต์
ข้อจำกัดคือข้อมูลจะไม่เปลี่ยนทันทีหลังแก้เว็บไซต์ เพราะต้องรอข้อมูลจากผู้ใช้จริงสะสมก่อน จึงควรใช้เครื่องมือทดสอบอื่นประกอบระหว่างพัฒนา
2. PageSpeed Insights
PageSpeed Insights แสดงข้อมูลภาคสนามจาก Chrome User Experience Report หาก URL หรือโดเมนมีข้อมูลเพียงพอ ค่า INP ในส่วนนี้จึงสะท้อนประสบการณ์ของผู้ใช้จริง ไม่ใช่การจำลองเพียงครั้งเดียว
จุดที่หลายคนสับสนคือ Lighthouse ในส่วนข้อมูลจำลองอาจไม่แสดงค่า INP โดยตรง เพราะการทดสอบโหลดหน้าอัตโนมัติไม่ได้มีผู้ใช้คลิกปุ่ม คุณอาจเห็น Total Blocking Time หรือ TBT แทน ซึ่งใช้ช่วยวิเคราะห์ภาระบน main thread ได้ แต่ไม่ใช่ค่าเดียวกับ INP
3. Chrome DevTools
เปิดหน้าเว็บใน Chrome แล้วใช้แถบ Performance เพื่อบันทึกขณะทดลองกดเมนู เปิดป๊อปอัป เลือกตัวกรอง หรือเพิ่มสินค้าลงตะกร้า คุณจะเห็นได้ว่า interaction ใดช้า และเวลาหมดไปกับ JavaScript การคำนวณเลย์เอาต์ หรือการวาดหน้าจอ
แนวทางที่ได้ผลคืออย่าทดสอบเพียงปุ่มเดียว ให้สร้างรายการ “เส้นทางใช้งานสำคัญ” เช่น เปิดเมนู → ค้นหาสินค้า → เลือกตัวเลือก → เพิ่มลงตะกร้า → เปิดตะกร้า แล้วตรวจทีละจุด
สาเหตุที่ทำให้ INP สูงในเว็บ WordPress
รูปแบบปัญหาที่พบบ่อยในเว็บไซต์ WordPress ไม่ได้มาจากเซิร์ฟเวอร์ช้าเพียงอย่างเดียว แต่เกิดจากงานที่เบราว์เซอร์ต้องประมวลผลหลังผู้ใช้เริ่มโต้ตอบ เช่น
- ปลั๊กอินหลายตัวโหลด JavaScript ซ้ำซ้อนหรือทำงานทุกหน้า
- Page Builder สร้าง DOM ขนาดใหญ่และมีเอฟเฟกต์จำนวนมาก
- สคริปต์โฆษณา แชต Heatmap และระบบติดตามหลายชุดแย่งใช้ main thread
- เมนู Mega Menu ตัวกรองสินค้า หรือ Variation ของ WooCommerce ประมวลผลหนัก
- Event handler ทำงานหลายขั้นตอนก่อนแสดงสถานะตอบรับให้ผู้ใช้
- JavaScript อ่านและแก้เลย์เอาต์สลับกันจนเกิด Forced Synchronous Layout
ปลั๊กอินแคชอาจช่วยให้หน้าโหลดเร็วขึ้น แต่ไม่ได้แก้ INP ทุกกรณี เพราะ Cache เว็บไซต์และ WordPress เน้นลดเวลาสร้างและส่งหน้าเป็นหลัก หากปุ่มช้าเพราะ JavaScript หนัก คุณต้องแก้ที่สคริปต์และกระบวนการตอบสนองโดยตรง
วิธีปรับปรุง INP บน WordPress แบบทำตามได้จริง
1. หา interaction ที่ช้าก่อนติดตั้งปลั๊กอินเพิ่ม
เริ่มจากทดสอบเมนูมือถือ ช่องค้นหา ปุ่มเพิ่มลงตะกร้า แบบฟอร์ม และป๊อปอัป บันทึกผลด้วย Chrome DevTools แล้วระบุให้ได้ว่า interaction ไหนใช้เวลานาน การเพิ่มปลั๊กอิน Performance โดยยังไม่รู้สาเหตุ อาจเพิ่ม JavaScript และทำให้ปัญหาหนักกว่าเดิม
2. ลด JavaScript ที่ไม่จำเป็น
ปิดฟังก์ชันของธีมหรือปลั๊กอินที่ไม่ได้ใช้ เช่น Animation, Slider, Social Feed และ Widget บางชนิด ตรวจสอบด้วยว่ามีระบบ Analytics, Pixel หรือ Chat ซ้ำกันหรือไม่ จากนั้นโหลดสคริปต์เฉพาะหน้าที่ต้องใช้ แทนการโหลดทุกไฟล์ทั่วทั้งเว็บไซต์
การใช้ฟังก์ชัน Delay JavaScript ช่วยได้ในบางเว็บ แต่ต้องทดสอบเมนู แบบฟอร์ม และการสั่งซื้อทุกครั้ง เพราะการหน่วงสคริปต์ผิดตัวอาจทำให้ปุ่มใช้งานไม่ได้
3. แบ่งงาน JavaScript ที่ยาวออกเป็นช่วงสั้น
เมื่อ JavaScript ทำงานต่อเนื่องนาน เบราว์เซอร์จะไม่สามารถตอบสนองต่อการคลิกใหม่หรือวาดหน้าจอได้ นักพัฒนาควรแบ่ง long task ออกเป็นงานย่อย และคืนสิทธิ์ให้ main thread ระหว่างขั้นตอน แทนการประมวลผลข้อมูลทั้งหมดในครั้งเดียว
4. แสดงผลตอบรับให้ผู้ใช้เห็นทันที
หากการกดปุ่มต้องรอ API หรือ AJAX อย่าปล่อยให้หน้าจอนิ่ง ควรเปลี่ยนสถานะปุ่ม แสดง loading indicator หรือปิดการกดซ้ำทันที แล้วจึงทำงานเบื้องหลัง วิธีนี้ไม่ได้ลดเวลาของระบบทุกส่วน แต่ช่วยให้ interaction แรกแสดงผลเร็วขึ้นและลดความสับสนของผู้ใช้
5. ลดความซับซ้อนของ DOM และเลย์เอาต์
หน้า Landing Page ที่ซ้อน Section, Column และ Widget หลายชั้นอาจทำให้เบราว์เซอร์คำนวณเลย์เอาต์นาน ตัดองค์ประกอบที่ไม่จำเป็น ลดเอฟเฟกต์ Sticky และ Parallax และหลีกเลี่ยงการเปลี่ยนสไตล์ขององค์ประกอบจำนวนมากพร้อมกัน
6. ทดสอบบนมือถือระดับกลาง
การทดสอบบนคอมพิวเตอร์แรงอาจไม่เปิดเผยปัญหาจริง ลองใช้ CPU throttling ใน DevTools หรือทดสอบผ่านมือถือระดับกลาง โดยเฉพาะหน้า WooCommerce และหน้าที่มี Page Builder หากเว็บยังตอบสนองได้ดีภายใต้ทรัพยากรจำกัด ผู้ใช้ส่วนใหญ่ก็มีแนวโน้มได้รับประสบการณ์ที่ดีขึ้น
ควรเริ่มแก้ INP จากจุดไหนก่อน?
เริ่มจากหน้าที่สร้างรายได้หรือรับ Lead มากที่สุด ไม่จำเป็นต้องไล่แก้ทุก URL พร้อมกัน สำหรับเว็บธุรกิจทั่วไป ลำดับที่เหมาะสมคือหน้าชำระเงิน หน้าสินค้า แบบฟอร์มติดต่อ หน้า Landing Page และเมนูหลักบนมือถือ
ตั้งเป้าหมายเป็น interaction ไม่ใช่คะแนนรวม เช่น “ปุ่มเพิ่มลงตะกร้าต้องตอบสนองภายใน 200 มิลลิวินาที” หรือ “เมนูมือถือเปิดได้ทันทีแม้มีสคริปต์แชตทำงานอยู่” เป้าหมายลักษณะนี้ตรวจสอบง่ายและเชื่อมโยงกับผลลัพธ์ทางธุรกิจได้ชัดกว่า
หลังแก้แล้ว ให้ตรวจซ้ำด้วย DevTools ก่อน จากนั้นติดตามข้อมูลผู้ใช้จริงใน PageSpeed Insights และ Search Console อย่าหยุดเพียงเพราะการทดสอบในเครื่องได้คะแนนดี เพราะ INP ที่มีความหมายที่สุดคือค่าที่เกิดขึ้นบนอุปกรณ์ของลูกค้าจริง
คำถามที่พบบ่อย
ค่า INP เท่าไหร่ถึงถือว่าเว็บไซต์ทำงานได้ดี?
ค่า INP ไม่เกิน 200 มิลลิวินาทีถือว่าอยู่ในเกณฑ์ดี ส่วน 200–500 มิลลิวินาทีควรปรับปรุง และมากกว่า 500 มิลลิวินาทีถือว่าตอบสนองช้า ควรประเมินจากผู้เข้าชมจริงที่เปอร์เซ็นไทล์ 75 ทั้งบนมือถือและเดสก์ท็อป
INP ต่างจาก FID อย่างไร?
FID วัดเฉพาะความล่าช้าของการโต้ตอบครั้งแรก และไม่ได้รวมเวลาที่เบราว์เซอร์แสดงผลตอบสนอง ส่วน INP ประเมินการโต้ตอบตลอดช่วงที่ผู้ใช้อยู่บนหน้าเว็บ จึงสะท้อนประสบการณ์การใช้งานจริงได้ครอบคลุมกว่า
จะแก้ค่า INP สูงบนเว็บไซต์ได้อย่างไร?
เริ่มจากลดงาน JavaScript ที่ใช้เวลานาน แบ่งงานประมวลผลขนาดใหญ่ออกเป็นช่วงสั้น และลดสคริปต์จากปลั๊กอินหรือบริการภายนอกที่ไม่จำเป็น ควรตรวจองค์ประกอบที่ผู้ใช้กดบ่อย เช่น เมนู ปุ่มสั่งซื้อ และช่องค้นหา ผ่าน PageSpeed Insights และ Chrome DevTools
บทความที่เกี่ยวข้อง