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

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

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

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

สารบัญ

1. ตัวชี้วัดสามตัว: LCP, INP และ CLS
2. วิธีวัด Core Web Vitals
3. ทำไมเว็บไซต์ของคุณน่าจะมีประสิทธิภาพต่ำ
4. วิธีปรับปรุง LCP
5. วิธีปรับปรุง INP
6. วิธีปรับปรุง CLS
7. บทบาทของโครงสร้างพื้นฐานเซิร์ฟเวอร์
8. คำถามที่พบบ่อย

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 อยู่ในช่วงที่ไม่ดีซึ่งต้องวิเคราะห์หาสาเหตุ

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

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

Google Search Console — หากเว็บไซต์ได้รับการยืนยัน รายงาน Core Web Vitals จะจัดกลุ่ม URL ตามข้อมูลภาคสนามที่มีอยู่ เป็นจุดเริ่มต้นที่มีประโยชน์สำหรับดูปัญหาจากผู้ใช้จริง ส่วน URL ที่มีข้อมูลไม่พอยังต้องใช้การทดสอบในห้องปฏิบัติการหรือ RUM ที่สอดคล้องกัน

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

Chrome DevTools — แท็บ Performance แสดงตัวชี้วัดแบบเรียลไทม์และวิเคราะห์การโหลดอย่างละเอียด ฟังก์ชันเหล่านี้เข้ามาแทน Web Vitals Extension ซึ่งยุติการสนับสนุนในปี 2025

ความแตกต่างที่สำคัญ: PageSpeed Insights แสดงทั้งข้อมูลจากห้องปฏิบัติการแบบจำลองและข้อมูลภาคสนามที่รวบรวมใน Chrome UX Report ข้อมูลแบบแรกช่วยวินิจฉัย ส่วนข้อมูลแบบหลังอธิบายประสบการณ์ที่สังเกตได้ในช่วงเวลาหนึ่ง และอาจไม่มีสำหรับ URL ที่มีปริมาณผู้ใช้น้อย

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

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

รูปภาพที่ไม่ได้รับการปรับปรุง — ไฟล์ขนาดหลายเมกะไบต์ที่อัปโหลดด้วยขนาดเดิม แทนที่จะปรับขนาดและบีบอัดให้เหมาะกับบริบท ไฟล์เหล่านี้อาจใช้เวลาส่วนใหญ่ของงบประมาณการโหลดหน้าเว็บ

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

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

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

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

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

ควรแยก LCP ตามขั้นตอนการโหลดทั้งหมด ได้แก่ การตอบสนองแรก การค้นพบและโหลดทรัพยากรหลัก และช่วงรอก่อน element แสดงผล คอขวดจะแตกต่างกันในแต่ละหน้า

ปรับทรัพยากร LCP เมื่อผลวัดชี้ว่าเป็นคอขวด

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

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

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

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

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

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

INP วัดการตอบสนองต่อการโต้ตอบ JavaScript และงานยาวบน main thread เป็นสาเหตุที่พบบ่อย แต่ควรวัดทั้งช่วงรอรับ input การประมวลผล และการแสดง frame ถัดไป

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

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

แท็บ Performance ใน Chrome DevTools แสดงงานที่ใช้ main thread ควรจัดลำดับจากคอขวดที่ตรวจวัดได้จริง และแยกโค้ดของเว็บไซต์ ไลบรารี และบริการจากบุคคลที่สามออกจากกัน

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

พิกเซลติดตาม วิดเจ็ตแชท และเครื่องมือวิเคราะห์มักใช้ defer หรือ async หรือเริ่มทำงานภายหลังได้ แต่ต้องพิจารณาความยินยอม dependency และหน้าที่ของแต่ละระบบ พร้อมวัดและทดสอบเพื่อไม่ให้เกิด regression หรือสูญเสียข้อมูลที่จำเป็น

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

CLS เกิดจากการเลื่อน layout ที่ไม่คาดคิด รูปภาพที่ไม่ได้จองพื้นที่ เนื้อหาที่แทรกภายหลัง ฟอนต์ และการเปลี่ยนแปลงอื่นอาจมีผลต่างกัน

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

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

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

เมื่อฟอนต์เว็บโหลดหลังจากเบราว์เซอร์แสดงข้อความด้วยฟอนต์ระบบแล้ว การเปลี่ยนรูปแบบตัวอักษรอาจเลื่อน layout font-display: optional ช่วยลดความเสี่ยงจากการสลับฟอนต์ล่าช้า และ size-adjust ช่วยปรับ fallback ควรตรวจผลกับฟอนต์และเบราว์เซอร์ที่ใช้งานจริง

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

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

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

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

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

ควรประเมิน TTFB ตามพื้นที่ของผู้ใช้ ประเภทหน้า และโครงสร้างพื้นฐาน หากค่าสูง ต้องแยกสาเหตุจากเครือข่าย cache แอปพลิเคชัน และฐานข้อมูลก่อนดำเนินการ:

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

นี่คือจุดที่ SEO และโครงสร้างพื้นฐานมาบรรจบกัน การตอบสนองเริ่มต้นที่ช้าใช้เวลาส่วนสำคัญก่อนจะแสดงเนื้อหาหลัก จึงต้องวัดผลร่วมกับเครือข่าย cache การ render และทรัพยากรของหน้าเว็บ

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

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

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

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

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

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

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

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

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

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

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

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

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

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