Core Web Vitals 2026: คืออะไร ทำไมถึงสำคัญ และวิธีปรับปรุง

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

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

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

สารบัญ

1. ตัวชี้วัดสามตัว: LCP, INP และ CLS

LCP — Largest Contentful Paint

พูดง่ายๆ: ใช้เวลานานเท่าไหร่กว่าเนื้อหาหลักของหน้าเว็บจะมองเห็นได้

ตัวชี้วัดนี้วัดความเร็วที่รับรู้จากมุมมองของผู้ใช้ ไม่ใช่เมื่อหน้าเริ่มโหลด แต่เมื่อส่วนที่สำคัญที่สุด เช่น รูปภาพหลัก, หัวข้อ, บล็อกข้อความกลาง มองเห็นได้จริงๆ

LCP ต่ำกว่า 2.5 วินาที ถือว่าดีสำหรับ Google ระหว่าง 2.5 ถึง 4 วินาทีต้องปรับปรุง เกิน 4 วินาทีเป็นปัญหาร้ายแรง

INP — Interaction to Next Paint

พูดง่ายๆ: หน้าเว็บตอบสนองได้รวดเร็วแค่ไหนเมื่อผู้ใช้ทำอะไรบางอย่าง เช่น คลิกปุ่ม เปิดเมนู กรอกข้อมูล

ตัวชี้วัดนี้แทนที่ FID (First Input Delay) ในเดือนมีนาคม 2024 เพราะวัดการตอบสนองได้ครอบคลุมกว่า ไม่ใช่แค่คลิกแรก แต่ทุกการโต้ตอบระหว่างการนำทาง

INP ต่ำกว่า 200 มิลลิวินาที ถือว่าดี ระหว่าง 200 ถึง 500ms ต้องปรับปรุง เกิน 500ms มีปัญหา

CLS — Cumulative Layout Shift

พูดง่ายๆ: หน้าเว็บ “กระโดด” มากแค่ไหนขณะโหลด ทำให้องค์ประกอบที่ผู้ใช้กำลังดูหรือกำลังจะคลิกเลื่อนไป

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

CLS ต่ำกว่า 0.1 ถือว่าดี ระหว่าง 0.1 ถึง 0.25 ต้องปรับปรุง เกิน 0.25 เป็นปัญหาที่ Google ลงโทษ

2. วิธีวัด Core Web Vitals

ก่อนดำเนินการ คุณต้องรู้ว่าปัญหาอยู่ที่ไหน เครื่องมือหลักสามารถเข้าถึงได้ฟรี:

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

PageSpeed Insights (pagespeed.web.dev) — วิเคราะห์ URL เดียวและให้คะแนน 0 ถึง 100 แยกสำหรับมือถือและเดสก์ท็อป พร้อมการระบุตัวชี้วัดแต่ละตัวและสาเหตุหลักของปัญหา

Web Vitals Extension — ส่วนขยาย Chrome ที่แสดงตัวชี้วัดแบบเรียลไทม์ขณะที่คุณท่องเว็บไซต์

ความแตกต่างที่สำคัญ: PageSpeed Insights แสดงทั้งข้อมูลจากห้องปฏิบัติการ (จำลอง) และข้อมูลภาคสนาม (จริง) ข้อมูลที่ Google ใช้สำหรับการจัดอันดับคือข้อมูลจริงที่รวบรวมจากผู้ใช้ผ่าน Chrome

3. ทำไมเว็บไซต์ของคุณน่าจะมีประสิทธิภาพต่ำ

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

รูปภาพที่ไม่ได้รับการปรับปรุง — รูปภาพที่อัปโหลดด้วยความละเอียดกล้องเดิม (มักจะ 4 ถึง 6MB) แทนที่จะเป็นเวอร์ชันที่ปรับขนาดและบีบอัดแล้ว เพียงอย่างเดียวก็สามารถยกเลิกความพยายามในการปรับปรุงอื่นๆ ทั้งหมดได้

ปลั๊กอินและสคริปต์จากบุคคลที่สามมากเกินไป — เครื่องมือวิเคราะห์, วิดเจ็ตแชท, พิกเซลติดตาม, ฟอนต์ภายนอก: สะสมอย่างรวดเร็วและทำให้ทุกอย่างช้าลง

Hosting คุณภาพต่ำ — เวลาตอบสนองของเซิร์ฟเวอร์ (TTFB) คือรากฐานที่การปรับปรุงอื่นๆ ทั้งหมดสร้างขึ้น ด้วย hosting ที่ช้า แม้แต่เว็บไซต์ที่ปรับปรุงอย่างสมบูรณ์แบบก็จะมี LCP ที่ไม่ดี

ไม่มีระบบ cache — ทุกหน้าถูกสร้างตั้งแต่ต้นในทุกคำขอแทนที่จะให้บริการจากสำเนาที่สร้างไว้แล้ว

ฟอนต์เว็บที่โหลดไม่ถูกต้อง — ฟอนต์กำหนดเองเป็นหนึ่งในสาเหตุที่พบบ่อยที่สุดของ CLS: หน้าเว็บแสดงฟอนต์ระบบก่อน จากนั้นฟอนต์กำหนดเองโหลดและเลื่อน layout

4. วิธีปรับปรุง LCP

LCP ขึ้นอยู่กับปัจจัยหลักสองประการ: ความเร็วในการตอบสนองของเซิร์ฟเวอร์และขนาดของ element หลักของหน้า

ปรับปรุงรูปภาพ — นี่คือลำดับความสำคัญสูงสุด

รูปแบบ WebP มีคุณภาพภาพที่เทียบเท่า JPEG แต่มีขนาดไฟล์เล็กกว่าถึง 30% รูปแบบ AVIF รองรับโดยเบราว์เซอร์ทันสมัยทั้งหมดในปี 2026 ปรับขนาดรูปภาพให้เป็นขนาดสูงสุดที่แสดงจริงเสมอ ไม่มีประโยชน์ที่จะโหลดรูปภาพกว้าง 3,000px หาก container มีความกว้างเพียง 800px

ใช้ lazy loading แต่ด้วยวิจารณญาณ

Lazy loading เลื่อนการโหลดรูปภาพที่ไม่มองเห็นใน viewport เริ่มต้น แต่ต้องไม่นำไปใช้กับรูปภาพหลักที่ส่งผลต่อ LCP ความผิดพลาดทั่วไปคือเปิดใช้งาน lazy loading ทั่วโลกสำหรับรูปภาพทั้งหมดและทำให้ LCP แย่ลงโดยไม่ตั้งใจ

ใช้ cache ฝั่งเซิร์ฟเวอร์

ระบบ cache ให้บริการหน้าที่สร้างไว้แล้วแทนที่จะสร้างใหม่ทุกคำขอ ความแตกต่างใน TTFB อาจเป็นหนึ่งระดับ

5. วิธีปรับปรุง INP

INP วัดการตอบสนองต่อการโต้ตอบ และเกือบตลอดเวลาเป็นปัญหาที่เกิดจาก JavaScript ที่บล็อก main thread ของเบราว์เซอร์

ระบุสคริปต์ที่หนัก

แท็บ Performance ใน Chrome DevTools แสดงสคริปต์ที่ใช้เวลานานที่สุด บ่อยครั้งพบว่า 90% ของเวลาดำเนินการถูกใช้โดยสคริปต์จากบุคคลที่สามหนึ่งหรือสองตัว

โหลดสคริปต์จากบุคคลที่สามแบบ deferred

พิกเซลติดตาม, วิดเจ็ตแชท, เครื่องมือวิเคราะห์: ในกรณีส่วนใหญ่ไม่จำเป็นต้องพร้อมใช้งานทันทีที่หน้าเปิด การโหลดด้วย attribute defer หรือ async ช่วยปรับปรุง INP โดยไม่กระทบการทำงาน

6. วิธีปรับปรุง CLS

CLS เกือบตลอดเวลาเกิดจาก element ที่หน้าไม่รู้ว่าจะวางไว้ที่ไหนจนกว่าจะโหลดเสร็จ

ระบุขนาดของรูปภาพและวิดีโอเสมอ

หากเบราว์เซอร์ไม่รู้ขนาดของรูปภาพล่วงหน้า จะแสดงพื้นที่ว่างก่อนแล้วจึงแทรกเมื่อดาวน์โหลดเสร็จ ซึ่งทำให้ element อื่นๆ เลื่อน การเพิ่ม attribute width และ height ให้กับ element <img> (หรือใช้ CSS aspect-ratio) แก้ปัญหา CLS ที่เกิดจากรูปภาพส่วนใหญ่

จองพื้นที่สำหรับฟอนต์กำหนดเอง

เมื่อฟอนต์เว็บโหลดหลังจากเบราว์เซอร์แสดงข้อความด้วยฟอนต์ระบบแล้ว การเปลี่ยนรูปแบบตัวอักษรอาจเลื่อน layout คุณสมบัติ CSS font-display: optional หลีกเลี่ยงปัญหาโดยใช้ฟอนต์กำหนดเองเฉพาะเมื่ออยู่ใน cache แล้ว

ระวัง banner และ element ที่แทรกแบบไดนามิก

โฆษณา, banner คุกกี้, การแจ้งเตือน: หากแทรกในหน้าหลังการโหลดเริ่มต้นและเลื่อนเนื้อหาที่มองเห็นอยู่แล้ว จะส่งผลเสียต่อ CLS วิธีแก้คือจองพื้นที่ที่จะครอบครองล่วงหน้า

7. บทบาทของโครงสร้างพื้นฐานเซิร์ฟเวอร์

มีด้านหนึ่งที่มักถูกมองข้ามในการถกเถียงเรื่อง Core Web Vitals: การปรับปรุง front-end ทั้งหมดมีเพดานสูงสุดที่กำหนดโดยความเร็วของเซิร์ฟเวอร์ที่รองรับ

TTFB (Time To First Byte) — เวลาที่เบราว์เซอร์รอก่อนได้รับ byte แรกของการตอบสนองจากเซิร์ฟเวอร์ — คือพื้นที่ที่การปรับปรุงอื่นๆ ทั้งหมดสร้างขึ้น ด้วย TTFB สูง แม้แต่เว็บไซต์ที่ปรับปรุงอย่างสมบูรณ์แบบก็ไม่มีทางบรรลุ LCP ที่ยอดเยี่ยม

TTFB ต่ำกว่า 200 มิลลิวินาทีคือเป้าหมาย การบรรลุเป้าหมายต้องใช้:

เซิร์ฟเวอร์ที่อยู่ใกล้ผู้ใช้ทางภูมิศาสตร์ หรือการใช้ CDN ที่กระจายเนื้อหาบน node ทั่วโลก
การกำหนดค่าเซิร์ฟเวอร์ที่ปรับปรุงแล้ว เวอร์ชันซอฟต์แวร์ที่อัปเดต, opcode cache ที่ใช้งานอยู่
แผน hosting ที่เหมาะสม บน shared hosting ราคาถูก TTFB จะสูงโดยโครงสร้าง

นี่คือจุดที่ SEO และโครงสร้างพื้นฐานมาบรรจบกันอย่างหลีกเลี่ยงไม่ได้ คุณสามารถปรับปรุงทุกรูปภาพและทุกบรรทัด JavaScript แต่หากเซิร์ฟเวอร์ตอบสนองใน 800ms คุณก็อยู่นอกเกณฑ์ของ LCP ที่ดีก่อนที่จะเริ่มด้วยซ้ำ

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

Core Web Vitals ส่งผลต่อการจัดอันดับ Google จริงหรือ?

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

คะแนน PageSpeed ขั้นต่ำเท่าไหร่ที่ทำให้สบายใจ?

PageSpeed Insights ให้คะแนน 0 ถึง 100 แต่ตัวเลขนั้นไม่ใช่สิ่งที่ Google ใช้สำหรับการจัดอันดับ Google ใช้ตัวชี้วัดแต่ละตัว (LCP, INP, CLS) และเกณฑ์ของพวกมัน กล่าวได้ว่า คะแนนต่ำกว่า 50 บนมือถือแทบจะเป็นสัญญาณของปัญหาร้ายแรงเสมอ เกิน 70 บนมือถือเป็นจุดเริ่มต้นที่ดี เกิน 90 ยอดเยี่ยม

มือถือและเดสก์ท็อปมีความสำคัญเท่ากันหรือไม่?

Google ใช้การ crawl แบบ mobile-first ตั้งแต่ปี 2019 ประเมินเว็บไซต์ของคุณเป็นหลักตามที่ผู้ใช้สมาร์ทโฟนจะเห็น Core Web Vitals บนมือถือจึงมีน้ำหนักมากกว่า

ฉันสามารถปรับปรุง Core Web Vitals เองได้หรือต้องการผู้เชี่ยวชาญ?

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

ควรตรวจสอบ Core Web Vitals ของเว็บไซต์บ่อยแค่ไหน?

Google Search Console อัปเดตข้อมูลด้วยความล่าช้าประมาณ 28 วัน การตรวจสอบรายเดือนเพียงพอสำหรับเว็บไซต์ที่เสถียร หลังการเปลี่ยนแปลงเว็บไซต์ที่สำคัญ ควรตรวจสอบทันทีด้วย PageSpeed Insights

เว็บไซต์ของฉันได้คะแนนดีบนเดสก์ท็อปแต่แย่มากบนมือถือ จะเริ่มจากไหน?

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

Core Web Vitals ของเว็บไซต์คุณอยู่ในช่วงดี ต้องปรับปรุง หรือมีปัญหาหรือไม่? เราทำการวิเคราะห์ที่ครอบคลุม: SEO เชิงเทคนิค, ความเร็ว, โครงสร้างพื้นฐานเซิร์ฟเวอร์ และการปรับปรุงประสิทธิภาพ ติดต่อเรา เพื่อค้นหาสิ่งที่กำลังถ่วงเว็บไซต์ของคุณ