INP (Interaction to Next Paint) คือค่าวัดความไวต่อการแตะ/คลิก โดยพิจารณาอินเทอร์แอ็กชันที่ช้าที่สุดเกือบทั้งหมดของหน้า เกณฑ์ผ่านคือ ≤200 ms; 200–500 ms ต้องปรับปรุง; >500 ms แย่ วิธีลดคือหั่น Long Tasks, ลด JS/สคริปต์ที่สาม และทำแฮนด์เลอร์ให้เบา
INP คืออะไร (เข้าใจเร็ว)
INP วัดเวลาตอบสนองหลังผู้ใช้ คลิก/แตะ/กดคีย์ จนเบราว์เซอร์เพนต์เฟรมถัดไปที่สะท้อนการเปลี่ยนแปลงบนหน้าจอ แตกต่างจากตัวชี้วัดเก่าเพราะสะท้อนทั้งหน้าและหลายเหตุการณ์ ไม่ใช่เหตุการณ์เดียว
เกณฑ์ผ่าน (Threshold 2025)
สถานะ | ค่าที่วัดได้ | ความหมาย |
ดี | ≤ 200 ms | ตอบสนองไว |
ต้องปรับปรุง | 200 – 500 ms | ยังมีดีเลย์ให้รู้สึกได้ |
แย่ | > 500 ms | ช้า รบกวนประสบการณ์ |
อาการ → สาเหตุ → วิธีแก้ (โฟกัสมือถือ)
อาการ | สาเหตุหลัก | วิธีแก้เร็ว | เครื่องมือเช็ค |
แตะปุ่มแล้วหน่วง |
Long Tasks บนเมนเธรด (bundle ใหญ่/งานซิงก์) |
หั่นงานยาวเป็นก้อนเล็ก, แยกโค้ด on-demand, เลื่อนงาน non-critical ไป idle |
DevTools Performance, Web Vitals overlay |
เปิดเมนู/โมดัลกระตุก |
รีเฟรช layout บ่อย, อ่าน-เขียน DOM สลับกัน |
Batch DOM, ใช้ transform/opacity, ลด forced reflow |
Performance Profiler (Bottom-Up/Events) |
พิมพ์แล้วตัวอักษรขึ้นช้า |
แฮนด์เลอร์ key/input หนัก, sync validation |
ดีบาวซ์/ธรอตเทิล, ย้าย validation เป็น async/idle |
Performance + Sources (breakpoints) |
แตะลิงก์แล้วไม่ขยับ |
สคริปต์ที่สามบล็อก (tag/ads/analytics) |
ตัด/โหลดแบบ lazy, ใช้ consent-mode, ย้ายไปหลัง interaction |
Coverage, Network blocking |
โค้ดตัวอย่าง: หั่น Long Tasks ให้ INP ดีขึ้น
// แบ่งงานหนักเป็นชิ้นเล็ก & ยกไปช่วงว่าง
function chunkWork(items, doChunk) {
const DEADLINE_MS = 50; // ไม่บล็อกเมนเธรดนาน
function run() {
const start = performance.now();
while (items.length && performance.now() - start < DEADLINE_MS) {
doChunk(items.shift());
}
if (items.length) {
(window.requestIdleCallback || setTimeout)(run, 0);
}
}
run();
}
How-to: ลด INP ให้ “ผ่าน” ทีละขั้น
- วัดจากผู้ใช้จริง (RUM): เปิดรวบรวม Web Vitals ในโปรดักชัน + อ่าน CrUX/Field data
- โปรไฟล์อินเตอร์แอ็กชัน: DevTools → Record → กดปุ่ม/เปิดเมนู → หา Long Tasks >50 ms
- ลดงานบนอินพุต: ทำแฮนด์เลอร์ให้เล็ก, ใช้ passive listeners, ดีบาวซ์/ธรอตเทิล
- แยก/เลื่อนโหลด JS: Code-split เส้นทาง, โหลด 3rd-party แบบ lazy/consent-mode
- ลดงาน layout: ใช้
transform/opacity
, batch DOM, หลีกเลี่ยง forced reflow
- ทดสอบมือถือจริง: วัด INP บนอุปกรณ์กลาง-ล่าง ไม่ใช่เครื่องแรงอย่างเดียว
- วนซ้ำ: รีคอร์ด → ปรับ → วัดซ้ำจน ≤200 ms
อ่านต่อ & เชื่อมโยงภายใน
FAQ (People Also Ask)
INP ต่างจาก FID ยังไง?
FID วัดเหตุการณ์แรกเหตุการณ์เดียว ส่วน INP พิจารณาอินเทอร์แอ็กชันเกือบทั้งหมดบนหน้า จึงสะท้อนประสบการณ์ผู้ใช้จริงกว่า
ควรโฟกัสอะไรถ้า INP ไม่ผ่าน?
หั่น Long Tasks, ทำแฮนด์เลอร์ให้เล็ก, ลด JS หนักและสคริปต์ที่สาม, แก้ layout thrashing
วัด INP จากไหน?
RUM/CrUX (field), Web Vitals overlay, DevTools Performance (lab สำหรับโปรไฟล์)
แหล่งอ้างอิง
อัปเดตล่าสุด: 08 Aug 2025
เกี่ยวกับผู้เขียน
Vision X Brain Team — ทีมผู้เชี่ยวชาญ SEO/Performance/CRO สำหรับอีคอมเมิร์ซและเว็บความเร็วสูง เร่ง INP/LCP/CLS ในโปรเจกต์จริงด้วยการลด JS หนักและปรับสถาปัตยกรรมอย่างเหมาะสม ดูผลงาน/ติดต่อ
ต้องการทีมช่วยทำ INP ให้ผ่านเร็ว?
เราช่วยโปรไฟล์อินเตอร์แอ็กชัน สำรวจ Long Tasks ปรับแฮนด์เลอร์/เลย์เอาต์ และติดตั้ง RUM เพื่อติดตามค่า INP ต่อเนื่อง ติดต่อเรา