Core Web Vitals คืออะไร

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

  • LCP (Largest Contentful Paint) วัดว่าเนื้อหาหลักปรากฏเร็วเพียงใด เป้าหมายคือไม่เกิน 2.5 วินาที
  • INP (Interaction to Next Paint) วัดว่าหน้าตอบสนองต่อการคลิก แตะ หรือกดแป้นพิมพ์เร็วเพียงใด เป้าหมายคือไม่เกิน 200 มิลลิวินาที
  • CLS (Cumulative Layout Shift) วัดการขยับของเนื้อหาโดยไม่คาดคิด เป้าหมายคือไม่เกิน 0.1

ผลของแต่ละตัวพิจารณาที่เปอร์เซ็นไทล์ที่ 75 ของการเข้าชมจริง และแยกระหว่างมือถือกับเดสก์ท็อป กล่าวอีกอย่างคือ อย่างน้อย 75% ของการเข้าชมควรได้รับประสบการณ์ที่อยู่ในเกณฑ์ “ผ่าน”

ชุดตัวชี้วัดนี้เปลี่ยนตามพฤติกรรมการใช้งานเว็บได้ ในเดือนมีนาคม 2024 ตัวชี้วัด INP เข้ามาแทน First Input Delay (FID) เพราะ FID วัดเฉพาะการโต้ตอบครั้งแรกและมองไม่เห็นความหน่วงที่เกิดขึ้นภายหลัง

Core Web Vitals มีผลต่อ SEO อย่างไร

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

แนวทางที่เหมาะสมจึงไม่ใช่ไล่คะแนนให้เต็มเพื่อ SEO อย่างเดียว แต่คือแก้ปัญหาที่ผู้ใช้สัมผัสได้จริง เช่น รอเนื้อหาหลักนาน ปุ่มตอบสนองช้า หรือข้อความกระโดดจนกดผิด อ่านรายละเอียดจาก เอกสาร Page Experience ของ Google Search Central

LCP, INP และ CLS วัดอะไร

LCP — Largest Contentful Paint

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

เวลาของ LCP หายไปช่วงใด

เวลาของ LCP แบ่งเป็นสี่ช่วงต่อกัน ได้แก่ เวลารอตอบกลับจากเซิร์ฟเวอร์ (TTFB) ช่วงหน่วงก่อนเบราว์เซอร์เริ่มโหลดทรัพยากรของ LCP เวลาโหลดทรัพยากร และช่วงหน่วงก่อนวาดจริง การแยกดูทีละช่วงสำคัญกว่าดูตัวเลขรวม เพราะแต่ละช่วงใช้วิธีแก้ต่างกัน

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

INP — Interaction to Next Paint

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

INP ที่สูงมักเกิดจาก main thread ติดงาน JavaScript ยาว event handler ทำงานมากเกินไป หรือเบราว์เซอร์ต้องคำนวณ style และ layout จำนวนมากก่อนวาดเฟรมถัดไป

CLS — Cumulative Layout Shift

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

สาเหตุที่พบบ่อยคือรูปภาพหรือ iframe ไม่มีขนาดกำกับ กล่องโฆษณาถูกแทรกเหนือเนื้อหา ฟอนต์เปลี่ยนแล้วกินพื้นที่ต่างจากฟอนต์สำรอง หรือ component โหลดเสร็จแล้วดันเนื้อหาเดิมลง

เกณฑ์ Core Web Vitals ที่ควรผ่าน

ตัวชี้วัด ผ่าน ต้องปรับปรุง ไม่ผ่าน
LCP ≤ 2.5 วินาที มากกว่า 2.5 ถึง 4.0 วินาที มากกว่า 4.0 วินาที
INP ≤ 200 มิลลิวินาที มากกว่า 200 ถึง 500 มิลลิวินาที มากกว่า 500 มิลลิวินาที
CLS ≤ 0.1 มากกว่า 0.1 ถึง 0.25 มากกว่า 0.25
ช่วงเกณฑ์ของ LCP, INP และ CLSตัดสินที่เปอร์เซ็นไทล์ที่ 75 ของการเข้าชมจริง และต้องผ่านครบทั้งสามตัว ช่วง “ไม่ผ่าน” ไม่มีขอบบน
  • LCPLargest Contentful Paintผู้ใช้เห็นเนื้อหาหลักเมื่อไร
    ผ่าน≤ 2.5 วินาที
    ต้องปรับปรุง2.5 – 4.0 วินาที
    ไม่ผ่าน> 4.0 วินาที
  • INPInteraction to Next Paintหน้าตอบสนองการกดเร็วแค่ไหน
    ผ่าน≤ 200 มิลลิวินาที
    ต้องปรับปรุง200 – 500 มิลลิวินาที
    ไม่ผ่าน> 500 มิลลิวินาที
  • CLSCumulative Layout Shiftเนื้อหาขยับเองมากแค่ไหน
    ผ่าน≤ 0.1
    ต้องปรับปรุง0.1 – 0.25
    ไม่ผ่าน> 0.25

หน้าเว็บจะถือว่าผ่าน Core Web Vitals เมื่อผ่านครบทั้งสามตัว หากตกตัวใดตัวหนึ่ง ผลรวมของหน้านั้นยังไม่ผ่าน ดูที่มาของเกณฑ์และวิธีคำนวณได้จาก คำอธิบายเกณฑ์ Core Web Vitals บน web.dev

วิธีวัด Core Web Vitals ให้ไม่ตีความผิด

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

เริ่มจากข้อมูลภาคสนาม

ข้อมูลภาคสนาม (field data) มาจากผู้ใช้จริง จึงครอบคลุมอุปกรณ์ เครือข่าย ตำแหน่ง และรูปแบบการใช้งานที่หลากหลาย แหล่งที่ใช้ได้ ได้แก่

  • PageSpeed Insights ส่วนบน ซึ่งแสดงข้อมูล Chrome UX Report (CrUX) ของ URL หรือทั้ง origin เมื่อมีข้อมูลเพียงพอ
  • รายงาน Core Web Vitals ใน Google Search Console สำหรับดูปัญหาเป็นกลุ่ม URL
  • Real User Monitoring (RUM) ที่เก็บจากเว็บของตัวเอง เมื่ออยากเห็นเส้นทางหรือ interaction ที่ CrUX ไม่ได้แจกแจง

ข้อมูล CrUX สรุปจากช่วงเวลา 28 วัน จึงไม่เปลี่ยนทันทีหลัง deploy การแก้ไข และบาง URL ที่มี traffic น้อยอาจไม่มีข้อมูลระดับหน้า ให้ตรวจด้วยว่าตัวเลขที่เห็นเป็นของ URL นั้นจริงหรือเป็นค่า fallback ของทั้ง origin

ใช้ข้อมูลห้องทดลองเพื่อหาสาเหตุ

ข้อมูลห้องทดลอง (lab data) วัดในสภาพแวดล้อมที่ควบคุมได้ด้วย Lighthouse หรือ Performance panel ใน DevTools เหมาะกับการทำซ้ำ เปรียบเทียบก่อน–หลัง และแยกงานบน main thread แต่ไม่ได้สะท้อนผู้ใช้ทั้งหมด

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

รัน Lighthouse จาก command line ได้ดังนี้

npx lighthouse https://example.com --only-categories=performance --view

หากต้องการเก็บข้อมูลจากผู้ใช้จริง ไลบรารี web-vitals ช่วยอ่าน metric จาก browser API และส่งกลับระบบวิเคราะห์ของคุณได้

import { onCLS, onINP, onLCP, type Metric } from 'web-vitals';

function report(metric: Metric) {
	const body = JSON.stringify({
		name: metric.name,
		value: metric.value,
		rating: metric.rating,
		path: location.pathname,
	});
	navigator.sendBeacon('/rum', body);
}

onLCP(report);
onINP(report);
onCLS(report);

ลำดับตรวจและแก้ Core Web Vitals

  1. ยืนยันว่าปัญหาเกิดกับผู้ใช้จริง ดู field data แยก mobile/desktop และตรวจว่าข้อมูลอยู่ระดับ URL หรือ origin
  2. หา metric ที่ทำให้ไม่ผ่าน อย่าเริ่มแก้ทุกอย่างพร้อมกัน เลือก LCP, INP หรือ CLS ที่กระทบมากที่สุดก่อน
  3. จำลองปัญหาใน lab ตั้งค่าอุปกรณ์และเครือข่ายให้ใกล้กับกลุ่มผู้ใช้ แล้วบันทึก trace เพื่อหา element, task หรือ layout shift ที่เป็นต้นเหตุ
  4. แก้ที่สาเหตุและป้องกัน regression เปรียบเทียบ trace ก่อน–หลัง เพิ่ม performance budget หรือ automated check แล้วรอ field data รอบใหม่ยืนยันผล

แนวทางแก้ที่ได้ผลบ่อย

ปรับ LCP

  1. หา element ที่เป็น LCP จริงของหน้านั้น และทำให้เบราว์เซอร์ค้นพบตั้งแต่ HTML ชุดแรก
  2. ใส่ fetchpriority="high" ให้รูปหลักเมื่อเหมาะสม และอย่าโหลดรูป LCP ผ่าน JavaScript หรือ CSS background หากหลีกเลี่ยงได้
  3. อย่าใส่ loading="lazy" ให้ภาพที่อยู่ในกรอบหน้าจอแรก เพราะจะเลื่อนคิวของทรัพยากรที่ควรมาก่อน
  4. ลด TTFB และตัด CSS หรือ script ที่ขวางการเรนเดอร์ออกจาก critical path

อ่านขั้นตอนแยก LCP เป็นรายช่วงได้ที่ Optimize Largest Contentful Paint บน web.dev

ปรับ INP

  1. หา interaction ที่ช้าจาก RUM หรือ Performance panel แทนการเดาจากขนาด bundle เพียงอย่างเดียว
  2. แบ่งงาน JavaScript ที่ยาวเกิน 50 มิลลิวินาทีเป็นชิ้นย่อย และคืนคิวให้เบราว์เซอร์วาดเฟรมระหว่างทาง
  3. ลดงานใน event handler และเลื่อนงานที่ไม่จำเป็นต่อ visual feedback ไปทำภายหลัง
  4. หลีกเลี่ยง layout thrashing จากการสลับอ่านและเขียนค่า layout ซ้ำในรอบเดียว

ปรับ CLS

  1. กำหนด width และ height หรือ aspect-ratio ให้รูปภาพ วิดีโอ และ iframe
  2. จองพื้นที่ให้ banner, embed, ad slot หรือ component ที่จะแทรกภายหลัง
  3. โหลดฟอนต์อย่างเหมาะสม และปรับ metric ของ fallback font ให้ใกล้กับฟอนต์จริง
  4. หลีกเลี่ยงการแทรกเนื้อหาเหนือสิ่งที่ผู้ใช้กำลังอ่าน เว้นแต่เกิดจากการกระทำของผู้ใช้และมีพื้นที่รองรับ

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

ต้องผ่านทั้ง LCP, INP และ CLS หรือไม่

ต้องผ่านครบทั้งสามตัวจึงจะถูกจัดว่า “ผ่าน Core Web Vitals” โดยแต่ละตัวพิจารณาที่เปอร์เซ็นไทล์ที่ 75 และแยกผลระหว่างมือถือกับเดสก์ท็อป

คะแนน Lighthouse 100 แปลว่า Core Web Vitals ผ่านหรือไม่

ไม่จำเป็น Lighthouse เป็นการทดสอบในห้องทดลอง ณ เวลาหนึ่ง ส่วน Core Web Vitals ที่ใช้ประเมินประสบการณ์จริงมาจาก field data ในช่วง 28 วัน และ Lighthouse ไม่ได้วัด INP โดยตรง

แก้ Core Web Vitals แล้วอันดับ Google จะดีขึ้นทันทีหรือไม่

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

อ่านต่อและแหล่งอ้างอิง

หากต้องการประเมินความเร็วเว็บไซต์ร่วมกับโครงสร้างทางเทคนิค เนื้อหา และการค้นพบหน้าเว็บ ดูขอบเขตงานได้ที่ บริการที่ปรึกษาด้าน SEO หรือกลับไปอ่าน บทความทั้งหมดของ Nixxel