ไทยGBP Peak Team

PageSpeed 99 แต่ Core Web Vitals ไม่ผ่าน: ตรวจ INP อย่างไร

แยกคะแนน Lighthouse ออกจากข้อมูลผู้ใช้จริง อ่านค่า INP และวางแผนแก้ทีละจุด พร้อมวิธีตรวจว่าเว็บยังทำงานและข้อจำกัดข้อมูลย้อนหลัง 28 วัน

แผนภาพอธิบายว่าคะแนน Lighthouse เป็นการทดสอบจำลอง ส่วน Core Web Vitals ใช้ข้อมูลผู้ใช้จริงย้อนหลัง ตัวเลขเป็นตัวอย่าง

คะแนน Performance สีเขียวกับข้อความ Core Web Vitals ไม่ผ่านเกิดพร้อมกันได้ ก่อนเปลี่ยนโค้ดเพื่อไล่คะแนน 100 ให้แยกก่อนว่ากำลังอ่านผลจากการทดสอบจำลอง หรือประสบการณ์ของผู้ใช้จริง เพราะสองส่วนนี้ตอบคนละคำถาม

คู่มือนี้อธิบายวิธีอ่านรายงานและวางแผนแก้ปัญหา ไม่ได้ตรวจเว็บไซต์ใดเป็นรายกรณี ตัวเลขตัวอย่างด้านล่างใช้ประกอบการอ่านผลเท่านั้น ไม่ใช่ผลทดสอบเว็บไซต์ปัจจุบันหรือคำรับประกันอันดับ Google

คะแนน Performance กับผล Core Web Vitals ต่างกันตรงไหน

เอกสาร PageSpeed Insights ของ Google แยกข้อมูลเป็นสองส่วน ข้อมูลจำลองมาจาก Lighthouse และช่วยหาจุดที่ควรตรวจระหว่างทดสอบ ส่วนข้อมูลผู้ใช้จริงมาจาก Chrome User Experience Report หรือ CrUX ซึ่งสะท้อนการใช้งานย้อนหลัง 28 วัน

Lighthouse อาจให้คะแนนสูงในการเปิดหน้าทดสอบครั้งหนึ่ง แต่ผู้ใช้จริงอาจกดเมนู ค้นหาสินค้า หรือใช้ฟอร์มแล้วเจอการตอบสนองช้า การทำคะแนนให้สูงขึ้นอีกหนึ่งจุดจึงไม่จำเป็นต้องแก้ปัญหาที่ทำให้ข้อมูลจริงไม่ผ่าน

คู่มือการคิดคะแนน Lighthouse อธิบายว่าคะแนนเป็นผลรวมแบบถ่วงน้ำหนักของตัวชี้วัด และเปลี่ยนได้ตามเงื่อนไขการทดสอบ เอกสารยังระบุว่าคะแนน 100 ทำได้ยากและไม่ได้เป็นสิ่งที่คาดหวังจากทุกเว็บไซต์

อ่านตัวชี้วัดที่ไม่ผ่านให้เจอ

Core Web Vitals ครอบคลุมการแสดงเนื้อหาหลัก การตอบสนองต่อการใช้งาน และความนิ่งของหน้าจอ เกณฑ์ระดับดีใน Web Vitals คือ LCP ไม่เกิน 2.5 วินาที, INP ไม่เกิน 200 มิลลิวินาที และ CLS ไม่เกิน 0.1 โดยพิจารณาที่เปอร์เซ็นไทล์ 75 และแยกมือถือกับเดสก์ท็อป

ตัวอย่างสมมติ: รายงานมี LCP 1.1 วินาที, INP 344 มิลลิวินาที และ CLS 0 แม้ Performance จะเป็น 99 แต่ INP ยังอยู่ในช่วงต้องปรับปรุง ควรเริ่มสืบหาการโต้ตอบที่ช้า แทนการบีบรูปทุกไฟล์เพื่อพยายามให้คะแนนกลายเป็น 100

ก่อนเทียบผลให้จดว่าเป็นข้อมูลระดับ URL หรือระดับต้นทางเว็บไซต์ หากข้อมูลของหน้านั้นไม่พอ PageSpeed Insights อาจใช้ข้อมูลระดับต้นทางแทน และถ้าข้อมูลยังไม่พออีกก็อาจไม่แสดงผลผู้ใช้จริง การไม่มีข้อมูลจึงไม่ใช่หลักฐานว่าผ่านหรือไม่ผ่าน

สำหรับรายงานที่มีข้อมูลครบ การผ่านต้องได้ระดับดีในตัวชี้วัดทั้งสาม เอกสาร PageSpeed Insights มีข้อยกเว้นเมื่อข้อมูล INP ไม่พอ: ยังอาจประเมินผ่านจาก LCP และ CLS ที่ดีได้ จึงควรอ่านสถานะและขอบเขตข้อมูลจริงในรายงาน ไม่เดาผลจากช่องที่ว่าง

INP สูงต้องตรวจอะไร

แนวทางปรับ INP ของ web.dev แนะนำให้เริ่มจากข้อมูลจริง แล้วหาการโต้ตอบที่ทำให้ช้า เช่น การแตะเมนู กดค้นหา หรือพิมพ์ในฟอร์ม จากนั้นทำให้เกิดอาการซ้ำในสภาพทดสอบก่อนเลือกวิธีแก้ ตัวอย่างเหล่านี้เป็นรายการที่ควรลอง ไม่ได้แปลว่าเมนูหรือฟอร์มของทุกเว็บเป็นต้นเหตุ

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

ลองทำบันทึกสั้น ๆ ให้ผู้พัฒนาตรวจต่อ:

  • URL และชนิดอุปกรณ์ที่ใช้ พร้อมวันเวลาทดสอบ
  • ขั้นตอนก่อนอาการ เช่น เปิดหน้าสินค้าแล้วแตะตัวกรองครั้งแรก
  • สิ่งที่ควรเกิดกับสิ่งที่เกิดจริง เช่น แตะแล้วปุ่มยังไม่เปลี่ยนสถานะ
  • หลักฐานจากการบันทึก Performance และรายการสคริปต์ที่เกี่ยวข้อง
  • ขอบเขตที่ยังไม่รู้ เช่น เกิดเฉพาะมือถือบางรุ่นหรือทุกเครื่อง

หากพบงาน JavaScript ยาวหรือการวาดหน้าจอที่ใช้เวลามาก ให้ผู้พัฒนาเลือกแก้ตามหลักฐาน เช่น แบ่งงานหนัก ลดงานที่ไม่จำเป็นในจังหวะกด หรือทำให้ส่วนที่เปลี่ยนบนหน้าจอเล็กลง การเลือกวิธีใดต้องดูโค้ดและเส้นทางใช้งานจริง ไม่ควรปิดระบบติดตาม ฟอร์ม หรือส่วนรักษาความปลอดภัยทั้งหมดเพื่อไล่คะแนน

แก้ทีละจุดและตรวจว่าเว็บยังทำงาน

หากเคยปรับแล้วเว็บพัง ให้หยุดเพิ่มการเปลี่ยนแปลงและใช้เวอร์ชันที่กู้คืนได้เป็นจุดเริ่มต้น ทดลองแก้บนสำเนาทดสอบ พร้อมเก็บรายการไฟล์หรือการตั้งค่าที่เปลี่ยน วิธีนี้เป็นข้อเสนอในการควบคุมงาน ไม่ใช่ข้อกำหนดจาก Google

หลังแก้หนึ่งประเด็น ให้ลองเส้นทางเดิมซ้ำ และตรวจเส้นทางสำคัญของเว็บ เช่น เมนู ค้นหา ส่งฟอร์ม และปุ่มติดต่อ บันทึกผลก่อนกับหลังด้วยเงื่อนไขที่เทียบกันได้ ถ้าอาการตอบสนองดีขึ้นแต่ฟอร์มส่งไม่ได้ การแก้นั้นยังไม่พร้อมใช้งาน

ผลจำลองช่วยตรวจการเปลี่ยนแปลงได้ทันที แต่ข้อมูล CrUX ยังรวมประสบการณ์ย้อนหลัง 28 วัน จึงไม่ควรคาดว่าค่าผู้ใช้จริงจะเปลี่ยนทั้งหมดทันทีหลังเผยแพร่ และไม่ควรรับปากว่าจะผ่านในวันใด หากยังไม่มีข้อมูลผู้ใช้จริงมากพอ

เกี่ยวกับ SEO อย่างไร

Google Search Central อธิบาย Core Web Vitals ว่าเป็นตัวชี้วัดประสบการณ์ผู้ใช้จริงและแนะนำให้เว็บไซต์ทำให้ดี การปรับความเร็วควรทำเพื่อให้คนใช้งานหน้าเว็บได้สะดวกด้วย อย่าใช้คะแนน Performance เพียงตัวเดียวเป็นหลักฐานว่า SEO ทั้งเว็บไซต์ดีแล้ว หรือสัญญาว่าปรับ INP แล้วอันดับจะเพิ่มแน่นอน

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

Performance 99 แต่ Core Web Vitals ไม่ผ่านได้หรือไม่

ได้ คะแนน Lighthouse มาจากการทดสอบจำลอง ส่วนผลผู้ใช้จริงใช้ข้อมูล CrUX คนละชุด ต้องอ่านว่าตัวชี้วัดใดไม่ผ่านและเป็นข้อมูลระดับ URL หรือต้นทางเว็บไซต์

INP 344 มิลลิวินาทีอยู่ในระดับใด

ตามเกณฑ์ PageSpeed Insights ค่าเกิน 200 ถึง 500 มิลลิวินาทีอยู่ในช่วงต้องปรับปรุง แต่ตัวเลขอย่างเดียวยังไม่บอกว่าสคริปต์หรือการกดใดเป็นสาเหตุ

ต้องทำคะแนนให้ได้ 100 ก่อนหรือไม่

ไม่ควรตั้งคะแนน 100 เป็นเงื่อนไขแทนการแก้อาการจริง ให้เลือกตัวชี้วัดและเส้นทางใช้งานที่มีปัญหา แล้วตรวจทั้งความเร็วและการทำงานหลังแก้

แก้แล้วข้อมูลผู้ใช้จริงจะเปลี่ยนทันทีหรือไม่

ไม่ทั้งหมด ข้อมูล CrUX ใน PageSpeed Insights ใช้ช่วงย้อนหลัง 28 วัน จึงยังอาจรวมการใช้งานก่อนแก้ ต้องติดตามด้วยขอบเขตและอุปกรณ์ที่เทียบกันได้

ตรวจแหล่งข้อมูลทางการวันที่ 26 ตุลาคม 2569 ไม่มีการวัดผลเว็บไซต์ของผู้อ่านหรือรับประกันผลการจัดอันดับในบทความนี้

รับบทความใหม่ทางอีเมล

เช็กลิสต์และเทคนิค Local SEO สำหรับธุรกิจไทย ส่งเมื่อมีใหม่ ยกเลิกได้ทุกเมื่อ