Core Web Vitals คืออะไร แก้ LCP, INP และ CLS ยังไง (อัปเดต 2026 · INP แทน FID)

Core Web Vitals คืออะไร มีกี่ตัว

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

• LCP (Largest Contentful Paint): เวลาที่เนื้อหาชิ้นใหญ่ที่สุดในจอแรก เช่น รูป hero หรือย่อหน้าหัวเรื่อง แสดงเสร็จ
• INP (Interaction to Next Paint): เวลาตั้งแต่คนคลิก แตะ หรือกดปุ่มคีย์บอร์ด จนหน้าจอแสดงผลตอบกลับ
• CLS (Cumulative Layout Shift): คะแนนว่าองค์ประกอบบนหน้าขยับเองโดยที่คนอ่านไม่ได้สั่งมากแค่ไหน

web.dev (เว็บความรู้ของทีม Chrome อัปเดต 31 ต.ค. 2024) กำหนดให้วัดที่ percentile 75 ของการเข้าหน้า แยกมือถือกับเดสก์ท็อป แปลว่าคนเข้าหน้าอย่างน้อย 3 ใน 4 ครั้งต้องได้ประสบการณ์ในเกณฑ์ดี หน้าจึงจะนับว่าผ่าน และต้องผ่านครบทั้ง 3 ตัว ไม่ใช่เฉลี่ยรวมกัน การใช้ p75 แทนค่าเฉลี่ยบังคับให้หน้าดีสำหรับคนส่วนใหญ่ รวมคนที่เครื่องหรือเน็ตช้ากว่า ไม่ใช่แค่ค่ากลางที่ดูดี

เกณฑ์ Core Web Vitals: ดี ต้องปรับ และแย่

เกณฑ์ Core Web Vitals แบ่งแต่ละตัวเป็น 3 ระดับ คือ ดี ต้องปรับปรุง และแย่ ใช้ตัวเลขชุดเดียวกันทั้งใน web.dev, เอกสาร Google Search และรายงานใน Search Console ตารางนี้คือค่าที่ p75 ของผู้ใช้จริง

ตัวชี้วัด	วัดอะไร	ดี	ต้องปรับปรุง	แย่
LCP	เนื้อหาหลักโหลดเสร็จ	ไม่เกิน 2.5 วินาที	เกิน 2.5 ถึง 4 วินาที	เกิน 4 วินาที
INP	ตอบสนองต่อการคลิก แตะ กดคีย์	ไม่เกิน 200 มิลลิวินาที	เกิน 200 ถึง 500 มิลลิวินาที	เกิน 500 มิลลิวินาที
CLS	หน้าขยับเองโดยไม่ตั้งใจ	ไม่เกิน 0.1	เกิน 0.1 ถึง 0.25	เกิน 0.25

FID หายไปไหน และ FCP กับ TTFB ใช่ Core Web Vitals ไหม

FID (First Input Delay) ไม่ได้เป็น Core Web Vitals แล้ว เพราะ Google ใช้ INP แทนตั้งแต่ 12 มี.ค. 2024 ทั้งใน PageSpeed Insights, Chrome UX Report และ Search Console (ที่มา: web.dev ประกาศ 12 มี.ค. 2024 และ Google Search Central blog อัปเดตวันเดียวกัน) เหตุผลคือ FID วัดแค่ความหน่วงก่อนเริ่มประมวลผลการกดครั้งแรก ส่วน INP วัดทุกการกดตลอดการเข้าหน้า และนับจนหน้าจอแสดงผลจริง บทความไทยหลายหน้าที่ยังติดอันดับคำ “lcp คือ” และ “inp คือ” ยังสอน FID เป็นเกณฑ์หลักอยู่ (เราสังเกต 15 ต.ค. 2026)

FCP (First Contentful Paint) และ TTFB (Time to First Byte เวลาที่เซิร์ฟเวอร์เริ่มส่งข้อมูลกลับ) ก็ไม่ใช่ Core Web Vitals web.dev จัดสองตัวนี้เป็นตัวชี้วัดช่วยวินิจฉัย ใช้หาสาเหตุว่าทำไม LCP ช้า Core Web Vitals มี 3 ตัวเท่านั้น ถ้าเจอบทความที่บอกว่ามี 5 ตัว ให้รู้ว่ากำลังรวมตัวช่วยเข้าไปด้วย

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

Core Web Vitals มีผลกับอันดับ Google จริง แต่เป็นแค่สัญญาณหนึ่งในหลายตัว และไม่ชนะเรื่องความเกี่ยวข้องของเนื้อหา เรื่องนี้สำคัญกับทุกคนที่กำลังตัดสินใจว่าจะลงแรงกับความเร็วเว็บแค่ไหน เอกสาร Understanding page experience ของ Google (last updated 2026-09-22) เขียนว่า “Core Web Vitals are used by our ranking systems.” และเขียนต่อว่าคะแนนดีในรายงานหรือเครื่องมือ “doesn’t guarantee” ว่าหน้าจะติดอันดับบนสุด

ภาพรวมเรื่อง page experience และ HTTPS เราอธิบายไว้แล้วใน HTTPS และ page experience ช่วยอันดับแค่ไหน ส่วนที่เพิ่มเฉพาะเรื่อง Core Web Vitals มีสามข้อ

1. ประเมินรายหน้าเป็นหลัก: เอกสารเดียวกันบอกว่าระบบจัดอันดับหลักประเมินเนื้อหาระดับหน้า แต่ก็ระบุว่า “we do have some site-wide assessments” ดังนั้นหน้าที่ช้าจำนวนมากอาจกระทบภาพรวมได้ แต่ Google ไม่ได้บอกว่ากระทบแค่ไหน
2. Google ไม่มี “คะแนน SEO” จาก Core Web Vitals: Search Console รายงานเป็นสถานะ ดี ต้องปรับปรุง หรือแย่ ส่วนคะแนน 0–100 ใน PageSpeed Insights เป็นคะแนนแล็บของ Lighthouse ไม่ใช่คะแนนที่ Google ใช้จัดอันดับ
3. ประโยชน์ที่ชัดกว่าคืออยู่ฝั่งคนอ่าน: หน้าที่โหลดช้าหรือปุ่มกดไม่ตอบ ทำให้คนออกก่อนเห็นเนื้อหาหรือก่อนกรอกฟอร์ม ข้อนี้กระทบยอดขายแม้อันดับจะไม่เปลี่ยน

The Art of SEO บทที่ 7 วางเรื่องประสบการณ์ใช้งานและความเร็วเป็นส่วนหนึ่งของการทำเว็บให้เป็นมิตรกับ search engine คู่กับเนื้อหาและโครงสร้าง ไม่ได้แยกเป็นทางลัด แต่เล่มนี้ (พิมพ์ปี 2023) ยังใช้ FID เป็นตัวชี้วัดหลัก ส่วนนิยามตัวชี้วัดในบทความนี้จึงใช้เอกสารปัจจุบันของ Google และ web.dev แทน

LCP คืออะไร (ในเรื่องเว็บไซต์) และแก้ LCP ยังไง

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

องค์ประกอบที่นับเป็น LCP ได้คือ รูป (img) รูปใน SVG ภาพปกของวิดีโอ รูปพื้นหลังที่โหลดผ่าน CSS และกล่องข้อความ บนเว็บธุรกิจจำนวนมาก LCP มักเป็นรูป hero หรือแบนเนอร์สไลด์ด้านบน ส่วนหน้าบทความมักเป็นรูปปกหรือย่อหน้าแรก

คู่มือ Optimize LCP ของ web.dev แบ่งเวลา LCP เป็น 4 ช่วง ใช้หาว่าช้าที่ตรงไหน

1. TTFB: เวลาที่เซิร์ฟเวอร์เริ่มส่ง HTML กลับ ช้าเพราะโฮสต์ ไม่มี cache หรือ redirect หลายทอด
2. Resource load delay: เบราว์เซอร์เจอรูป LCP ช้า เช่น รูปถูกใส่ด้วย JavaScript หรือติด lazy-load
3. Resource load duration: เวลาดาวน์โหลดรูป ช้าเพราะไฟล์ใหญ่หรือขนาดเกินจอ
4. Element render delay: โหลดรูปเสร็จแล้วแต่ยังแสดงไม่ได้ เพราะรอ CSS หรือ JavaScript ที่บล็อกการแสดงผล (render-blocking)

สาเหตุ LCP ช้า	วิธีแก้
รูป hero ติด lazy-load	เอา lazy-load ออกจากรูปในจอแรก ใส่ fetchpriority="high" ให้รูป LCP และใช้ lazy-load กับรูปที่อยู่ล่างจอเท่านั้น
รูปใหญ่เกินจอ หรือไฟล์หนัก	ย่อให้พอดีความกว้างที่แสดงจริง ใช้ srcset ให้มือถือได้ไฟล์เล็ก บีบอัดเป็น WebP หรือ AVIF (ใส่ alt ให้ถูกด้วย ดู Alt text คืออะไร)
รูปถูกใส่ด้วย JavaScript หรือเป็นสไลด์	ใส่รูปแรกเป็น <img> ใน HTML ตรงๆ หรือ preload รูปพื้นหลังจาก CSS เลี่ยงสไลด์หลายรูปในจอแรก
เซิร์ฟเวอร์ตอบช้า (TTFB สูง)	เปิด page cache ให้หน้าสาธารณะ ใช้ CDN (เครือข่ายเซิร์ฟเวอร์ที่เก็บสำเนาเว็บไว้หลายพื้นที่) ถ้าคนอ่านกระจายหลายพื้นที่ ลด redirect และคุยกับโฮสต์ถ้ายังช้า
CSS และ JavaScript บล็อกการแสดงผล	ตัดไฟล์ที่ไม่ใช้ในหน้านั้น ให้ JavaScript ที่ไม่จำเป็นโหลดแบบ defer และลดจำนวนฟอนต์

ฝั่งเซิร์ฟเวอร์ ข้อมูลหน้าแรกเว็บไทย 56 เว็บที่เราเก็บไว้ใน SEO Audit คืออะไร พบว่า TTFB ของหน้าแรกเกิน 1 วินาที 20 เว็บ (35.7%) ตัวเลขนี้วัดจากเครือข่ายเดียวในกรุงเทพฯ ครั้งเดียว จึงใช้บอกได้แค่ว่าเรื่องเซิร์ฟเวอร์ช้าไม่ได้หายากในเว็บที่ติดหน้า 1 ไม่ใช่ค่า LCP ของเว็บเหล่านั้น

INP คืออะไร (ในเรื่องเว็บไซต์) และแก้ INP ยังไง

INP ในเรื่องเว็บไซต์ย่อมาจาก Interaction to Next Paint คือเวลาตั้งแต่คนคลิก แตะ หรือกดปุ่มคีย์บอร์ดบนหน้า จนหน้าจอแสดงผลตอบกลับครั้งถัดไป (ไม่เกี่ยวกับ INP ที่เป็นชื่อหลักสูตรโรงเรียน หรือบุคลิก MBTI ที่สะกดคล้ายกัน) ตัวนี้สำคัญกับหน้าที่มีเมนู ฟอร์ม ตัวกรองสินค้า หรือปุ่มแชต เกณฑ์ดีคือไม่เกิน 200 มิลลิวินาที เกิน 500 มิลลิวินาทีถือว่าแย่ (web.dev, INP อัปเดต 2 ก.ย. 2025)

INP นับเฉพาะการคลิกเมาส์ การแตะหน้าจอ และการกดคีย์บอร์ด ไม่นับการเลื่อนหน้า (scroll) การเอาเมาส์ชี้ (hover) และการซูม ค่า INP ของการเข้าหน้าหนึ่งครั้งคือ interaction ที่ช้าที่สุด โดยตัดค่าที่สูงผิดปกติออก 1 ครั้งต่อทุก 50 interaction (หน้าที่มีการกดน้อยจึงใช้ค่าที่ช้าที่สุดเลย) ข้อนี้มีคนเข้าใจผิดบ่อย คำตอบจาก OpenAI ผ่าน API ที่เราทดสอบ 1 ครั้ง (15 ต.ค. 2026) ยังบอกว่า INP รวมการเลื่อนหน้าด้วย

web.dev แบ่งเวลาของแต่ละ interaction เป็น 3 ช่วง และแต่ละช่วงแก้ต่างกัน

1. Input delay: คนกดแล้ว แต่เบราว์เซอร์ยังไม่ว่างเพราะกำลังรัน JavaScript อื่นอยู่ (มักเป็นสคริปต์ภายนอก เช่น แชต pixel หรือโฆษณา)
2. Processing duration: เวลารันโค้ดที่ตอบการกดนั้นเอง เช่น ตัวกรองสินค้าที่คำนวณทั้งหน้า
3. Presentation delay: เวลาวาดหน้าจอใหม่ ช้าเมื่อหน้ามีองค์ประกอบ (DOM) จำนวนมาก หรือเปลี่ยนหน้าตาเยอะในครั้งเดียว

วิธีแก้ INP ส่วนใหญ่คือทำให้ main thread (เส้นทางหลักที่เบราว์เซอร์ใช้รัน JavaScript และวาดหน้า) ว่างเร็วขึ้น

• ลด long task: งาน JavaScript ที่ยาวเกิน 50 มิลลิวินาทีจะกันไม่ให้หน้าตอบการกด ให้นักพัฒนาแบ่งงานใหญ่เป็นชิ้นเล็ก และให้ส่วนที่ไม่เร่งด่วนรันทีหลัง
• เลื่อนสคริปต์ภายนอก: แชต pixel โฆษณา และ heatmap ให้โหลดหลังหน้าแสดงเสร็จ หรือโหลดเมื่อคนเริ่มใช้งาน ไม่ใช่ตอนเปิดหน้า
• ตัดปลั๊กอินและสคริปต์ที่ไม่ใช้: หลายตัวโหลด JavaScript ทุกหน้าแม้ใช้แค่หน้าเดียว
• ลดขนาดหน้า: page builder ที่ซ้อนกล่องหลายชั้นทำให้ DOM ใหญ่ และทำให้ช่วง presentation delay ยาว
• ตอบสนองทันทีก่อน: เมื่อกดปุ่ม ให้แสดงสถานะ เช่น ปุ่มหมุนหรือเปลี่ยนสี ก่อนทำงานหนัก คนอ่านจะเห็นว่าหน้ารับคำสั่งแล้ว

การเปลี่ยนเป็น HTTP/2 หรือ HTTP/3 ช่วยความเร็วฝั่งเครือข่าย แต่ไม่ได้แก้ต้นเหตุหลักของ INP ซึ่ง web.dev ระบุว่าการตอบสนองช้ามักมาจากงาน JavaScript บน main thread และความแรงของเครื่องคนอ่าน มากกว่าเครือข่าย

CLS คืออะไร (ในเรื่องเว็บไซต์) และแก้ CLS ยังไง

CLS ในเรื่องเว็บไซต์ย่อมาจาก Cumulative Layout Shift คือคะแนนที่บอกว่าองค์ประกอบบนหน้าขยับเองโดยคนอ่านไม่ได้สั่งมากแค่ไหน เช่น กำลังจะกดลิงก์แล้วแบนเนอร์โผล่มาดันลง CLS เป็นค่าไม่มีหน่วย ไม่ใช่วินาที เกณฑ์ดีคือไม่เกิน 0.1 และเกิน 0.25 ถือว่าแย่ (web.dev, CLS)

CLS ไม่ได้รวมการขยับทั้งหมดตลอดเวลาที่เปิดหน้า web.dev จับการขยับที่เกิดใกล้กัน (ห่างกันไม่ถึง 1 วินาที รวมไม่เกิน 5 วินาที) เป็นหนึ่งกลุ่ม แล้วใช้กลุ่มที่ขยับมากที่สุดเป็นค่า CLS และไม่นับการขยับที่เกิดภายใน 500 มิลลิวินาทีหลังคนคลิกหรือกด เพราะเป็นการเปลี่ยนที่คนอ่านคาดไว้ เช่น กดเปิดเมนูแล้วเมนูกางลง

สาเหตุ CLS	อาการที่เห็น	วิธีแก้
รูปหรือวิดีโอไม่มีขนาดกำกับ	ข้อความกระโดดลงเมื่อรูปโหลดเสร็จ	ใส่ width และ height ให้ทุกรูปและวิดีโอ หรือกำหนด aspect-ratio ใน CSS
โฆษณา embed และ iframe	กล่องโฆษณาโผล่แล้วดันเนื้อหา	จองพื้นที่ความสูงไว้ล่วงหน้า ถ้าไม่มีโฆษณาก็ให้กล่องว่างคงขนาดเดิม
เนื้อหาที่แทรกทีหลัง	แบนเนอร์คุกกี้ แถบโปรโมชัน หรือแถบแจ้งเตือนดันหน้าลง	แสดงแบบลอยทับ (overlay) ที่ขอบล่าง หรือจองพื้นที่ไว้ตั้งแต่แรก ไม่แทรกเหนือเนื้อหา
ฟอนต์เว็บโหลดทีหลัง	ข้อความเปลี่ยนขนาดหรือขึ้นบรรทัดใหม่เมื่อฟอนต์มา	preload ฟอนต์หลัก ใช้ font-display และตั้งฟอนต์สำรองให้ขนาดใกล้ฟอนต์จริง (size-adjust)
แอนิเมชันที่เปลี่ยนตำแหน่ง	องค์ประกอบเลื่อนแล้วดันเพื่อนบ้าน	ใช้ transform แทนการเปลี่ยน top, left, width หรือ height

เช็คความเร็วเว็บและ Core Web Vitals ฟรีด้วย 3 เครื่องมือ

เครื่องมือเช็คความเร็วเว็บที่ตอบเรื่อง Core Web Vitals ได้ตรงที่สุดมีสามตัว และใช้ฟรีทั้งหมด ใช้คู่กันเสมอ เพราะแต่ละตัวตอบคนละคำถาม ตัวที่บอกว่าเว็บ “ผ่าน” หรือไม่ในสายตา Google คือข้อมูลผู้ใช้จริงใน Search Console และในส่วนบนของ PageSpeed Insights ไม่ใช่คะแนนตัวเลขใหญ่

เครื่องมือ (ฟรี)	ข้อมูลแบบไหน	ตอบคำถามอะไร	ข้อจำกัด
PageSpeed Insights	ผู้ใช้จริง (ถ้ามี) + ผลแล็บ	URL นี้ผ่าน Core Web Vitals ไหม และอะไรทำให้ช้า	เว็บคนเข้าน้อยจะไม่มีข้อมูลผู้ใช้จริง เหลือแค่ผลแล็บ
Search Console รายงาน Core Web Vitals	ผู้ใช้จริง	กลุ่มหน้าไหนของทั้งเว็บที่ไม่ผ่าน และแก้แล้วผ่านหรือยัง	เว็บเล็กมักขึ้นว่าไม่มีข้อมูล
Chrome DevTools (แท็บ Performance และ Lighthouse)	วัดบนเครื่องเรา	เกิดอะไรตอนกดปุ่มนี้ องค์ประกอบไหนเป็น LCP อะไรขยับ	เครื่องเราเร็วกว่าผู้ใช้ส่วนใหญ่ ต้องจำลองมือถือและเน็ตช้า

ถ้ากำลังตรวจเว็บทั้งเว็บ ให้วาง Core Web Vitals เป็นหนึ่งขั้นในลำดับตรวจตามผลกระทบ ไม่ใช่ขั้นแรก The Art of SEO บทที่ 10 วางการตรวจเว็บเป็นขั้นตอน (crawl → Search Console → analytics …) ซึ่ง Core Web Vitals อยู่ในขั้นที่ดูรายงานของ Search Console ลำดับเต็มอยู่ใน SEO Audit คืออะไร ตรวจเว็บเองทีละขั้น และรายชื่อเครื่องมืออื่นอยู่ใน SEO Tools ฟรีและเสียเงิน

ทำไมคะแนน PageSpeed 90+ แต่ Core Web Vitals ยังไม่ผ่าน

คะแนน 0–100 ใน PageSpeed Insights คือผลแล็บ (lab data) จาก Lighthouse ที่โหลดหน้าครั้งเดียวบนมือถือจำลองระดับกลาง ส่วนการตัดสินว่าผ่าน Core Web Vitals มาจากข้อมูลผู้ใช้จริง (field data) ใน Chrome UX Report ย้อนหลัง 28 วันที่ p75 เอกสาร About PageSpeed Insights (อัปเดต 21 ต.ค. 2024) เขียนชัดว่าผลแล็บที่ดีไม่ได้รับประกันว่าผู้ใช้จริงจะได้ประสบการณ์ที่ดี สองตัวเลขนี้จึงขัดกันได้ด้วยเหตุผลห้าข้อ

1. เครื่องและเน็ตต่างกัน: แล็บจำลองเครื่องเดียว ผู้ใช้จริงมีทั้งมือถือรุ่นประหยัดและเน็ตที่ช้ากว่า
2. แล็บวัด INP ไม่ได้: ไม่มีคนกดจริง ผลแล็บจึงดูได้แค่ Total Blocking Time (TBT เวลารวมที่หน้าถูกงาน JavaScript ยาวๆ บล็อกระหว่างโหลด) ซึ่ง web.dev บอกว่าใช้เป็นตัวแทนคร่าวๆ ได้ แต่ใช้แทน INP ไม่ได้ หน้าที่ TBT ดีอาจมี INP แย่เมื่อคนกดเมนูหรือฟอร์มจริง
3. แล็บเห็นแค่ช่วงโหลด: แบนเนอร์หรือโฆษณาที่โผล่ตอนคนเลื่อนลงทำให้ CLS ของผู้ใช้จริงสูงกว่าแล็บ
4. ช่วงเวลาต่างกัน: ข้อมูลผู้ใช้จริงคือ 28 วันย้อนหลัง แก้วันนี้ คะแนนแล็บเปลี่ยนทันที แต่ข้อมูลผู้ใช้จริงค่อยๆ เปลี่ยน
5. ระดับ URL กับระดับโดเมน: ถ้า URL นั้นคนเข้าน้อย PageSpeed Insights จะแสดงข้อมูลของทั้ง origin (โดเมน) แทน ซึ่งรวมหน้าที่ช้ากว่าด้วย

ช่วงคะแนนแล็บคือ 0–49 แย่ 50–89 ต้องปรับปรุง และ 90–100 ดี ใช้คะแนนนี้หาสาเหตุและเทียบก่อนกับหลังแก้ได้ แต่ห้ามใช้แทนการผ่าน Core Web Vitals

อ่านรายงาน Core Web Vitals ใน Search Console

รายงาน Core Web Vitals ใน Search Console คือมุมมองทั้งเว็บจากข้อมูลผู้ใช้จริงใน Chrome UX Report แยกมือถือกับเดสก์ท็อป เหมาะกับการหาว่ากลุ่มหน้าไหนต้องแก้ และใช้ยืนยันว่าแก้แล้วได้ผล วิธีอ่านตาม Search Console Help (ตรวจ 15 ต.ค. 2026) มีหกข้อ

• รายงานเป็นกลุ่ม URL: หน้าที่ประสบการณ์คล้ายกันถูกรวมเป็นกลุ่ม และสถานะ LCP, INP, CLS ใช้กับทั้งกลุ่ม
• สถานะของกลุ่มคือค่าที่แย่ที่สุด: ถ้า LCP และ INP ดีแต่ CLS แย่ กลุ่มนั้นขึ้นว่าแย่
• ต้องมีข้อมูลพอ: กลุ่มต้องมีข้อมูล LCP และ CLS พอจึงจะขึ้นในรายงาน ถ้ากลุ่มเล็กเกินไป Search Console ใช้ข้อมูลระดับ origin แทน และถ้า origin ก็ไม่พอ จะไม่แสดงอะไร เว็บใหม่หรือเว็บคนเข้าน้อยจึงเห็นหน้าว่าไม่มีข้อมูล ซึ่งไม่ได้แปลว่าเว็บมีปัญหา
• ข้อมูลย้อนหลัง 28 วัน: ตัวเลขของกลุ่มคือ 28 วันล่าสุด
• Validate fix ใช้ 28 วัน: กดเริ่มตรวจแล้ว Search Console เฝ้าดู 28 วัน ถ้าไม่เจอปัญหาในช่วงนั้นจึงนับว่าแก้แล้ว และการกดนี้ไม่ได้สั่งให้ Google crawl ใหม่
• ข้อมูลรวมทุกประเทศ: ถ้าคนเข้าจำนวนมากมาจากพื้นที่ที่เน็ตช้า ตัวเลขรวมจะแย่ลง

รายงานนี้อยู่ในกลุ่มรายงานด้านประสบการณ์ ดูวิธีเปิดและรายงานอื่นที่เกี่ยวข้องได้ใน รายงานอื่นใน Search Console ที่ควรรู้

ต้นเหตุที่เจอบ่อยในเว็บไทย: แบนเนอร์คุกกี้ PDPA แชต LINE และ Facebook และฟอนต์ไทย

เว็บธุรกิจไทยจำนวนมากมีของสามอย่างที่กระทบ Core Web Vitals ได้ตรงๆ คือแบนเนอร์ขอความยินยอมคุกกี้ตาม PDPA ปุ่มแชต LINE หรือ Facebook และฟอนต์ภาษาไทย เจ้าของเว็บควรเช็กสามจุดนี้ก่อนเปลี่ยนโฮสต์หรือเปลี่ยนธีม เพราะมักแก้ได้ในการตั้งค่า หน้าไทย 5 หน้าที่ติดอันดับหรือถูก AI Overview อ้างในคำเหล่านี้ที่เราอ่าน (15 ต.ค. 2026) ไม่มีหน้าไหนพูดถึงสามเรื่องนี้

1. แบนเนอร์คุกกี้ PDPA: ถ้าแบนเนอร์แทรกด้านบนแล้วดันหน้าลง จะเพิ่ม CLS และถ้าตัวจัดการ consent โหลดสคริปต์หนักตอนเปิดหน้า จะเพิ่ม input delay ของ INP วิธีแก้คือให้แบนเนอร์ลอยทับที่ขอบล่าง ไม่ดันเนื้อหา และเลือกตัวจัดการที่โหลดเบา ในบางกรณีแบนเนอร์ที่เป็นข้อความยาวอาจกลายเป็นองค์ประกอบ LCP ของหน้าเองด้วย ให้เช็กใน PageSpeed Insights ว่า LCP ชี้ไปที่อะไร
2. แชต LINE, Facebook และ pixel: web.dev ระบุว่าวิดเจ็ตแชตส่วนใหญ่โหลด JavaScript จำนวนมากที่กระทบทั้งการโหลดและการตอบสนอง และสคริปต์ติดตามโฆษณาก็มักโหลดตั้งแต่เปิดหน้า แย่ง main thread ในช่วงที่คนเริ่มกด วิธีแก้คือให้ปุ่มแชตเป็นปุ่มธรรมดาที่โหลดวิดเจ็ตจริงเมื่อคนกด หรือโหลดหลังหน้าแสดงเสร็จ และเอา pixel ที่ไม่ได้ใช้แล้วออก
3. ฟอนต์ไทย: ความเสี่ยงจริงไม่ใช่ขนาดตัวอักษรไทย แต่คือการโหลดหลายน้ำหนัก (weight) หลายครอบครัว หรือ host ไฟล์ฟอนต์เต็มเอง และฟอนต์สำรองที่ขนาดต่างจากฟอนต์จริงจนข้อความขยับเมื่อฟอนต์มา (CLS)

เราทดสอบขนาดไฟล์ฟอนต์จาก Google Fonts เอง (15 ต.ค. 2026, น้ำหนัก 400, ไฟล์ woff2, ทดสอบ 1 ครั้งต่อไฟล์) ผลคือ Sarabun ชุดอักษรไทยหนัก 9,880 ไบต์ Sarabun ชุดละตินหนัก 11,440 ไบต์ ส่วน Inter ชุดละตินหนัก 23,804 ไบต์ Google Fonts แบ่งฟอนต์เป็นชุดตามภาษา (subset) และเบราว์เซอร์โหลดเฉพาะชุดที่หน้าใช้จริง ความเชื่อว่า “ฟอนต์ไทยหนักกว่าฟอนต์อังกฤษ” จึงไม่จริงอย่างน้อยกับ Sarabun เมื่อโหลดแบบ subset (หน้าไทยมักโหลดทั้งชุดไทยและชุดละติน รวมราว 21 KB ซึ่งยังเล็กกว่าการโหลดหลายน้ำหนัก) นี่เป็นการทดสอบเล็ก ใช้บอกขนาดไฟล์ ไม่ได้วัดความเร็วของหน้า

เว็บ WordPress แก้ Core Web Vitals อะไรก่อน: ลำดับที่ทำเองได้

ลำดับแก้ Core Web Vitals สำหรับเว็บ WordPress คือวัดก่อน แล้วแก้รูปในจอแรกกับ cache ก่อน จากนั้นค่อยไล่สคริปต์ภายนอก ฟอนต์ และแบนเนอร์ ลำดับนี้เหมาะกับเว็บ SME ที่ใช้ธีมสำเร็จรูปหรือ page builder และไม่มีนักพัฒนาประจำ เหตุที่เริ่มจากรูปและ cache เพราะ LCP เป็นตัวที่ตกมากที่สุดบนมือถือ และสองเรื่องนี้แก้ได้จากหน้าตั้งค่าโดยไม่ต้องเขียนโค้ด

1. วัดก่อนแก้: เปิด PageSpeed Insights บนมือถือกับหน้าแรกและหน้าทำเงิน 3 หน้า จดค่าผู้ใช้จริง (ถ้ามี) ผลแล็บ และองค์ประกอบที่เป็น LCP แล้วเปิดรายงาน Core Web Vitals ใน Search Console ดูว่ากลุ่มไหนไม่ผ่าน
2. รูปในจอแรก: ปิด lazy-load ของรูป hero ย่อรูปให้พอดีจอ บีบอัดเป็น WebP หรือ AVIF และตรวจว่าทุกรูปมี width กับ height
3. Page cache: เปิด page cache จากโฮสต์หรือปลั๊กอิน cache ตัวใดตัวหนึ่ง (ใช้ตัวเดียว ไม่ซ้อนหลายตัว) แล้วดู TTFB ใหม่
4. ปลั๊กอินที่ไม่ใช้: ปิดและลบปลั๊กอินที่ไม่ได้ใช้ และดูว่าปลั๊กอินไหนโหลดสคริปต์ทุกหน้าแม้ใช้หน้าเดียว เช่น ฟอร์มหรือสไลเดอร์
5. สคริปต์ภายนอก: เลื่อนแชต pixel และ heatmap ให้โหลดหลังหน้าแสดงเสร็จหรือเมื่อคนเริ่มใช้งาน
6. ฟอนต์: ใช้ไม่เกิน 2 ครอบครัว เลือกเฉพาะน้ำหนักที่ใช้จริง โหลดแบบ subset และตั้ง font-display
7. แบนเนอร์คุกกี้และแถบโปรโมชัน: เปลี่ยนเป็นแบบลอยทับ ไม่แทรกดันเนื้อหา
8. Page builder: ลดกล่องซ้อนกล่อง เลี่ยงสไลเดอร์และวิดีโอพื้นหลังในจอแรก

แก้แต่ละข้อแล้วเช็กผลแล็บใน PageSpeed Insights ทันที ข้อมูลผู้ใช้จริงต้องรอราว 28 วันจึงสะท้อนผลครบ แล้วกด Validate fix ใน Search Console เช็กลิสต์ technical SEO ฉบับ WordPress ที่ครอบคลุมเรื่องอื่นนอกจากความเร็วอยู่ใน เช็กลิสต์ technical SEO สำหรับ WordPress ใน 30 นาที

ทำเองหรือส่งต่อนักพัฒนา: เหมาะกับใคร และข้อควรระวัง

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

• ทำเองได้: ย่อและบีบอัดรูป ปิด lazy-load รูป hero เปิด cache ลบปลั๊กอิน ลดฟอนต์ เปลี่ยนแบนเนอร์เป็นแบบลอยทับ ตั้งค่าแชตให้โหลดทีหลัง
• ควรส่งนักพัฒนา: INP แย่ที่มาจาก JavaScript ของธีมหรือปลั๊กอินเอง long task ที่ต้องแก้โค้ด TTFB สูงแม้เปิด cache แล้ว และเว็บที่สร้างด้วย JavaScript framework
• ข้อควรระวัง: ปลั๊กอินความเร็วที่รวมหรือเลื่อนไฟล์ JavaScript อัตโนมัติอาจทำให้เมนู ฟอร์ม หรือระบบชำระเงินพัง ทดสอบทุกหน้าที่มีฟอร์มหลังเปิด และอย่าเปิดหลายปลั๊กอินที่ทำงานเดียวกันพร้อมกัน
• ไม่ต้องไล่คะแนน 100: เป้าคือผ่านเกณฑ์ดีที่ p75 ทั้งสามตัว ไม่ใช่คะแนนแล็บเต็ม

เว็บทั่วโลกผ่าน Core Web Vitals กี่ % และควรแก้ตัวไหนก่อน

เว็บทั่วโลกที่ผ่าน Core Web Vitals ครบทั้งสามตัวมีไม่ถึงครึ่งบนมือถือ ข้อมูลนี้มาจาก HTTP Archive Web Almanac 2025 บท Performance (เผยแพร่ 15 ม.ค. 2026 ใช้ข้อมูล Chrome UX Report เดือน ก.ค. 2025 ระดับ origin หลายล้านเว็บ) ใช้เป็นเส้นฐานเทียบเว็บของคุณ และบอกว่าควรเริ่มแก้ตัวไหน

ตัวชี้วัด (origin ที่อยู่ในเกณฑ์ดี)	มือถือ	เดสก์ท็อป
ผ่านครบทั้ง 3 ตัว (2025)	48%	56%
ผ่านครบ 3 ตัว ปี 2024	44%	55%
ผ่านครบ 3 ตัว ปี 2023	36%	48%
LCP ดี (2025)	62%	74%
INP ดี (2025)	77%	97%
CLS ดี (2025)	81%	72%

อ่านได้สองข้อ ข้อแรก มือถือผ่านน้อยกว่าเดสก์ท็อปทุกปี จึงควรดูรายงานแท็บมือถือก่อน ข้อสอง บนมือถือ LCP ผ่านแค่ 62% ขณะที่ INP และ CLS ผ่านเกิน 3 ใน 4 สำหรับเว็บส่วนใหญ่ LCP จึงเป็นตัวที่ดึงผลรวมลง และควรอยู่ต้นลำดับการแก้ ส่วนบนเดสก์ท็อป ตัวที่ผ่านน้อยที่สุดคือ CLS (72%) ไม่ใช่ LCP (74%) ถ้าคนเข้าเว็บคุณจากคอมพิวเตอร์เป็นหลัก ให้เช็ก CLS ก่อน

ความเชื่อผิดเรื่อง Core Web Vitals 7 ข้อ (เทียบเอกสารทางการ)

ความเชื่อผิดเรื่อง Core Web Vitals ส่วนใหญ่มาจากบทความที่เขียนก่อนปี 2024 และไม่ได้อัปเดต เราเก็บ 7 ข้อนี้จากหน้าไทยที่ติดอันดับและคำตอบ AI ที่เราอ่านเมื่อ 15 ต.ค. 2026 แล้วเทียบกับเอกสารของ Google และ web.dev ตารางนี้ใช้ตรวจบทความหรือรายงานที่คุณได้รับได้ทันที

#	ความเชื่อ	ข้อเท็จจริงตามเอกสาร	แหล่ง
1	FID ยังเป็นหนึ่งใน Core Web Vitals	INP แทน FID ตั้งแต่ 12 มี.ค. 2024	web.dev 12 มี.ค. 2024 · Search Central blog
2	CLS วัดเป็นวินาที	CLS เป็นคะแนนไม่มีหน่วย เกณฑ์ดีไม่เกิน 0.1	web.dev, CLS
3	Core Web Vitals มี 5 ตัว รวม FCP และ TTFB	มี 3 ตัว คือ LCP, INP, CLS ส่วน FCP และ TTFB เป็นตัวช่วยวินิจฉัย	web.dev, Web Vitals (31 ต.ค. 2024)
4	Google ให้ “คะแนน SEO” จาก Core Web Vitals	Search Console รายงานเป็นสถานะ ดี ต้องปรับปรุง แย่ ส่วนคะแนน 0–100 เป็นผลแล็บของ Lighthouse	Search Console Help · PageSpeed Insights About (21 ต.ค. 2024)
5	INP นับการเลื่อนหน้าด้วย	INP นับคลิก แตะ และกดคีย์ ไม่นับ scroll, hover และการซูม	web.dev, INP (2 ก.ย. 2025)
6	คะแนน PageSpeed 100 แปลว่าผ่านและติดอันดับ	ผลแล็บที่ดีไม่รับประกันประสบการณ์ผู้ใช้จริง และคะแนนดีไม่การันตีอันดับบนสุด	PageSpeed Insights About · Understanding page experience (22 ก.ย. 2026)
7	Core Web Vitals เป็นปัจจัยอันดับใหญ่ แก้แล้วขึ้นอันดับ 1	ระบบจัดอันดับใช้ Core Web Vitals แต่ไม่มีสัญญาณ page experience ตัวเดียว และความเกี่ยวข้องของเนื้อหายังมาก่อน	Understanding page experience (22 ก.ย. 2026)

ความเชื่อข้อ 1 ยังพบในเอกสารอ้างอิงที่ดีด้วย The Art of SEO ฉบับพิมพ์ปี 2023 บทที่ 7 อธิบาย FID ซึ่งเป็นตัวชี้วัดในช่วงที่พิมพ์ ถ้าใช้หนังสือหรือคอร์สที่ทำก่อนปี 2024 ให้เปลี่ยน FID เป็น INP ทุกจุด ความเชื่อเก่าข้ออื่นในงาน technical SEO สรุปไว้ใน คำแนะนำ technical SEO เก่าที่ควรเลิกใช้

Core Web Vitals มีผลกับ AI Search ไหม

ยังไม่มีเอกสารทางการที่บอกว่า Core Web Vitals เป็นสัญญาณที่ ChatGPT, Gemini หรือ Perplexity ใช้เลือกแหล่งอ้างอิง คำตอบที่ซื่อตรงคือเราไม่รู้ และไม่ควรเชื่อบทความที่ฟันธงว่าเว็บเร็วแล้วจะถูก AI อ้างมากขึ้น ฝั่ง Google นั้น AI Overviews และ AI Mode เลือกจากหน้าที่อยู่ใน index ของ Google Search อยู่แล้ว (ดู AI Overviews คืออะไร) เอกสาร AI features ของ Google (อัปเดต 10 ธ.ค. 2025) บอกว่าหน้าต้องถูก index และแสดง snippet ได้ ไม่มีข้อกำหนดเพิ่ม และนับประสบการณ์ใช้งานที่ดีเป็นแนวปฏิบัติทั่วไป แต่ไม่ได้ระบุว่า Core Web Vitals มีบทบาทพิเศษในการเลือกแหล่งของ AI

สิ่งที่ยืนยันได้และเกี่ยวกับความเร็วโดยตรงคือ bot ต้องโหลดหน้าได้สำเร็จ และเนื้อหาสำคัญต้องอยู่ใน HTML ที่เซิร์ฟเวอร์ส่งมา AI SEO For Dummies บทที่ 2 แนะนำให้เนื้อหาสำคัญอยู่ใน HTML ที่ render จากเซิร์ฟเวอร์ บทที่ 10 ให้ตรวจว่า bot เห็นหน้าเหมือนคนไหม ทั้ง HTML ดิบและหน้าที่ render แล้ว และบทที่ 11 ให้แก้ 3 ปัญหาใหญ่ก่อน ข้อนี้เกี่ยวกับความเร็วตรงที่หน้าที่ timeout หรือพึ่ง JavaScript หนักๆ เสี่ยงให้ bot ได้หน้าว่าง ดูเพิ่มใน JavaScript กับการ render และ robots.txt สำหรับ AI bots

ดังนั้นลำดับที่ใช้ได้ทั้ง Google และ AI Search คือ ให้ bot เข้าถึงและอ่านเนื้อหาได้ก่อน ให้เนื้อหาตอบคำถามได้ตรง แล้วจึงทำ Core Web Vitals ให้ผ่านเพื่อคนอ่านและเพื่อสัญญาณหนึ่งในระบบจัดอันดับของ Google ความต่างระหว่าง Google กับแชตบอต AI อธิบายไว้ใน AI Search คืออะไร

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

แหล่งอ้างอิง

• web.dev, Web Vitals (อัปเดต 31 ต.ค. 2024 ตรวจ 15 ต.ค. 2026: Core Web Vitals 3 ตัว, วัดที่ percentile 75 แยกมือถือและเดสก์ท็อป, ตัวชี้วัดอื่นเป็นตัวช่วย)
• web.dev, Largest Contentful Paint (LCP) (อัปเดต 4 ก.ย. 2025: 2.5 และ 4 วินาที, ชนิดองค์ประกอบ) · Optimize LCP (อัปเดต 31 มี.ค. 2025: เวลา LCP 4 ช่วง)
• web.dev, Interaction to Next Paint (INP) (อัปเดต 2 ก.ย. 2025: 200 และ 500 มิลลิวินาที, นับคลิก แตะ กดคีย์ ไม่นับ scroll hover ซูม, 3 ช่วงของ interaction)
• web.dev, Optimize long tasks (อัปเดต 19 ธ.ค. 2024: งานที่ยาวเกิน 50 มิลลิวินาที = long task)
• web.dev, Learn Performance: Lazy load images and iframe elements (1 พ.ย. 2023: facade แทนวิดเจ็ตแชตที่โหลด JavaScript มาก)
• web.dev, Cumulative Layout Shift (CLS) (อัปเดต 12 เม.ย. 2023 นิยามยังใช้ปัจจุบัน: 0.1 และ 0.25 ไม่มีหน่วย, session window, ไม่นับ 500 มิลลิวินาทีหลังการกด, สาเหตุหลัก) · Optimize CLS (ฟอนต์สำรองและ size-adjust ลดการขยับเมื่อฟอนต์โหลด)
• web.dev, Interaction to Next Paint becomes a Core Web Vital (12 มี.ค. 2024) · Google Search Central blog, Introducing INP to Core Web Vitals (อัปเดต 12 มี.ค. 2024: INP แทน FID)
• Google Search Central, Understanding page experience in Google Search results (last updated 2026-09-22 ตรวจ 15 ต.ค. 2026: “There is no single signal.”, “Core Web Vitals are used by our ranking systems.”, คะแนนดีไม่การันตีอันดับบนสุด, ประเมินระดับหน้าเป็นหลักและมี site-wide บางส่วน) · Core Web Vitals and Google Search results (อัปเดต 10 ธ.ค. 2025)
• Google Search Central, AI features and your website (อัปเดต 10 ธ.ค. 2025: หน้าต้องถูก index และแสดง snippet ได้ ไม่มีข้อกำหนดเพิ่มสำหรับ AI Overviews และ AI Mode)
• Search Console Help, Core Web Vitals report (ตรวจ 15 ต.ค. 2026: ข้อมูล CrUX, กลุ่ม URL, สถานะ = ค่าที่แย่ที่สุด, ต้องมีข้อมูล LCP และ CLS, ใช้ origin แทนเมื่อข้อมูลไม่พอ, 28 วัน, Validate fix 28 วัน, แยกมือถือและเดสก์ท็อป)
• Google for Developers, About PageSpeed Insights (อัปเดต 21 ต.ค. 2024: field data 28 วัน p75 กับ lab data จาก Lighthouse, ช่วงคะแนน 0–49 / 50–89 / 90–100, ผลแล็บดีไม่รับประกันผู้ใช้จริง)
• HTTP Archive, Web Almanac 2025, Performance (เผยแพร่ 15 ม.ค. 2026 อัปเดต 5 พ.ค. 2026 ข้อมูล CrUX ก.ค. 2025: origin ผ่านครบ มือถือ 48% เดสก์ท็อป 56% · มือถือ LCP 62% INP 77% CLS 81% · เดสก์ท็อป LCP 74% INP 97% CLS 72%)
• ข้อมูลของ The Missing Piece: ขนาดไฟล์ฟอนต์ woff2 จาก Google Fonts (CSS2, Chrome user agent, น้ำหนัก 400, 15 ต.ค. 2026, n = 1 ต่อไฟล์) · TTFB หน้าแรก 56 เว็บที่ติดหน้า 1 จากงาน SEO Audit (วัดจากกรุงเทพฯ ครั้งเดียว) · การสังเกตผลค้นหาและ AI Overview คำ “core web vitals”, “inp คือ”, “lcp คือ” และคำตอบ OpenAI ผ่าน API อย่างละ 1 ครั้ง 15 ต.ค. 2026 · ไม่เปิดเผยชื่อเว็บ
• Nathan Gotch, AI SEO For Dummies (Wiley, 2026), บทที่ 2 (เนื้อหาสำคัญควรอยู่ใน HTML ที่ render จากเซิร์ฟเวอร์) · บทที่ 10 (ตรวจ HTML ดิบเทียบหน้าที่ render และไฟล์ที่ถูกบล็อก) · บทที่ 11 (แก้ 3 ปัญหาใหญ่ก่อน) · หมายเหตุ: หนังสือเล่มนี้ไม่มีเนื้อหาเรื่อง Core Web Vitals, LCP, INP หรือ CLS เราอ้างเฉพาะเรื่อง bot ต้องโหลดและอ่านหน้าได้
• Eric Enge, Stephan Spencer, Jessie Stricchiola, The Art of SEO, 4th ed. (O’Reilly, 2023), บทที่ 7 (page experience และ performance เป็นส่วนหนึ่งของเว็บที่เป็นมิตรกับ search engine) · บทที่ 10 (ตรวจเว็บเป็นระบบ) · เล่มนี้ยังใช้ FID ซึ่งล้าสมัยแล้ว นิยามตัวชี้วัดในบทความนี้จึงใช้เอกสารปัจจุบันของ Google และ web.dev

ตรวจข้อมูลล่าสุด: 2 พ.ย. 2026