ลูกค้ากดเข้าเว็บไซต์แล้วเห็นหน้าเว็บ แต่ปุ่มยังไม่ตอบสนอง หรือกำลังจะกด “ติดต่อเรา” แล้วปุ่มกลับขยับหนีไปอีกตำแหน่ง เหตุการณ์แบบนี้วัดไม่ได้ด้วยคำว่า “เว็บโหลดเร็วดี” เพียงอย่างเดียว เพราะความเร็วที่ผู้ใช้รู้สึกมีหลายจังหวะ ตั้งแต่เห็นเนื้อหาหลัก กดใช้งาน ไปจนถึงความนิ่งของหน้าจอ
Google ใช้ชื่อ Core Web Vitals สำหรับชุดตัวชี้วัดประสบการณ์ผู้ใช้จริง 3 ค่า ได้แก่ Largest Contentful Paint (LCP), Interaction to Next Paint (INP) และ Cumulative Layout Shift (CLS) บทความนี้อธิบายว่าค่าแต่ละตัวบอกอะไร ใช้เกณฑ์ไหน และเจ้าของธุรกิจควรบรีฟทีมเว็บอย่างไร โดยอ้างอิงเอกสาร Google Search Central, web.dev และ Search Console ที่เผยแพร่อย่างเป็นทางการ ไม่ใช่ผลทดสอบเว็บไซต์ใดเว็บไซต์หนึ่ง
ตารางเกณฑ์ Core Web Vitals ที่ควรเก็บไว้อ้างอิง
| ตัวชี้วัด | วัดอะไร | ดี (Good) | ควรปรับปรุง | แย่ (Poor) |
|---|---|---|---|---|
| LCP | เวลาแสดงองค์ประกอบเนื้อหาที่ใหญ่ที่สุดในส่วนที่มองเห็น | ไม่เกิน 2.5 วินาที | มากกว่า 2.5 ถึง 4 วินาที | มากกว่า 4 วินาที |
| INP | ระยะเวลาตอบสนองต่อการโต้ตอบของผู้ใช้ | ไม่เกิน 200 มิลลิวินาที | มากกว่า 200 ถึง 500 มิลลิวินาที | มากกว่า 500 มิลลิวินาที |
| CLS | คะแนนการขยับขององค์ประกอบโดยไม่คาดหมาย | ไม่เกิน 0.1 | มากกว่า 0.1 ถึง 0.25 | มากกว่า 0.25 |
เกณฑ์ในตารางอ้างอิงจากเอกสารรายงาน Core Web Vitals ของ Google Search Console โดยพิจารณาข้อมูลประสบการณ์จริงที่เปอร์เซ็นไทล์ 75 แยกตามประเภทอุปกรณ์ตามที่มีข้อมูล ซึ่งหมายความว่าไม่ได้ตัดสินจากการเปิดเว็บเพียงครั้งเดียวในเครื่องของเจ้าของเว็บไซต์ ตัวเลขข้างต้นเป็นเกณฑ์คุณภาพประสบการณ์ ไม่ใช่คะแนนที่จะบอกว่าเว็บไซต์อันดับหนึ่งใน Google โดยอัตโนมัติ
LCP: ลูกค้ารออีกกี่วินาทีกว่าจะเห็นเนื้อหาที่สำคัญ
ลองนึกถึงหน้า Landing Page ที่มีภาพ Hero ขนาดใหญ่ด้านบน ข้อความและปุ่มติดต่ออาจแสดงแล้ว แต่รูปใหญ่ยังว่างอยู่เป็นเวลานาน ผู้ใช้มีโอกาสรู้สึกว่าหน้าเว็บยังมาไม่ครบ LCP ช่วยสะท้อนจังหวะที่องค์ประกอบใหญ่ที่สุดในพื้นที่ที่เห็นปรากฏบนจอ ซึ่งอาจเป็นภาพ วิดีโอ หรือบล็อกข้อความ ไม่จำเป็นต้องเป็นรูปเสมอไป
กรณีที่พบบ่อยในเว็บไซต์ธุรกิจคืออัปโหลดภาพ Hero ขนาดใหญ่โดยไม่บีบอัด จัดลำดับดาวน์โหลดภาพสำคัญไว้หลังไฟล์อื่น หรือให้สคริปต์จำนวนมากขวางการแสดงผล ปัญหาเดียวกันอาจเกิดกับหน้าแรกที่มีสไลด์หลายภาพ แม้ผู้ดูเห็นหน้าเว็บบางส่วนแล้วก็ตาม
สิ่งที่ควรถามผู้พัฒนาไม่ใช่แค่ “ลดขนาดรูปได้ไหม” แต่คือ องค์ประกอบใดเป็น LCP ของหน้าเป้าหมายจริง และเวลาส่วนใหญ่หายไประหว่างตอบสนองจากเซิร์ฟเวอร์ ดาวน์โหลดทรัพยากร หรือรอการแสดงผล หลังรู้สาเหตุจึงค่อยจัดลำดับงาน เช่น ปรับขนาดและรูปแบบภาพ ใช้ไฟล์ภาพเหมาะกับมือถือ หรือเลื่อนโหลดภาพที่อยู่นอกจอแทนการเลื่อนโหลด Hero ที่ต้องเห็นทันที
INP: เว็บเห็นแล้ว แต่กดได้ทันใจหรือเปล่า
INP เป็นตัววัดการตอบสนองต่อการคลิก แตะ และกดแป้นพิมพ์ตลอดการใช้งานหน้าเว็บ ไม่ใช่ความเร็วตอนเปิดหน้าเว็บครั้งแรกเท่านั้น ตัวเลข INP สูงอาจเกิดจาก JavaScript ทำงานหนักจนเบราว์เซอร์ไม่มีเวลาจัดการกับการกดของผู้ใช้
ตัวอย่างที่เจ้าของธุรกิจพบได้จริงคือผู้ใช้กรอกแบบฟอร์มอยู่แล้วพิมพ์สะดุด เมนูเปิดช้า หรือกดปุ่มเปลี่ยนแท็บแล้วไม่มีการเปลี่ยนแปลงให้เห็นทันที สาเหตุอาจมาจากงานคำนวณบนหน้าเว็บที่กินเวลานาน โค้ดติดตามผลหลายชุดทำงานพร้อมกัน หรือส่วนประกอบที่ต้องคำนวณใหม่มากเกินความจำเป็น
หากต้องแก้ INP ให้ทีมงานลองทดสอบการโต้ตอบหลายจุด เช่น เมนูมือถือ ตัวเลือกแพ็กเกจ ปุ่มเปิดแบบฟอร์ม และช่องกรอกข้อมูล แล้วตรวจช่วงเวลาที่เบราว์เซอร์ติดขัด การลด JavaScript ที่ไม่จำเป็น แบ่งงานหนักไม่ให้บล็อกการโต้ตอบ และออกแบบการตอบกลับของปุ่มให้ชัดเจน เป็นแนวทางตรวจสอบได้ แต่ควรเลือกวิธีตามการวัดจริง ไม่ใช่สุ่มลบสคริปต์ทุกตัว เพราะบางส่วนอาจเกี่ยวข้องกับการทำงานหรือการวัด Conversion
CLS: ปุ่มที่ลูกค้ากำลังจะกดห้ามกระโดดหนี
CLS เป็นคะแนนการเปลี่ยนตำแหน่งองค์ประกอบบนหน้าจอโดยไม่คาดหมาย ไม่ได้มีหน่วยเป็นวินาที ลองอ่านบทความบนมือถือแล้วอยู่ ๆ แบนเนอร์หรือรูปที่เพิ่งโหลดดันเนื้อหาลง หรือกำลังแตะปุ่มสั่งซื้อแต่ตำแหน่งเลื่อนไปเพราะมีป๊อปอัปเข้ามา นั่นคือประสบการณ์ที่ CLS ช่วยสะท้อน
วิธีป้องกันส่วนหนึ่งเริ่มตั้งแต่การออกแบบ: กำหนดพื้นที่ของรูปและวิดีโอล่วงหน้า สำรองพื้นที่ให้ส่วนประกอบที่โหลดภายหลัง เลือกวิธีโหลดฟอนต์ให้ลดการขยับ และอย่าแทรกแบนเนอร์เหนือเนื้อหาที่ผู้ใช้กำลังอ่านโดยไม่มีพื้นที่รองรับ ส่วนที่เป็นแอนิเมชันหรือการเปลี่ยนสถานะจากการกระทำของผู้ใช้มีรายละเอียดในการคำนวณต่างจากการขยับแบบไม่คาดหมาย จึงต้องดูสาเหตุจากเครื่องมือ ไม่ใช่นับทุกการเคลื่อนไหวว่าเป็นปัญหา
ทำไมคะแนน Lighthouse สีเขียวแล้ว Search Console ยังบอกว่าต้องปรับปรุง
นี่คือคำถามที่มักเกิดขึ้นหลังส่งมอบเว็บไซต์ เพราะเครื่องมือสองแบบไม่ได้ตอบคำถามเดียวกันทั้งหมด Lighthouse และ PageSpeed Insights ในส่วน Lab ใช้สภาพแวดล้อมการทดสอบจำลอง ส่วนรายงาน Core Web Vitals ใน Search Console อาศัยข้อมูลประสบการณ์จากผู้ใช้จริงที่มีข้อมูลเพียงพอ ความต่างของมือถือ เครือข่าย เครื่องผู้ใช้ การใช้งานจริง และช่วงเวลาของข้อมูลทำให้ตัวเลขไม่จำเป็นต้องตรงกัน
ดังนั้นถ้าฝ่ายพัฒนาแคปหน้าจอคะแนน 100 แต่ผู้ใช้ยังบ่นว่าเมนูหน่วง อย่าเพิ่งสรุปว่าผู้ใช้เข้าใจผิด ให้ตรวจข้อมูล Field และทดลองการใช้งานจริงร่วมกัน รวมถึงระวังว่า URL ที่มีข้อมูลไม่เพียงพออาจไม่มีรายงานแยกของตัวเอง ไม่ใช่มีคะแนนดีโดยปริยาย
ลำดับตรวจงานสำหรับเว็บธุรกิจที่มีทั้งบทความและหน้ารับลูกค้า
| กลุ่มหน้า | จุดที่ต้องดู | คำถามก่อนแก้ |
|---|---|---|
| หน้าแรก / Landing Page | Hero, CTA, ฟอร์ม, สคริปต์ | ภาพแรกแสดงทันไหม และกดติดต่อได้ทันทีหรือไม่ |
| หน้าบริการ | ภาพตัวอย่าง, ตารางราคา, แท็บ | เนื้อหาหรือปุ่มขยับขณะเลื่อนอ่านหรือไม่ |
| บทความ | ภาพแทรก, ฟอนต์, ตาราง | อ่านบนมือถือได้ต่อเนื่องโดยไม่มีเนื้อหากระโดดหรือไม่ |
| ฟอร์มติดต่อ | ช่องกรอกและข้อความตรวจสอบ | ปุ่มและช่องกรอกตอบสนองได้ดีโดยไม่ทำข้อมูลหายหรือไม่ |
ตารางนี้เป็นแนวทางจัดลำดับงานที่ Social Plus System เรียบเรียง ไม่ใช่เกณฑ์ใหม่ของ Google ในทางปฏิบัติให้เริ่มที่หน้าที่สร้างโอกาสทางธุรกิจสูงหรือมีผู้ใช้ได้รับผลกระทบมาก แล้วเก็บค่าก่อนแก้และหลังแก้จากเครื่องมือเดียวกันภายใต้เงื่อนไขที่ใกล้เคียงกัน เพื่อแยกการปรับปรุงจริงออกจากความผันผวนของผลวัด
หากหน้าเว็บมีการติดตั้ง Google Ads Conversion, Tag Manager หรือระบบฟอร์มที่ใช้รับลีดอยู่แล้ว การแก้ปัญหาความเร็วต้องทดสอบการส่งฟอร์มและการบันทึก Event ซ้ำด้วย ไม่ควรเอาสคริปต์ออกเพียงเพื่อให้ตัวเลขความเร็วดูดีแล้วทำให้ธุรกิจวัดผลไม่ได้
Core Web Vitals มีผลกับ SEO และ AI Search อย่างไร
Google ระบุว่าประสบการณ์ของหน้าเว็บ รวมถึง Core Web Vitals สอดคล้องกับสิ่งที่ระบบจัดอันดับหลักพยายามให้ความสำคัญ แต่ การผ่านเกณฑ์ทั้งสามตัวไม่ได้รับประกันอันดับที่ดี เนื้อหาที่ตอบโจทย์ค้นหา ความเกี่ยวข้อง การเข้าถึงหน้าเว็บได้ และคุณภาพโดยรวมยังสำคัญ การลดเวลาโหลดจึงควรเป็นส่วนหนึ่งของงาน SEO ไม่ใช่เหตุผลให้หยุดปรับเนื้อหาหรือโครงสร้างเว็บไซต์
สำหรับ AI Search หลักคิดที่ใช้ได้อย่างระมัดระวังคือช่วยให้ผู้ใช้และระบบเข้าถึงเนื้อหาที่มีความหมายได้ชัดเจน เช่น หัวข้อที่ตรงคำถาม คำอธิบายตารางที่อ่านเข้าใจได้ และเนื้อหาหลักที่ไม่ถูกซ่อนด้วยกลไกซับซ้อน แต่ไม่มีหลักฐานจากเกณฑ์ Core Web Vitals ที่บอกว่า “INP ต่ำแล้ว AI จะอ้างอิงบทความเพิ่มขึ้นกี่เปอร์เซ็นต์” จึงไม่ควรขายคำสัญญาประเภทนั้น
ทีมที่กำลังวาง แผน SEO สำหรับเว็บไซต์ธุรกิจ ควรตรวจคุณภาพเนื้อหาและการใช้งานควบคู่กัน ส่วนการปรับเว็บเพื่อการวัดผลให้แยกปัญหาที่เกิดจริงออกจากข้อสันนิษฐานก่อนมอบหมายงานพัฒนา
วิธีใช้ตารางนี้เป็นแหล่งอ้างอิง
เกณฑ์ LCP, INP และ CLS เป็นข้อมูลของ Google เอกสารต้นทางอยู่ในหัวข้อแหล่งอ้างอิงด้านล่าง ผู้นำไปใช้ควรอ้าง Google เมื่อกล่าวถึงนิยามและเกณฑ์ ส่วนตารางตัวอย่างงานของเว็บไซต์ธุรกิจและคำแนะนำในการจัดลำดับตรวจสอบเป็นการเรียบเรียงของ Social Plus System วันที่ 29 ตุลาคม 2026 อย่านำตัวอย่างสถานการณ์ไปนำเสนอว่าเป็นสถิติจากการสำรวจเว็บไซต์ไทย
คำถามที่พบบ่อย
เว็บไซต์ต้องได้ Core Web Vitals ผ่านทุกข้อจึงจะติดอันดับ Google หรือไม่?
ไม่จำเป็นครับ Google แนะนำให้ทำคะแนนดีเพื่อประสบการณ์ของผู้ใช้ แต่ไม่ได้รับประกันอันดับจากตัวชี้วัดเพียงสามค่า เนื้อหาที่เกี่ยวข้องและมีประโยชน์ยังเป็นองค์ประกอบสำคัญ ควรแก้ประสบการณ์ที่มีปัญหาจริงควบคู่กับการปรับเนื้อหา
ถ้าคะแนน PageSpeed Insights ดี แต่ Search Console ขึ้นสีเหลือง ควรเชื่ออะไร?
ให้ดูชนิดของข้อมูลก่อน ผลทดลองใน Lab และข้อมูล Field จากผู้ใช้จริงมีจุดประสงค์ต่างกัน ใช้ Search Console ระบุปัญหาที่ผู้ใช้พบ แล้วใช้เครื่องมือทดสอบหาสาเหตุ หากข้อมูลยังไม่พอ ไม่ควรสรุปว่าหน้านั้นผ่านหรือไม่ผ่าน
ค่า INP แทนค่า FID แล้วหรือยัง?
ใช่ INP เข้ามาแทน First Input Delay (FID) ใน Core Web Vitals ตั้งแต่เดือนมีนาคม 2024 เพราะวัดการตอบสนองตลอดการใช้งานได้ครอบคลุมกว่า หากเอกสารตรวจเว็บยังใช้ FID เป็นเกณฑ์หลัก ควรปรับรายการตรวจให้เป็นปัจจุบัน
แหล่งอ้างอิง
Google Search Central. Understanding Core Web Vitals and Google search results (ปรับปรุง 2025). เข้าถึงวันที่: 29 ตุลาคม 2026.
Google Search Console Help. Core Web Vitals report (เอกสารออนไลน์). เข้าถึงวันที่: 29 ตุลาคม 2026.
web.dev. How the Core Web Vitals metrics thresholds were defined (ปรับปรุง 2025). เข้าถึงวันที่: 29 ตุลาคม 2026.
คำถามที่พบบ่อยเกี่ยวกับ Core Web Vitals คืออะไร
เว็บไซต์ต้องได้ Core Web Vitals ผ่านทุกข้อจึงจะติดอันดับ Google หรือไม่?
ไม่จำเป็นครับ Google แนะนำเกณฑ์เหล่านี้เพื่อประสบการณ์ผู้ใช้ที่ดี แต่ไม่มีการรับประกันอันดับจากการผ่าน LCP, INP และ CLS เพียงอย่างเดียว การตอบโจทย์คำค้น เนื้อหาที่มีคุณภาพ และการเข้าถึงหน้าเว็บได้ยังสำคัญ จึงควรปรับประสิทธิภาพและคุณภาพเนื้อหาควบคู่กัน
คะแนน PageSpeed ดีแต่ Search Console ขึ้นสีเหลือง ควรเชื่ออะไร?
ให้ดูชนิดข้อมูลก่อนครับ Search Console ใช้ข้อมูลจากการใช้งานจริง ส่วนผล Lab จำลองเงื่อนไขการทดสอบ จึงอาจแตกต่างจากเครื่องและเครือข่ายของผู้ใช้ ควรใช้ข้อมูล Field ระบุปัญหาและใช้เครื่องมือ Lab หาสาเหตุ ไม่ตัดสินจากการรันครั้งเดียว
INP แทน FID แล้วหรือยัง?
ใช่ครับ INP เข้ามาแทน FID ใน Core Web Vitals ตั้งแต่เดือนมีนาคม 2024 เพราะครอบคลุมการตอบสนองต่อการโต้ตอบตลอดการเข้าชม ไม่ได้มองเฉพาะครั้งแรก หากเช็กลิสต์เว็บยังใช้ FID เป็นเกณฑ์หลัก ควรปรับเป็น INP และตรวจตามข้อมูลจริง
ดูขอบเขตบริการที่เกี่ยวข้อง วิธีทำงาน และข้อมูลที่ควรเตรียมก่อนให้ทีมประเมิน
ดูบริการที่เกี่ยวข้องส่งรายละเอียดงานให้ทีมประเมิน
กรอกชื่อ เบอร์โทร และรายละเอียดที่อยากให้ช่วย ทีมจะติดต่อกลับเพื่อประเมินแนวทาง