วิธีปรับปรุงค่า INP (Interaction to Next Paint) บนเว็บไซต์ให้คะแนนดีขึ้น

วิธีปรับปรุงค่า INP บนเว็บไซต์ คำตอบสั้นๆ: ลดภาระงานของ main thread ที่ทำให้การแสดงผลถัดไปหลังจากผู้ใช้คลิก, แตะ หรือพิมพ์ล่าช้า คุณต้องแบ่งงาน JavaScript ที่ใช้เวลานาน, ลบสคริปต์ที่ไม่จำเป็น, ปรับ event listener ให้น้อยลง, ลดแหล่งข้อมูลที่ขัดขวางการ render, ตรวจสอบโค้ดจาก third-party และวัดผลด้วยข้อมูลผู้ใช้จริง ค่า INP ที่ดีควรอยู่ที่ 200 ms หรือต่ำกว่า; 200-500 ms ต้องปรับปรุง, เกิน 500 ms ถือว่าแย่

INP หรือ Interaction to Next Paint เป็นหนึ่งใน Core Web Vitals ที่มีความสำคัญมากสำหรับ SEO และประสบการณ์ผู้ใช้ในปี 2026 Google ไม่ได้ดูแค่ความเร็วในการโหลดหน้า แต่ยังดูว่าหลังโหลดแล้ว ผู้ใช้มีปฏิสัมพันธ์กับเว็บไซต์ได้ลื่นไหลแค่ไหน ตัวอย่างเช่น คลิกปุ่มฟิลเตอร์แล้วเมนูขึ้นช้า, ปุ่ม "เพิ่มสินค้าลงตะกร้า" ตอบสนองช้า, เมนูมือถือแสดงผลช้า หรือช่องฟอร์มค้างขณะพิมพ์ ล้วนเป็นสัญญาณของปัญหา INP

บทความนี้จะพาคุณวัดค่า INP, ค้นหาสาเหตุทางเทคนิคที่ทำให้คะแนนตก และแนะนำวิธีปรับปรุง INP สำหรับนักพัฒนา, เจ้าของเว็บไซต์ หรือผู้ดูแล WordPress พร้อมอธิบายบทบาทของ hosting, CDN และการเชื่อมต่อที่ปลอดภัยต่อประสิทธิภาพ ด้วยตัวอย่างจริง หากต้องการเลือกโฮสติ้งที่เน้นประสิทธิภาพ แพ็คเกจการโฮสต์เว็บไซต์ หรือสำหรับโปรเจค WordPress โฮสติ้ง WordPress ก็มีตัวเลือกที่เหมาะสม

INP คืออะไร? ทำไมถึงสำคัญ?

INP วัดความเร็วในการตอบสนองต่อปฏิสัมพันธ์ของผู้ใช้บนหน้าเว็บ เช่น คลิกปุ่ม, เปลี่ยนแท็บ, เปิดเมนู, พิมพ์ในฟอร์ม หรือแตะบนมือถือ เบราว์เซอร์จะประมวลผล event, รัน JavaScript, คำนวณ style/layout ก่อนจะแสดงผลภาพใหม่ระหว่าง interaction เวลาที่ใช้จากปฏิสัมพันธ์จนถึงการแสดงผลใหม่ คือสิ่งที่ INP วัด

ก่อนหน้านี้ FID (First Input Delay) ถูกใช้วัดเฉพาะความล่าช้าของปฏิสัมพันธ์แรก แต่ INP จะวัดตลอดอายุการใช้งานของหน้า ดังนั้นเหมาะกับเว็บอีคอมเมิร์ซ, บล็อก, SaaS, เว็บไซต์องค์กร หรือระบบสมาชิกที่ต้องการวัดประสบการณ์ของผู้ใช้จริง

เกณฑ์ของ Google:

INP ไม่สำคัญแค่ SEO แต่ยังส่งผลต่อ conversion เช่น บนมือถือ ถ้าปุ่มฟิลเตอร์ตอบสนองช้า 700 ms ผู้ใช้อาจคิดว่าคำสั่งไม่ทำงาน กดซ้ำหรือออกจากหน้า ในทางกลับกัน UI ที่ตอบสนองใน 150-180 ms จะดูน่าเชื่อถือ รวดเร็ว และเป็นมืออาชีพมากกว่า

วิธีวัดค่า INP

ก่อนปรับ INP ต้องวัดผลให้ถูกต้อง เครื่องมือแบบ lab จะแสดงปัญหาโดยประมาณ แต่ข้อมูลผู้ใช้จริงสะท้อนอุปกรณ์, การเชื่อมต่อ และเบราว์เซอร์ที่หลากหลาย ควรใช้ทั้งข้อมูลจาก lab และ field

1. ตรวจสอบด้วย PageSpeed Insights

PageSpeed Insights จะแสดงค่า INP จาก Chrome User Experience Report หากมีข้อมูลจริง แยกดูผลมือถือและเดสก์ท็อป ให้ความสำคัญกับมือถือ เพราะมือถือที่ช้าจะเจอ main thread block ง่ายกว่า ถ้าค่า INP เกิน 200 ms ให้จดรายการ "โอกาส" และ "วิเคราะห์" เพื่อปรับปรุง

2. ติดตามรายงาน Core Web Vitals ใน Search Console

Search Console มีรายงาน Core Web Vitals แยกปัญหาตามกลุ่ม URL ดูว่าหน้าแบบเดียวกันมีปัญหาหรือไม่ เช่น หน้า product detail ทั้งหมด INP ต่ำ อาจเกิดจากธีม, script ตะกร้า, plugin รีวิว หรือโค้ดตัวเลือกสินค้า

3. ใช้ Performance panel ใน Chrome DevTools

Chrome DevTools Performance panel แสดงว่า event ไหนรัน JavaScript อะไร และงานไหนใช้เวลานานเกิน 50 ms ให้บันทึก interaction เช่น คลิกเมนู แล้วดู block สีม่วง, เหลือง, เขียว งาน script ที่ยาว, style recalculation ซ้ำๆ และ layout หนาแน่น ล้วนเป็นตัวชี้วัด INP

4. ตั้งค่าระบบวัดผลผู้ใช้จริง (RUM)

สำหรับเว็บที่มี traffic สูง Real User Monitoring (RUM) มีประโยชน์มาก ใช้ Web Vitals library เพื่อเก็บค่า INP ตาม URL, อุปกรณ์, เบราว์เซอร์, ประเทศ และจุด interaction ข้อมูลเหล่านี้ช่วยให้ปรับปรุงตรงจุด เช่น พบว่าผู้ใช้ Android คลิกเมนูมือถือ INP สูง 620 ms ก็เน้นแก้ตรงนั้น

สาเหตุที่ทำให้ INP แย่ (ที่พบบ่อย)

ส่วนใหญ่ปัญหา INP เกิดจากฝั่งเบราว์เซอร์ที่ต้องประมวลผลมากเกินไปตอน user interaction แม้ infrastructure, file delivery, cache และ third-party จะมีผลทางอ้อม แต่ตัวหลักคือ workload ฝั่ง client

JavaScript ขนาดใหญ่/หนักเกินไป

เว็บสมัยใหม่โหลด JavaScript เยอะมาก เช่น ธีม, slider, live chat, ads, analytics, A/B test, map, social widget ไม่ใช่แค่ download แต่ยังต้อง parse, compile, execute ถ้า main thread ถูกใช้งานมาก ก็จะตอบสนอง interaction ช้า

Long task (งานที่กินเวลานาน)

งานบน main thread ที่กินเวลามากกว่า 50 ms ถูกเรียกว่า long task งานเดียว 300 ms อาจทำให้คลิกค้าง เช่น script ที่ recalculates product filter ฝั่ง client ของ 1000 สินค้า อาจดัน INP เกิน 500 ms ได้ง่ายๆ

DOM ซับซ้อน และ layout cost สูง

HTML node เยอะ, component ซ้อนกัน, style เปลี่ยนบ่อย, layout thrashing (อ่านเขียนซ้ำ) ทำให้ INP ต่ำ โดยเฉพาะ mega menu, product list, single page app ที่ DOM หนาแน่น

Third-party script

โค้ดจาก ad network, tracking pixel, heatmap, live chat, social embed รันในเว็บคุณแต่ควบคุมไม่ได้ ถ้าใช้ main thread ขณะ interaction แม้ UI จะเขียนดีแต่ก็ lag ได้

WordPress plugin/theme หนักเกินไป

WordPress ทุก plugin เพิ่ม CSS/JS ของตัวเอง เช่น script ของ contact form ควรโหลดเฉพาะหน้าติดต่อ แต่ถ้าโหลดทุกหน้า ก็เป็นภาระเปล่า editor, slider, popup plugin ก็มีผลกับ INP ในมือถือมาก

แผนปฏิบัติปรับปรุง INP ทีละขั้นตอน

หลักการคือ วัด, แยก, ลด, แบ่ง และวัดซ้ำ ขั้นตอนด้านล่างเรียงตามลำดับความสำคัญที่ทีมเทคนิคใช้จริง

1. หาจุด interaction ที่แย่ที่สุด

เริ่มจากระบุ interaction ไหน INP ต่ำ เช่น เมนูมือถือ, ปุ่มเพิ่มตะกร้า, filter panel, search box หรือ form submit ใช้ DevTools บันทึก interaction หลายครั้ง แล้วดู Event Timing/Interaction ว่าจุดไหนช้า

ตัวอย่าง: เว็บอีคอมเมิร์ซ filter button INP 740 ms เพราะกดแล้ว render product card ใหม่ทั้งหมด 1800 DOM node อัพเดทพร้อมกัน หลังย้าย filter ไป component แยก และ delay การอัพเดท list INP เหลือ 190 ms

2. ลดขนาด JavaScript bundle

ลบ code ที่ไม่ใช้ เป็นการลด INP ที่เห็นผล Bundle analyzer ช่วยดูว่าคลังไหนกินพื้นที่มาก ควร import เฉพาะ module ที่ต้องใช้ เช่น ใช้ Intl API แทน library date ขนาดใหญ่

• ปิดฟีเจอร์ธีมที่ไม่จำเป็น
• ไม่โหลด script slider, gallery, animation ที่ไม่ได้ใช้ในหน้านั้น
• ใช้ build tool ที่รองรับ tree shaking
• ไม่ส่ง admin panel code ไปฝั่ง visitor
• polyfill ที่ใช้เฉพาะ browser ที่จำเป็น

3. แบ่ง long task เป็นงานย่อย

main thread ต้องว่างเป็นช่วงๆ เพื่อรับ interaction ให้แบ่งงานใหญ่เป็นงานเล็ก ใช้ setTimeout, scheduler.postTask, requestIdleCallback หรือฟีเจอร์ timing ของ framework วัตถุประสงค์คือ แทนที่จะมีงานเดียว 300 ms ให้เป็นงานย่อย 20-40 ms หลายงาน

เช่นต้อง filter และ render ตาราง 5000 แถว ให้แสดง 50 แถวแรกก่อน ที่เหลือ virtualize หรือ background task เพื่อ user เห็นผลเร็ว งานที่เหลือไม่ block experience

4. ลด complexity ของ event listener

ทุก event เช่น click, input, scroll, keydown ถ้ามี function หนักจะลด INP เช่น input ทุก keystroke ส่ง API หรือ recalculates list ผิด ใช้ debounce/throttle ลดความถี่

• search box ใช้ debounce 300 ms
• scroll event ใช้ passive listener
• แทนที่จะใส่ listener ทีละร้อย element ใช้ event delegation
• หลังคลิกให้ feedback ก่อน งานหนักค่อยรันทีหลัง

5. ให้ feedback แก่ผู้ใช้ทันทีหลัง interaction

INP เกี่ยวกับ paint ถัดไป ดังนั้นควรให้ visual feedback เช่น ปุ่มเปลี่ยนสี, loading indicator, skeleton หรือเปิด panel เฟรมแรกทันที ผู้ใช้จะรู้ว่าเว็บไซต์ทำงานอยู่ อย่ารอ API หนักแล้วเปลี่ยน UI ทีเดียว ให้ feedback เร็วและอัพเดทแบบค่อยๆ ไป

6. ลด render/layout cost

CSS และ layout มีผลกับ INP ไม่แพ้ JavaScript หลังคลิกถ้าเปลี่ยนแปลง size, position หรือ style หลาย element จะหนัก animation ควรใช้ transform/opacity แทน width/height/top/left list ใหญ่ควร virtualize ไม่ต้องมีทุก card ใน DOM

หลีกเลี่ยง layout thrashing คือใน loop ไม่ควรอ่าน-เขียน-อ่านซ้ำ ให้แยก read กับ write เป็นกลุ่ม วิธีนี้ช่วยลดเวลาหลาย ms ในหน้าเว็บซับซ้อน

7. ตรวจสอบ third-party code

ถามว่า script นี้จำเป็นต่อ conversion ไหม ถ้าไม่ ให้ลบ, delay หรือโหลดเฉพาะหน้าที่ต้องใช้ Live chat อาจต้องในหน้า payment แต่ไม่ต้องโหลดใน blog ทุกหน้า analytic/ad script ควร defer/async อย่า block interaction สำคัญ

8. ใช้ Web Worker สำหรับงานหนัก

งานเช่น filter, process JSON, encryption, data transform ถ้ากิน CPU มาก ให้ใช้ Web Worker เพื่อย้ายไป background main thread จะรับ interaction ต่อได้ ไม่จำเป็นต้องใช้ทุกงาน แต่ถ้าเกิน 100 ms ควรพิจารณา

9. ลด hydration cost ของ framework

React, Vue, Angular, Next.js, Nuxt hydration หลังโหลดอาจกิน INP ใช้ partial hydration, island architecture หรือ server component แทน ทั้งหน้าไม่ต้อง interactive แค่ section ที่ต้อง เช่น modal, comment, suggestion ควรโหลดเมื่อ user ใช้

10. ลด plugin overload ใน WordPress

WordPress ให้ทำ inventory plugin ลบ plugin ที่ซ้ำกัน ตรวจว่าฟอร์ม, gallery, slider, popup โหลดไฟล์ในทุกหน้าหรือไม่ ใช้ asset unload plugin เพื่อปิด CSS/JS ที่ไม่จำเป็นในแต่ละหน้า

ตัวอย่าง: เว็บองค์กร WordPress หน้าแรก INP มือถือ 560 ms หลังลบ slider ใช้ HTML/CSS เบา popup script delay 5 วินาที JS ฟอร์มโหลดเฉพาะหน้าติดต่อ ผล INP มือถือเหลือ 210 ms และปรับเพิ่มเป็น 175 ms

Hosting กับ infrastructure ส่งผลต่อ INP อย่างไร?

INP คือ metrics ฝั่ง client แต่ hosting infrastructure ก็มีผลทางอ้อม เช่น server ตอบเร็ว, cache ดี, PHP version ใหม่, HTTP/2 หรือ HTTP/3, CDN, compression ทำให้ไฟล์ส่งถึง client เร็วขึ้น Main thread ฝั่ง client ก็ทำงานได้ต่อเนื่อง

Infrastructure แย่ TTFB สูง, resource มาช้า, cache ไม่เสถียร, server load สูง ทำให้ user experience ตก WordPress ที่ไม่มี cache จะประมวลผล PHP/database ทุก request หน้าไม่พร้อม interaction ทันที จึงต้องคิด INP ไปพร้อมกับ LCP และ TTFB

• ใช้ server-side cache
• เลือก PHP 8.x และ database ใหม่
• ให้ static file ผ่าน CDN
• เปิด Brotli หรือ Gzip compression
• อัปเดต SSL/TLS ดู ใบรับรอง SSL
• ตั้งชื่อโดเมนให้เหมาะกับโปรเจคใหม่ การตรวจสอบโดเมน

ตารางลำดับความสำคัญการปรับ INP

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

Checklist เทคนิคสำหรับนักพัฒนา

INP ควรมี checklist ติดตามในทีม ไม่เช่นนั้นงาน performance ที่ทำไปจะเสียเมื่อมี plugin, code ใหม่ หรือเปลี่ยนดีไซน์

• ตั้งเป้า INP มือถือ < 200 ms สำหรับ template สำคัญ
• ตรวจ bundle size ทุก pull request
• ทดสอบผลกระทบ performance ก่อนเพิ่ม third-party script
• ใช้ DevTools วัด interaction เช่น เมนูมือถือ, search, form, checkout
• ลด long task ให้ต่ำกว่า 50 ms หรือแบ่งงาน
• animation ใช้ transform/opacity
• list ใหญ่ใช้ pagination/infinite scroll/virtualize
• รายงาน RUM monthly และติดตาม Search Console

ข้อผิดพลาดที่พบบ่อยในการปรับ INP

ติดตั้ง cache plugin อย่างเดียว

Cache สำคัญแต่ไม่ใช่คำตอบเดียว INP แย่เพราะ code หนักขณะ interaction Cache ช่วยส่งหน้าเร็วแต่ไม่แก้ JavaScript หนัก ต้องทำร่วมกับ code optimization

เชื่อ lab score มากกว่าข้อมูลผู้ใช้จริง

Lighthouse มีประโยชน์แต่ไม่พอ ผู้ใช้จริงใช้ device, network, browser ต่างกัน โดยเฉพาะ Android ต่ำจะเจอ INP ที่ desktop test ไม่เห็น

delay script แบบสุ่ม

Defer/delay ต้องระวัง ถ้า delay ผิดจะทำให้เมนู, ตะกร้า, form หรือ payment flow พัง script ที่สำคัญห้าม delay ต้อง delay เฉพาะ third-party หรือ script ที่ไม่สำคัญ

เน้นแค่การ optimize รูปภาพ

Image optimization สำคัญกับ LCP แต่ไม่แก้ INP ถ้าปัญหาคือ code หลังคลิก รูปภาพอย่างเดียวไม่พอ ต้อง optimize ทุกส่วนของ Core Web Vitals

กลยุทธ์ SEO ที่เน้น INP ในปี 2026

ปี 2026 SEO ต้องคิด performance, content quality และ infrastructure ไปพร้อมกัน Google AI Overviews และ search experience ใหม่จะเน้นเว็บที่ตอบไวและให้ประสบการณ์ดีที่สุด INP จึงเป็นเรื่องของทีม dev, SEO, UX, content และ infrastructure ร่วมกัน

ตัวอย่าง: บล็อกควรมี TOC, filter, comment form ที่ไว เว็บอีคอมเมิร์ซตัวเลือก size, variation, add to cart ต้องตอบสนองทันที เว็บองค์กร form เสนอราคา, เมนูมือถือ, ปุ่มติดต่อห้าม delay ถ้า user รู้สึกเว็บไว จะอยู่นานขึ้น ดูหลายหน้า conversion สูงขึ้น

Hostragons มี hosting ที่เน้น performance, server ใหม่, infrastructure ปลอดภัย สนับสนุนงาน SEO เทคนิคได้ดี บริหารโดเมน, hosting, security ในที่เดียว ลดงาน operation ทีมจะได้เน้น UX และ content quality ดู โฮสติ้งธุรกิจ, เซิร์ฟเวอร์ VPS และ ใบรับรอง SSL

สรุป

หัวใจของการปรับ INP คือ อย่าให้ browser ทำงานหนักเกินไปขณะผู้ใช้มี interaction เริ่มจากวัด interaction ที่ช้าด้วยข้อมูลจริง ลบ JavaScript ที่ไม่ใช้, แบ่งงานใหญ่, ลด event listener, ลด render cost และควบคุม third-party code Hosting, cache, CDN และ security ที่ดีช่วยเสริมพื้นฐาน

อยากให้เว็บเร็ว, เชื่อถือได้, user friendly เริ่มวัด INP หน้า mobile ที่สำคัญ แล้วทำตาม 3 ขั้นตอนแรกของบทความนี้ ส่วน infrastructure เลือก Hostragons เพื่อเริ่มต้นที่ performance และเปรียบเทียบ hosting ให้เหมาะกับความต้องการ

คำถามที่พบบ่อย

INP score ควรอยู่ที่เท่าไหร่?

คะแนน INP ที่ดีต้องต่ำกว่า 200 ms 200-500 ms ควรปรับปรุง เกิน 500 ms ถือว่า user experience ไม่ดี โดยเฉพาะข้อมูลจากมือถือควรให้ความสำคัญ

INP กับ FID ต่างกันอย่างไร?

FID วัด delay ของ interaction แรกเท่านั้น ส่วน INP วัดคุณภาพการตอบสนองของทุก interaction ตลอดอายุหน้าทำให้สะท้อน user experience ได้ครบกว่า

ทำไม WordPress site มี INP score ต่ำ?

ปกติเกิดจาก plugin เยอะ, theme หนัก, CSS/JS ไม่จำเป็นโหลดทุกหน้า, slider, popup script และ third-party code แก้ด้วยการลบ plugin, asset unload ตามหน้า, ใช้ theme เบา

เปลี่ยน hosting จะช่วยแก้ INP หรือไม่?

Hosting ไม่สามารถแก้ JavaScript หรือ long task โดยตรง แต่ server ที่เร็ว, cache ดี, CDN, PHP ใหม่ และ resource เสถียร ช่วยสนับสนุนการปรับ INP โดยเฉพาะ WordPress

INP optimization ใช้เวลานานแค่ไหน?

หลังปรับ code/plugin จะเห็นผลทันทีใน lab test ส่วนข้อมูลผู้ใช้จริงใน Search Console หรือ Chrome ต้องรอให้มี data พอถึงจะเห็นผล ใช้เวลาหลายสัปดาห์