Core Web Vitals คืออะไร? LCP, INP, CLS และวิธีแก้

Core Web Vitals คือชุดตัวชี้วัด 3 ค่าที่ Google ใช้วัดประสบการณ์ของผู้ใช้จริงบนหน้าเว็บ ได้แก่ LCP ที่วัดความเร็วในการโหลดเนื้อหาหลัก, INP ที่วัดความไวในการตอบสนองเมื่อผู้ใช้คลิกหรือแตะ และ CLS ที่วัดความนิ่งของหน้าเว็บระหว่างใช้งาน ทั้ง 3 ค่าวัดจากการเข้าชมจริงของผู้ใช้ Chrome ไม่ได้มาจากคะแนนของเครื่องมือทดสอบเพียงอย่างเดียว บทความนี้อธิบายตามลำดับ ได้แก่ Core Web Vitals คืออะไรและวัดอะไรบ้าง, Core Web Vitals มีผลต่ออันดับ SEO แค่ไหน, LCP คืออะไรและวิธีแก้ LCP ช้า, INP คืออะไรและวิธีแก้ INP สูง, CLS คืออะไรและวิธีแก้หน้าเว็บขยับเอง และวิธีตรวจ Core Web Vitals ด้วย PageSpeed Insights และ Search Console

Core Web Vitals คืออะไร และวัดอะไรบ้าง

Core Web Vitals วัด 3 ด้านของประสบการณ์ใช้งานหน้าเว็บ คือการโหลด การตอบสนอง และความนิ่งของเลย์เอาต์ ตัวชี้วัดชุดนี้เป็นงานส่วนหนึ่งของ Technical SEO ซึ่งหมายถึงการดูแลโครงสร้างเบื้องหลังของเว็บให้ Google เก็บข้อมูลได้ครบและผู้ใช้เปิดหน้าได้ลื่น งานด้านความเร็วจึงอยู่ในเช็กลิสต์ Technical SEO ฉบับเต็ม ร่วมกับเรื่อง Crawl, Index และโครงสร้าง URL

แต่ละค่ามีเกณฑ์ “ดี” ที่ชัดเจน หน้า Web Vitals ของ web.dev กำหนดว่า LCP ควรเกิดขึ้นภายใน 2.5 วินาทีหลังหน้าเว็บเริ่มโหลด, INP ควรไม่เกิน 200 มิลลิวินาที และ CLS ควรไม่เกิน 0.1 ตารางนี้สรุปเกณฑ์ทั้ง 3 ระดับตามหน้าความช่วยเหลือเรื่องรายงาน Core Web Vitals ของ Search Console

เกณฑ์ผ่านไม่ได้ดูจากการเข้าชมครั้งเดียว web.dev ระบุว่าให้วัดที่เปอร์เซ็นไทล์ที่ 75 ของการโหลดหน้าเว็บ โดยแยกมือถือกับเดสก์ท็อป หมายความว่าอย่างน้อย 3 ใน 4 ของการเข้าชมต้องได้ค่าในเกณฑ์ดี และหน้าเว็บจะถือว่าผ่าน Core Web Vitals เมื่อทั้ง 3 ค่าผ่านพร้อมกันที่เปอร์เซ็นไทล์นี้ ตัวชี้วัดในชุดนี้ยังเปลี่ยนได้ตามเวลา web.dev ระบุว่าเมตริกที่เสถียรแล้วจะไม่เปลี่ยนเกินปีละ 1 ครั้ง ตัวอย่างที่ชัดที่สุดคือ INP ที่เข้ามาแทน FID

Core Web Vitals มีผลต่ออันดับ SEO แค่ไหน

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

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

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

LCP คืออะไร และวิธีแก้ LCP ช้า

LCP (Largest Contentful Paint) คือเวลาตั้งแต่ผู้ใช้เริ่มเปิดหน้าจนเนื้อหาชิ้นที่ใหญ่ที่สุดในหน้าจอแรกแสดงผลเสร็จ เช่น รูปปก แบนเนอร์ หรือย่อหน้าแรกของบทความ ค่าที่ดีคือไม่เกิน 2.5 วินาที และคู่มือ Optimize LCP ของ web.dev แบ่งเวลา LCP ออกเป็น 4 ช่วง พร้อมสัดส่วนเวลาที่แต่ละช่วงควรใช้โดยประมาณ

• Time to First Byte (TTFB) เวลาตั้งแต่ผู้ใช้เริ่มโหลดหน้าจนเบราว์เซอร์ได้รับไบต์แรกของ HTML ควรใช้ราว 40% ของเวลา LCP
• Resource load delay ช่วงรอระหว่างได้ HTML จนเบราว์เซอร์เริ่มโหลดไฟล์ของ LCP เช่น รูปปก ควรน้อยกว่า 10%
• Resource load duration เวลาที่ใช้โหลดไฟล์ LCP เอง ควรใช้ราว 40%
• Element render delay ช่วงหลังโหลดไฟล์เสร็จจนองค์ประกอบแสดงบนจอครบ ควรน้อยกว่า 10%

วิธีแก้ LCP ช้าจึงเริ่มจากหาว่าช่วงไหนยาวเกินสัดส่วน แล้วแก้ตรงช่วงนั้น web.dev แนะนำแนวทางหลักดังนี้

• ลด TTFB ด้วยแคชหน้าเว็บหรือ CDN และตัด Redirect ที่ไม่จำเป็นก่อนถึงหน้าจริง
• ให้เบราว์เซอร์เห็นรูป LCP ตั้งแต่ใน HTML ไม่ซ่อนไว้ใน CSS หรือ JavaScript ใส่ fetchpriority=”high” และห้ามใส่ Lazy Load ให้รูปนี้
• ลดขนาดไฟล์รูป ด้วยฟอร์แมตใหม่อย่าง WebP หรือ AVIF และย่อขนาดให้พอดีกับที่แสดงจริง
• ลด CSS และ JavaScript ที่บล็อกการแสดงผล ไม่วางสคริปต์แบบ synchronous ไว้ใน <head> และแบ่งงาน JavaScript ที่ยาวให้สั้นลง

ตัวอย่างโค้ดของรูปปกที่เป็น LCP ซึ่งตั้งค่าให้เบราว์เซอร์โหลดก่อนและไม่หน่วงด้วย Lazy Load

<img src="/images/cover.webp" width="1200" height="630"
     fetchpriority="high" alt="คำอธิบายรูป">

ไม่แนะนำสำหรับรูป LCP
<img src="/images/cover.webp" loading="lazy" alt="คำอธิบายรูป">

INP คืออะไร และวิธีแก้ INP สูง

INP (Interaction to Next Paint) คือค่าที่วัดว่าหลังผู้ใช้คลิก แตะ หรือกดแป้นพิมพ์ หน้าเว็บใช้เวลานานเท่าไรกว่าจะแสดงผลตอบสนองบนจอ หน้าอธิบาย INP ของ web.dev ระบุว่า INP สังเกตการโต้ตอบทั้งหมดตลอดการเข้าชมหน้านั้น แล้วใช้การโต้ตอบที่ยาวที่สุดเป็นค่าสุดท้ายโดยตัดค่าผิดปกติทางสถิติออก ค่าที่ดีคือไม่เกิน 200 มิลลิวินาที ส่วนการเลื่อนหน้า การวางเมาส์ และการซูม ไม่ถูกนับรวม

INP เข้ามาแทน FID (First Input Delay) อย่างเป็นทางการเมื่อวันที่ 12 มีนาคม 2024 ตามประกาศของทีม Chrome บน web.dev เหตุผลคือ FID วัดเฉพาะความหน่วงก่อนเริ่มประมวลผลของการโต้ตอบครั้งแรก ขณะที่ INP วัดทุกการโต้ตอบ ตั้งแต่ความหน่วงของอินพุต เวลาที่โค้ดตอบสนองทำงาน ไปจนถึงตอนที่เบราว์เซอร์วาดเฟรมถัดไป เว็บที่เคยผ่าน FID จึงอาจไม่ผ่าน INP ถ้าปุ่มหรือเมนูที่ผู้ใช้กดระหว่างอ่านตอบสนองช้า

วิธีแก้ INP สูงตามคู่มือ Optimize INP ของ web.dev คือลดเวลาทั้ง 3 ช่วงของการโต้ตอบ ได้แก่ Input delay, Processing duration และ Presentation delay โดยเริ่มจากหาการโต้ตอบที่ช้าในข้อมูลผู้ใช้จริงก่อน แล้วค่อยทดลองซ้ำบนเครื่องตัวเอง

• ลดงาน JavaScript ที่ทำงานนาน (Long Task) โดยเฉพาะสคริปต์ที่โหลดมาพร้อมหน้า เช่น ปลั๊กอินแชต ป๊อปอัป และสคริปต์ติดตาม ซึ่งทำให้เบราว์เซอร์ไม่ว่างรับการกด
• แบ่งงานยาวเป็นชิ้นเล็กและคืนเธรดหลักให้เบราว์เซอร์ อัปเดตหน้าจอให้ผู้ใช้เห็นผลก่อน แล้วค่อยทำงานที่ไม่เร่งด่วนตามหลัง
• ลดขนาด DOM หน้าที่มีองค์ประกอบมากเกินไปทำให้เบราว์เซอร์ใช้เวลาวาดหน้าจอใหม่นานขึ้นหลังทุกการกด

ข้อควรรู้คือเครื่องมือทดสอบที่โหลดหน้าโดยไม่มีการกดใด ๆ อย่าง Lighthouse วัด INP ไม่ได้ web.dev แนะนำให้ใช้ Total Blocking Time (TBT) เป็นค่าตัวแทนในการทดสอบ แต่ค่า INP ที่ใช้ตัดสินจริงต้องดูจากข้อมูลผู้ใช้จริงเท่านั้น

CLS คืออะไร และวิธีแก้หน้าเว็บขยับเอง

CLS (Cumulative Layout Shift) คือคะแนนที่วัดว่าเนื้อหาบนหน้าเว็บขยับตำแหน่งเองมากแค่ไหนโดยที่ผู้ใช้ไม่ได้สั่ง เช่น กำลังจะกดปุ่มแล้วแบนเนอร์โผล่ขึ้นมาดันปุ่มลงจนกดผิด ค่าที่ดีคือไม่เกิน 0.1 คู่มือ Optimize CLS ของ web.dev ระบุสาเหตุที่พบบ่อยที่สุด 4 อย่าง คือรูปที่ไม่กำหนดขนาด, โฆษณา embed และ iframe ที่ไม่กำหนดขนาด, เนื้อหาที่แทรกเข้ามาภายหลัง และเว็บฟอนต์ ส่วนการขยับที่เกิดภายใน 500 มิลลิวินาทีหลังผู้ใช้กดเองจะไม่ถูกนับ

• ใส่ width และ height ให้ทุกรูปและวิดีโอ หรือกำหนด aspect-ratio ใน CSS เพื่อให้เบราว์เซอร์จองพื้นที่ไว้ก่อนรูปโหลดเสร็จ
• จองพื้นที่ให้โฆษณา แบนเนอร์ และ embed ด้วย min-height ให้เท่ากับขนาดที่จะแสดงจริง
• ไม่แทรกเนื้อหาเหนือสิ่งที่ผู้ใช้กำลังอ่าน ถ้าต้องเพิ่มเนื้อหาให้ใช้ปุ่ม “โหลดเพิ่ม” หรือวางไว้ด้านล่าง
• ทำแอนิเมชันด้วย transform แทนการเปลี่ยน top หรือ left ที่ทำให้องค์ประกอบอื่นขยับตาม
• จัดการเว็บฟอนต์ ด้วย font-display: optional หรือ preload ฟอนต์หลัก เพื่อไม่ให้ข้อความกระโดดตอนฟอนต์โหลดเสร็จ

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

วิธีตรวจ Core Web Vitals ด้วย PageSpeed Insights และ Search Console

วิธีตรวจ Core Web Vitals ที่ใช้ได้ฟรีมี 2 เครื่องมือหลัก คือ PageSpeed Insights สำหรับตรวจทีละ URL และรายงาน Core Web Vitals ใน Search Console สำหรับดูทั้งเว็บ ทั้งสองเครื่องมือใช้ข้อมูลผู้ใช้จริงจาก Chrome User Experience Report (CrUX) เป็นตัวตัดสินว่าผ่านหรือไม่

สิ่งที่ต้องแยกให้ออกคือข้อมูลภาคสนามกับข้อมูลทดสอบ หน้าอธิบาย PageSpeed Insights ของ Google ระบุว่าข้อมูลผู้ใช้จริงมาจาก CrUX ช่วง 28 วันก่อนหน้า ส่วนข้อมูลทดสอบสร้างจาก Lighthouse ที่จำลองการโหลดบนอุปกรณ์เดียวและเครือข่ายแบบเดียว Google ระบุเองว่าข้อมูลทดสอบที่ดีไม่ได้แปลว่าประสบการณ์ของผู้ใช้จริงจะดีด้วยเสมอ คะแนน 0 ถึง 100 ที่เห็นด้านบนของรายงานจึงใช้หาสาเหตุ ส่วนการตัดสินว่าผ่านหรือไม่ต้องดูส่วน “ดูว่าผู้ใช้จริงได้รับประสบการณ์อย่างไร”

รายงาน Core Web Vitals ใน Search Console จัด URL ที่คล้ายกันไว้เป็นกลุ่ม แล้วให้สถานะ เร็ว, ต้องปรับปรุง หรือ ช้า แยกมือถือกับเดสก์ท็อป สถานะของแต่ละกลุ่มยึดตามค่าที่แย่ที่สุดในกลุ่มนั้น และคิดจากเปอร์เซ็นไทล์ที่ 75 ของช่วง 28 วันที่ผ่านมา หลังแก้ปัญหาแล้วให้กด “เริ่มติดตาม” เพื่อเริ่มการตรวจสอบ 28 วัน ส่วนเว็บใหม่หรือเว็บที่ผู้เข้าชมน้อยอาจเห็นคำว่าไม่มีข้อมูล เพราะ CrUX ยังเก็บข้อมูลผู้ใช้จริงได้ไม่พอ

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

ถ้าต้นเหตุคือ TTFB สูงบนเว็บที่ใช้ WordPress ทางแก้ที่ได้ผลมากที่สุดมักอยู่ที่ฝั่งเซิร์ฟเวอร์และระบบแคช เว็บ Rankfinder เองเคยลด TTFB จากราว 0.8 วินาทีเหลือราว 0.07 วินาทีเมื่อเดือนกันยายน 2026 ขั้นตอนทั้งหมดอยู่ในบทความวิธีทำเว็บ WordPress เร็วขึ้น จากเคสจริง

สำหรับธุรกิจที่อยากให้ทีมตรวจ Core Web Vitals ร่วมกับปัญหา Technical SEO อื่นทั้งเว็บ แล้วได้แผนแก้ที่เรียงตามผลกระทบต่ออันดับและยอดติดต่อ สามารถขอใบเสนอราคา SEOกับ Rankfinder ได้

ประเด็นสำคัญของ Core Web Vitals

• Core Web Vitals คือ 3 ค่าที่วัดประสบการณ์ผู้ใช้จริง ได้แก่ LCP ไม่เกิน 2.5 วินาที, INP ไม่เกิน 200 มิลลิวินาที และ CLS ไม่เกิน 0.1 โดยต้องผ่านทั้ง 3 ค่าที่เปอร์เซ็นไทล์ที่ 75
• Core Web Vitals สอดคล้องกับสิ่งที่ระบบจัดอันดับของ Google ให้คุณค่า แต่ไม่ใช่สัญญาณเดียว และ Google ยังแสดงเนื้อหาที่เกี่ยวข้องที่สุดก่อนเสมอ
• LCP ช้าแก้ได้โดยหาว่าช่วงไหนใน 4 ช่วงยาวเกิน แล้วลด TTFB ให้รูปหลักโหลดก่อน ลดขนาดรูป และลดไฟล์ที่บล็อกการแสดงผล
• INP แทน FID ตั้งแต่ 12 มีนาคม 2024 และแก้ได้ด้วยการลด JavaScript ที่ทำงานนาน แบ่งงานยาว และลดขนาด DOM
• CLS แก้ได้ด้วยการกำหนดขนาดรูป จองพื้นที่ให้โฆษณาและ embed ไม่แทรกเนื้อหาเหนือจุดที่ผู้ใช้อ่าน และจัดการเว็บฟอนต์
• ใช้ Search Console ดูภาพรวมทั้งเว็บ ใช้ PageSpeed Insights ตรวจทีละ URL และตัดสินผลจากข้อมูลผู้ใช้จริง 28 วัน ไม่ใช่คะแนน Lighthouse

อ่านต่อในหัวข้อเดียวกัน

• วิธีใช้ Google Search Console ฉบับมือใหม่
• หน้าเว็บไม่ถูก Index แก้อย่างไร (“Crawled – currently not indexed”)
• Schema Markup คืออะไร? คู่มือใส่ Structured Data ให้เว็บไทย 2026
• ย้ายเว็บ/เปลี่ยนโดเมนอย่างไรไม่ให้อันดับหาย (SEO Migration)
• SEO Audit คืออะไร? ตรวจเว็บอะไรบ้าง พร้อม Checklist

คำถามที่พบบ่อยเกี่ยวกับ Core Web Vitals

Core Web Vitals ไม่ผ่านแล้วอันดับจะตกไหม

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

คะแนน PageSpeed Insights ต้องได้ 90 ขึ้นไปไหม

คะแนน PageSpeed Insights ไม่จำเป็นต้องได้ 90 ขึ้นไปจึงจะผ่าน Core Web Vitals เพราะคะแนน 0 ถึง 100 มาจากการทดสอบด้วย Lighthouse ส่วนเกณฑ์ผ่านจริงคือค่า LCP, INP และ CLS จากผู้ใช้จริงที่เปอร์เซ็นไทล์ที่ 75 หน้าเว็บที่ได้คะแนนทดสอบ 70 กว่าจึงอาจผ่าน Core Web Vitals ได้ ถ้าผู้ใช้จริงโหลดหน้าได้เร็ว

ทำไมรายงาน Core Web Vitals ใน Search Console ขึ้นว่าไม่มีข้อมูล

รายงานขึ้นว่าไม่มีข้อมูลเพราะ CrUX ยังมีข้อมูลการเข้าชมจริงของหน้าเหล่านั้นไม่พอ ซึ่งพบบ่อยกับเว็บใหม่หรือเว็บที่มีผู้เข้าชมน้อย Google ระบุว่าพร็อพเพอร์ตีที่เพิ่งสร้างอาจต้องรอ 2 ถึง 3 วัน และถ้ากลุ่ม URL มีข้อมูลไม่พอ ระบบจะใช้ข้อมูลรวมระดับต้นทาง (Origin) ของเว็บแทน

ควรแก้ Core Web Vitals บนมือถือหรือเดสก์ท็อปก่อน

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