INP ต้าวัดใหม่ที่มาแทน FID และควรเริ่มเตรียมต้ายังไง

INP ต้าวัดใหม่ที่มาแทน FID และควรเริ่มเตรียมต้ายังไง

INP (Interaction to Next Paint) ได้เข้ามาแทนที่ FID (First Input Delay) อย่างเป็นทางการใน Core Web Vitals ไปแล้ว (ตั้งแต่มีนาคม 2024)

ถ้าคุณยังดูแค่ค่า FID อยู่ คุณอาจกำลังหลงทางครับ เพราะเว็บคุณอาจจะได้คะแนนเขียวสวยหรู แต่คนใช้งานจริงกลับรู้สึกว่า “เว็บนี้หน่วงจัง”

นี่คือเจาะลึกเรื่อง INP และวิธีรับมือเพื่อไม่ให้คะแนน SEO ร่วงครับ

INP (Interaction to Next Paint): ตัววัดความ “ลื่น” ที่โหดกว่าเดิม

1. FID vs INP ต่างกันยังไง? (อธิบายแบบเห็นภาพ)

ลองจินตนาการว่าคุณไปร้านอาหารและกดกริ่งเรียกพนักงานครับ:

  • FID (ตัวเก่า): วัดแค่ “เวลาตั้งแต่กดกริ่ง จนถึงพนักงานเริ่มหันมามองคุณ”
    • จุดอ่อน: ถ้าพนักงานหันมามองเร็ว (FID ดี) แต่ยืนนิ่งไม่เดินมารับออร์เดอร์สักที… ลูกค้าก็ยังหงุดหงิดอยู่ดีใช่ไหมครับ? นี่คือเหตุผลที่ FID สอบตก
  • INP (ตัวใหม่): วัด “เวลาทั้งหมดตั้งแต่กดกริ่ง -> พนักงานเดินมา -> จนถึงเริ่มพูดว่า ‘รับอะไรดีครับ'”
    • จุดแข็ง: มันวัดกระบวนการทั้งหมดจนกว่าจะเกิด “การเปลี่ยนแปลงบนหน้าจอ” (Next Paint) จริงๆ
INP ต้าวัดใหม่ที่มาแทน FID และควรเริ่มเตรียมต้ายังไง

FID วัดแค่ความ “ตื่นตัว” (Responsiveness start) แต่ INP วัดความ “สำเร็จในการตอบสนอง” (Full Interaction Latency)

2. INP วัดอะไรบ้าง?

INP จะจับเวลา 3 ช่วงของทุกการคลิก (Tap/Click/Keyboard) ตลอดการใช้งานหน้าเว็บ

  1. Input Delay เวลารอคิว (เช่น กดแล้วแต่ติด process อื่นอยู่)
  2. Processing Time เวลาที่ JavaScript ทำงานประมวลผลคำสั่งนั้น
  3. Presentation Delay เวลาที่ Browser วาดภาพใหม่ขึ้นหน้าจอ (เช่น เมนูเด้งออกมา, สีปุ่มเปลี่ยน)

Google จะเลือกค่าที่ “แย่ที่สุด” (หรือแย่เกือบที่สุด) ตลอดการใช้งาน มาเป็นคะแนนของหน้านั้นครับ

3. ทำไมเว็บ “สวยแต่ช้า” ถึงตายเพราะ INP?

ปัญหาหลักของ INP มักเกิดจาก JavaScript (JS) ที่ทำงานหนักเกินไปครับ

  • ถ้าคุณมี Code JS ก้อนใหญ่ (Long Task) ที่รันนานกว่า 200 milliseconds
  • ระหว่างที่ JS ก้อนนั้นรันอยู่ ถ้าผู้ใช้งานกดปุ่ม “ซื้อสินค้า” -> Browser จะค้าง (Freeze) เพราะมันไม่ว่างมารับคำสั่ง
  • ผลลัพธ์: ลูกค้ากดย้ำๆ (Rage Click) -> ประสบการณ์แย่ -> คะแนน INP พุ่ง (ซึ่งไม่ดี)

4. How-to: วิธีเตรียมตัวและแก้ค่า INP ให้ผ่านเกณฑ์

เป้าหมายคือต้องทำเวลาให้ต่ำกว่า 200 ms (สีเขียว) ครับ

1. หาจำเลยให้เจอ (Audit)

ใช้ PageSpeed Insights หรือ Chrome DevTools (แท็บ Performance)

  • มองหาแถบสีแดงๆ ที่เขียนว่า “Long Tasks” นั่นคือช่วงเวลาที่เว็บคุณเป็นอัมพาตครับ

2. แตกงานใหญ่ให้เป็นงานเล็ก (Break up Long Tasks)

นี่คือเทคนิคเชิง Technical หน่อยครับ

  • แทนที่จะให้ JS รันรวดเดียว 500ms (ซึ่งบล็อกการกดปุ่มของคน)
  • ให้ซอยย่อย Code เป็นชิ้นเล็กๆ ชิ้นละ 50ms แล้วให้มันสลับไปพักหายใจบ้าง เพื่อให้ Browser มีจังหวะมารับคำสั่งคลิกจากผู้ใช้งาน

3. โชว์ Feedback ทันที (Visual Feedback)

ถ้าการประมวลผลมันต้องใช้เวลานานจริงๆ (เช่น กดค้นหาแล้วต้องรอดึงข้อมูล)

INP ต้าวัดใหม่ที่มาแทน FID และควรเริ่มเตรียมต้ายังไง
  • อย่าให้หน้าจอนิ่ง!
  • ทันทีที่กดปุ่ม ให้ใส่ Loading Spinner หรือเปลี่ยนสีปุ่มทันที เพื่อบอกคนใช้งานว่า “รับทราบแล้ว กำลังทำให้อยู่”
  • การที่หน้าจอมีการเปลี่ยนแปลง (Paint) ทันที จะช่วยลดเวลา Presentation Delay ได้ครับ

4. ระวัง Third-Party Scripts

พวก Chat Widget, Social Feed, หรือ Tracking Pixel ที่เราแปะๆ เข้าไป มักเป็นตัวการทำให้ Main Thread เต็ม และทำให้ INP แย่ลง

  • วิธีแก้: โหลดเฉพาะที่จำเป็น หรือตั้งค่าให้โหลดแบบ defer หรือ async (โหลดทีหลังเมื่อหน้าเว็บว่าง)

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

ถ้าเว็บคุณกดแล้วหน่วง กดแล้วค้าง… ต่อให้ข้อมูลดีแค่ไหน ลูกค้าก็หนี และ SEO ก็ร่วงครับ

ใส่ความเห็น

อีเมลของคุณจะไม่แสดงให้คนอื่นเห็น ช่องข้อมูลจำเป็นถูกทำเครื่องหมาย *


ติดต่อ "แว่นTalk"