เพิ่มประสิทธิภาพ INP บน Hostinger LiteSpeed: คู่มือฉบับปฏิบัติ

INP วัดอะไรกันแน่ (และทำไม "การแก้ไข" ส่วนใหญ่ถึงไม่ได้ผล)

Interaction to Next Paint วัดความล่าช้าที่นานที่สุดระหว่าง user input (คลิก, แตะ, กดปุ่ม) กับเฟรมถัดไปที่เบราว์เซอร์ paint ตลอดช่วงอายุของหน้าเว็บทั้งหมด เกณฑ์คือ 200ms สำหรับ "ดี" และ 500ms สำหรับ "ควรปรับปรุง" มันเป็น metric แบบ 75th-percentile ดังนั้น interaction ที่แย่เพียงครั้งเดียวก็ทำให้คะแนนของ URL group ทั้งกลุ่มตกได้

คำแนะนำเรื่อง INP ส่วนใหญ่บนอินเทอร์เน็ตปฏิบัติกับมันเหมือน LCP — CDN ใหญ่ขึ้น, cache มากขึ้น, รูปภาพเล็กลง ไม่มีข้อไหนช่วย INP โดยตรงเลย INP คือ metric ของ main thread ฝั่ง JavaScript ทางแก้คือ: JS น้อยลง, JS ที่ฉลาดขึ้น และการโยนงานที่ไม่จำเป็นต้อง block การ paint ออกไป การ cache HTML (ซึ่ง LiteSpeed ทำอย่างจริงจัง) ไม่ได้เปลี่ยนงานบน main thread เลย ถ้าจะมีผลก็คือทำให้ interaction ที่หนัก JS แสดงผลเร็วขึ้นเท่านั้น

เราดึงข้อมูลวัด INP 3,400 รายการจาก RUM data ที่สอดคล้องกับ CrUX ข้าม 22 เว็บไซต์ลูกค้าที่ host บน Hostinger ใน Q1 2026 ค่ามัธยฐาน INP ก่อนที่เราจะ optimize: 340ms หลังจาก optimize: 148ms 21 เทคนิคด้านล่างเรียงตามผลกระทบทั่วไปที่พบใน dataset นี้

21 เทคนิค เรียงตามลำดับ

1. เลื่อนเวลาหรือลบ third-party script ออก (ผลกระทบ: สูง · ความยาก: ต่ำ)

ชัยชนะที่ใหญ่ที่สุดสำหรับ INP บนเว็บไซต์ Hostinger คือการกำจัด tag soup ของ third-party ทั้งหมด Google Tag Manager, Hotjar, Intercom, Facebook Pixel, chat widget หลายตัว — แต่ละตัวส่ง JS ที่รันตอน user interaction เราตัด INP ได้ 120-180ms เป็นประจำแค่จากการตรวจสอบ tag stack ใช้ async + defer อย่างเข้มข้น และโหลดเครื่องมือที่ต้อง consent เฉพาะหลังจาก interaction เท่านั้น

<!-- Bad -->
<script src="https://www.googletagmanager.com/gtm.js?id=GTM-XXXX"></script>

<!-- Better: load on first user interaction -->
<script>
addEventListener('click', () => {
  if (!window.__gtmLoaded) {
    window.__gtmLoaded = true;
    const s = document.createElement('script');
    s.src = 'https://www.googletagmanager.com/gtm.js?id=GTM-XXXX';
    document.head.appendChild(s);
  }
}, { once: true, passive: true });
</script>

2. เปิดใช้ "Combine CSS/JS" ของ LiteSpeed Cache อย่างระมัดระวัง (สูง · ต่ำ)

ปลั๊กอิน LiteSpeed ของ Hostinger รวมและ minify JS ได้ แต่โหมด Combine ที่ทำงานหนักมักทำให้ WordPress theme พังได้ ใช้ Minify + Defer แทน และข้าม Combine ไปเลยถ้ายังไม่ได้ QA ผลลัพธ์บนทุก template

3. เปลี่ยน page builder ของ WordPress ที่หนักเกินไป (สูง · สูง)

Elementor และ Divi ส่ง JS อย่างน้อย >200KB ก่อนจะนับ widget ใด ๆ ด้วยซ้ำ เรา migrate เว็บไซต์ลูกค้า 6 แห่งจาก Elementor ไปเป็น theme ที่เขียนโค้ดเอง INP ลดลงเฉลี่ย 180ms ขายไอเดียนี้ให้ลูกค้าที่รัก builder ของตัวเองยากมาก แต่ข้อมูลชัดเจนไม่มีข้อโต้แย้ง

4. ใช้ requestIdleCallback สำหรับงานที่ไม่สำคัญเร่งด่วน (สูง · กลาง)

อะไรก็ตามที่ไม่จำเป็นต้องเกิดขึ้นระหว่าง interaction frame — analytics, hover prefetch, lazy-load trigger — ควรรันในช่วงเวลาว่าง (idle time):

requestIdleCallback(() => {
  // analytics, prefetch, late hydration
}, { timeout: 2000 });

5. แบ่ง task ที่ยาวด้วย scheduler.yield() (สูง · กลาง)

Chromium รุ่นใหม่รองรับ scheduler.yield() ซึ่งคืน main thread ได้อย่างสะอาดระหว่าง task สำหรับ handler ใดก็ตามที่ใช้เวลา >50ms ให้แทรก yield เข้าไป:

async function processItems(items) {
  for (let i = 0; i < items.length; i++) {
    process(items[i]);
    if (i % 50 === 0 && 'scheduler' in window && 'yield' in scheduler) {
      await scheduler.yield();
    }
  }
}

6. ตรวจสอบ click handler ที่ทำให้ DOM thrash แบบ synchronous (สูง · กลาง)

เว็บไซต์ยุค jQuery ยังมี handler ที่อ่าน layout, เขียน style, อ่าน layout ซ้ำ — บังคับให้เกิด reflow loop ใช้ Chrome DevTools Performance panel ตรวจสอบ handler ใดก็ตามที่มีคำเตือน "Forced reflow" ขอบสีแดง คือพิษต่อ INP

7. แทนที่ alert()/confirm() ใน handler (กลาง · ต่ำ)

Dialog แบบ native block main thread แบบ synchronous แทนที่ด้วย modal ที่สร้างเองด้วย element <dialog>

8. ใช้ CSS content-visibility: auto บนหน้าเว็บที่ยาว (กลาง · ต่ำ)

สำหรับหน้าที่มีหลาย section อยู่นอกจอ วิธีนี้ข้ามงาน layout จนกว่า section นั้นจะใกล้ viewport เราเคยเห็น INP ดีขึ้น 40-60ms บนบทความบล็อกยาว ๆ และหน้ารายการสินค้า

9. Lazy-hydrate island ของ React/Vue (กลาง · สูง)

ถ้าคุณใช้ Astro หรือ islands framework ที่คล้ายกัน ใช้ client:visible หรือ client:idle แทน client:load สำหรับ widget ที่อยู่ใต้ fold ส่วนใหญ่แล้ว section ที่ "interactive" ไม่จำเป็นต้อง hydrate ก่อนที่ผู้ใช้จะ scroll ไปถึง

10. ย้าย event listener ไปใช้ delegation (กลาง · ต่ำ)

การแนบ click listener 200 ตัวเข้ากับ list item 200 ชิ้น ช้ากว่าการใช้ delegated listener ตัวเดียวบน parent listener แบบ delegate ตัวเดียว: attach ใช้เวลา ~3ms ส่วน 200 listener: attach ใช้ ~80ms บวกกับ overhead ของ event-loop ต่อรายการ

11. หลีกเลี่ยง document.write() ให้หมด (กลาง · ต่ำ)

ใช่ ในปี 2026 เรายังเจอมันบนเว็บไซต์เก่าอยู่ มัน block parser และทำให้ INP พังตั้งแต่ interaction แรก

12. ใช้ passive: true บน touch และ wheel listener (กลาง · ต่ำ)

ถ้าไม่ใส่ เบราว์เซอร์จะเริ่ม scroll ไม่ได้จนกว่า handler ของคุณจะ return { passive: true } บอกเบราว์เซอร์ว่า handler จะไม่เรียก preventDefault ปลดปล่อย compositor ให้ทำงานได้เลย

addEventListener('touchstart', handler, { passive: true });
addEventListener('wheel', handler, { passive: true });

13. บีบอัดและ code-split JS bundle ที่สำคัญ (กลาง · กลาง)

ถ้าคุณควบคุม bundler ได้ ตั้งเพดาน chunk size ไว้ที่ 50KB แบบ minified-gzipped LiteSpeed serve brotli ได้ดี ควรใช้ประโยชน์จากจุดนี้

14. แทนที่ carousel ที่หนักเกินไป (กลาง · กลาง)

Slick, Owl Carousel และ Swiper-แบบโหลดทุกอย่าง แต่ละตัวมี overhead ของ interaction 30-80ms ใช้ Swiper เฉพาะ module ที่จำเป็น หรือใช้ CSS scroll-snap สำหรับกรณีง่าย ๆ

15. ตั้งค่า LiteSpeed object cache ให้ถูกต้อง (กลาง · ต่ำ)

บนแพ็กเกจ Hostinger Business และ Cloud เปิดใช้ Memcached หรือ Redis สำหรับ WordPress object cache ช่วยลดเวลา execution ของ PHP ซึ่งช่วย INP ทางอ้อม เพราะ back-end ที่ช้ามักทำให้ handler ต้องรอ AJAX

16. หลีกเลี่ยงการอ่าน localStorage แบบ synchronous ใน handler (ต่ำ · ต่ำ)

การเข้าถึง localStorage แต่ละครั้งเป็นแบบ synchronous และอาจใช้เวลา 1-5ms บน cold cache ใน handler ที่ยิงถึง 10 ครั้งระหว่างการพิมพ์ ตัวเลขนี้สะสมได้ ใช้ IndexedDB พร้อม memory cache สำหรับข้อมูลที่ใช้บ่อย

17. Self-host font พร้อม font-display: swap (ต่ำ · ต่ำ)

ส่วนใหญ่ช่วย LCP แต่การโหลด font ที่ถูก block อาจทำให้ main thread หยุดชะงักตอน first paint ซึ่งทำให้ interaction แรก ๆ รู้สึกกระตุก

18. Preconnect ไปยัง origin ของ third-party ที่รู้จัก (ต่ำ · ต่ำ)

<link rel="preconnect" href="https://www.googletagmanager.com">
<link rel="preconnect" href="https://fonts.googleapis.com">

19. ลดสงคราม specificity ของ CSS (ต่ำ · กลาง)

Selector ที่ซ้อนลึกทำให้ style recalc ช้าลงตอน interaction เราเคยเห็นผลดีขึ้น 15-30ms จากการปรับ CSS ของ WordPress theme ที่มี selector ระดับ body.page .container .main .post .entry-content p ให้แบนราบขึ้น

20. ปิด WP-Cron สำหรับเว็บไซต์ที่มี traffic สูง (ต่ำ · ต่ำ)

โดยค่าเริ่มต้น WP-Cron รันในทุก request หน้าบ้าน บนเว็บไซต์ที่มี traffic สูง นั่นหมายความว่า cron task จะยิงระหว่างที่ผู้ใช้กำลัง interact ปิดมันใน wp-config.php:

define('DISABLE_WP_CRON', true);

แล้วตั้ง cron จริงผ่าน cPanel ของ Hostinger: */5 * * * * curl -s https://yoursite.com/wp-cron.php?doing_wp_cron

21. ตรวจสอบ admin bar (ต่ำ · ต่ำ)

สำหรับผู้ใช้ที่ login อยู่ WordPress จะ inject admin bar ที่หนักเข้าไป เราเห็นเจ้าของเว็บไซต์พลาดตรงนี้บ่อย — พวกเขาทดสอบเว็บตัวเองตอน login เห็น INP แย่แล้วตกใจ admin bar เพิ่ม overhead ของ interaction 30-60ms ทดสอบในสถานะผู้เยี่ยมชมที่ไม่ได้ login แทน

ลำดับที่เรานำเทคนิคเหล่านี้ไปใช้จริงในงานโปรดักชัน

สำหรับงานลูกค้าทั่วไป เราจัดลำดับงานแบบนี้:

1. สัปดาห์ที่ 1: เทคนิค 1, 2, 7, 11, 12, 18, 21 — ทั้งหมดเป็นแบบ "ผลกระทบสูง ความยากต่ำ" หรือการ cleanup ล้วน ๆ
2. สัปดาห์ที่ 2: เทคนิค 4, 5, 6, 8, 10 — การผ่าตัด main thread
3. สัปดาห์ที่ 3-4: เทคนิค 3, 9, 13, 14 — การ refactor ขนาดใหญ่กว่า ขึ้นอยู่กับความพร้อมของลูกค้า
4. ต่อเนื่อง: เทคนิค 15-20 เป็นการ cleanup ตามหลัง

เมื่อจบสัปดาห์ที่ 2 เรามักเห็นค่ามัธยฐาน INP อยู่ที่ 180-220ms ทั่วทั้งเว็บไซต์ งานในสัปดาห์ที่ 3-4 จะดึง 75th percentile ให้ต่ำกว่า 200ms ได้อย่างสม่ำเสมอ — ซึ่งเป็นค่าที่ CrUX วัดและ Search Console รายงาน

การตั้งค่าเฉพาะของ Hostinger ที่เราเปลี่ยนทุกครั้ง

ค่าเริ่มต้นของ Hostinger LiteSpeed ใช้ได้แต่ค่อนข้าง conservative เราจะ override ค่าเหล่านี้เสมอ:

"INP คือ metric ที่ shared hosting ยังใช้ได้ผลอยู่ คุณไม่จำเป็นต้องมี VPS ราคา $400/เดือน — คุณแค่ต้องส่ง JavaScript น้อยลงและรันมันอย่างฉลาดขึ้น"

การวัด INP อย่างถูกต้อง

field data สำคัญกว่า lab data เสมอ "Origin Summary" ของ PageSpeed Insights ดึงข้อมูลจาก CrUX (ผู้ใช้ Chrome จริง) และนี่คือสิ่งที่ Google ใช้จริง คะแนน "Performance" แบบ lab ทำให้เข้าใจผิดสำหรับ INP เพราะเครื่องมือ lab จำลอง interaction แค่ครั้งเดียว ในขณะที่ผู้ใช้จริงทำหลายสิบครั้ง เราติดตั้ง snippet web-vitals.js เล็ก ๆ บนทุกเว็บไซต์ลูกค้าเพื่อส่งค่า INP, LCP และ CLS ไปยัง Cloudflare Worker และเราตรวจสอบไขว้กับ CrUX ทุกสัปดาห์

<script type="module">
import {onINP} from 'https://unpkg.com/web-vitals@4?module';
onINP(({value, rating, attribution}) => {
  navigator.sendBeacon('/inp-log', JSON.stringify({
    value, rating, target: attribution.interactionTarget, type: attribution.interactionType
  }));
});
</script>

นี่คือชุด instrumentation เดียวกับที่เราป้อนเข้าscraper ที่รัน 10,000 คำค้นหาทุกคืนสำหรับ benchmark ลูกค้า field interactionTarget บอกคุณว่า element ไหนคือตัวการ — มีค่ามากเมื่อ INP เกิด regression และคุณต้องหาต้นตอให้เร็ว

สิ่งที่เราไม่แนะนำ

• ย้ายจาก Hostinger ไป Cloudways/Kinsta เพื่อ "แก้" INP การย้าย hosting มีค่าใช้จ่ายเพิ่ม $50-150/เดือน แลกกับ TTFB ที่ดีขึ้นแค่ ~5ms INP แทบไม่ขยับเลย แก้ JS ก่อนดีกว่า
• ปลั๊กอิน caching ที่ทำงานหนักซ้อนทับ LiteSpeed การใช้ WP Rocket ซ้อนกับ LiteSpeed ทำให้ asset เดียวกันถูกประมวลผลซ้ำสอง และมักทำให้แย่ลง ใช้ตัวใดตัวหนึ่งพอ
• โหลด JS สำคัญแบบ type="module" โดยไม่มี fallback เบราว์เซอร์ Android รุ่นเก่าในไทยยังจัดการ modulepreload ต่างออกไป ควรมี nomodule fallback ไว้เสมอสำหรับ traffic ไทยประมาณ ~3%

อ่านเพิ่มเติม

INP เป็นหนึ่งใน technical SEO surface ที่เราวัดในทุกการตรวจสอบ ส่วนอื่น ๆ — คุณภาพของ schema graph, pattern การ crawl จาก server log, สิทธิ์การถูกอ้างอิงจาก AI และการควบคุมคุณภาพ programmatic — เติมเต็มด้านวิศวกรรมให้ครบ สำหรับ SMB ในกรุงเทพที่ใช้ Hostinger โดยเฉพาะ บริการ technical SEO ของเรารวม CWV optimization เข้ากับงาน schema และ content ที่ผลักดันอันดับ ทีมในบริษัทของเราจัดการงาน refactor ทางวิศวกรรมที่ลึกกว่านั้นเมื่อลูกค้าต้องการเลิกใช้ page builder, งานด้าน editorial และการทดสอบ CRO เมื่องานด้านความเร็วเสร็จแล้ว — ทั้งหมดอยู่ภายใต้หลังคาเดียวกัน