Core Web Vitals: ตัวชี้วัดประสิทธิภาพ ค่าเกณฑ์ และลำดับความสำคัญในการปรับปรุง

ค่าเกณฑ์ Core Web Vitals การหาคอขวด และลำดับความสำคัญในการปรับปรุงเว็บไซต์ B2B

Core Web Vitals: ตัวชี้วัดประสิทธิภาพ ค่าเกณฑ์ และลำดับความสำคัญในการปรับปรุง

สรุปก่อน: Core Web Vitals คือคะแนนประสบการณ์การใช้งานหน้าเว็บของ Google ตัวชี้วัดหลักสามตัวมีเกณฑ์ผ่านคือ LCP ≤ 2.5 วินาที, INP ≤ 200 มิลลิวินาที และ CLS ≤ 0.1 ตัดสินจากเปอร์เซ็นไทล์ที่ 75 ปัญหาประสิทธิภาพ 80% ของเว็บไซต์ B2B กระจุกอยู่สามจุด คือ รูปภาพใหญ่ในหน้าจอแรกไม่ได้บีบอัด สคริปต์แชทและ CRM ของบุคคลที่สามบล็อกเธรดหลัก และรูปภาพไม่มีอัตราส่วนกว้างยาวทำให้เลย์เอาต์ขยับ ลำดับการปรับปรุงคือ LCP ก่อน INP ก่อน CLS แก้รูปภาพก่อน แก้สคริปต์ทีหลัง แก้เลย์เอาต์เป็นลำดับสุดท้าย ดูข้อมูลให้เชื่อเฉพาะข้อมูลภาคสนาม 28 วันจาก Search Console อย่าเอาคะแนนแล็บจาก Lighthouse มาสรุป

หนึ่ง ตัวชี้วัดสามตัววัดอะไรกันแน่

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

ตัวชี้วัด	ชื่อเต็ม	สิ่งที่วัด	เกณฑ์ผ่าน	ควรปรับปรุง
LCP	Largest Contentful Paint	เวลาที่องค์ประกอบใหญ่ที่สุดในหน้าจอแรกเรนเดอร์เสร็จ	≤ 2.5 วินาที	2.5 ถึง 4 วินาที
INP	Interaction to Next Paint	ความหน่วงจากการโต้ตอบของผู้ใช้จนถึงการวาดเฟรมถัดไป	≤ 200 มิลลิวินาที	200 ถึง 500 มิลลิวินาที
CLS	Cumulative Layout Shift	คะแนนสะสมของการเลื่อนเลย์เอาต์โดยไม่คาดคิด	≤ 0.1	0.1 ถึง 0.25
TTVC	ต่อยอดจาก Time to First Contentful Paint	เวลาที่เนื้อหาที่มีประโยชน์ชิ้นแรกถูกวาด	≤ 1.8 วินาที	1.8 ถึง 3 วินาที

สองความเข้าใจสำคัญ ข้อแรก เปอร์เซ็นไทล์ที่ 75: การที่ Google ตัดสินว่าหน้าเว็บของคุณดีหรือไม่ ดูจากผลของผู้ใช้จริง 75% บนตัวชี้วัดนี้ ไม่ใช่ค่าเฉลี่ย และไม่ใช่ผู้ใช้ที่เร็วที่สุด ข้อสอง INP เข้ามาแทน FID อย่างเป็นทางการในเดือนมีนาคม 2024 นับจากนั้นความหน่วงจากการโต้ตอบกลายเป็นตัวชี้วัดหลัก ซึ่งส่งผลกับเว็บไซต์ B2B ที่ติดตั้งแชทสด ระบบการตลาดอัตโนมัติ และป๊อปอัปแชทไว้เต็มไปหมดมากที่สุด เพราะสคริปต์เหล่านี้คือสาเหตุหลักที่บล็อกเธรดหลัก

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

สอง แหล่งข้อมูล: สามเครื่องมือดูอะไรบ้าง

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

เครื่องมือ	ประเภทข้อมูล	การสุ่มตัวอย่าง	เหมาะกับ	ข้อจำกัด
PageSpeed Insights	ผสมระหว่างแล็บและภาคสนาม	รันทดสอบครั้งเดียว + CrUX 28 วัน	วินิจฉัยหน้าเดียวแบบรวดเร็ว	ค่าแล็บกับผู้ใช้จริงมีความต่าง
CrUX	ข้อมูลภาคสนาม	ผู้ใช้ Chrome รายงานแบบไม่ระบุตัวตน	ดูการกระจายจริง	เว็บทราฟฟิกน้อยมีตัวอย่างไม่พอ
Search Console	สรุปข้อมูลภาคสนาม	ย้อนหลัง 28 วัน	ดูแนวโน้มตามเทมเพลต	ไม่มีเจาะลึกรายหน้า
Lighthouse CI	ข้อมูลจากแล็บ	รันทดสอบในเครื่อง	ทดสอบ regression ก่อน deploy	ไม่สะท้อนผู้ใช้จริงออนไลน์
Web Vitals .js	ฝังโค้ดเก็บข้อมูลภาคสนามเอง	ผู้ใช้ของตัวเอง	เว็บเล็กเก็บตัวอย่างเพิ่ม	ต้องลงแรงฝั่งพัฒนา

หลักปฏิบัติ: ใช้รายงาน Core Web Vitals ใน Search Console หาว่าเทมเพลตไหนมีปัญหา ใช้ PageSpeed Insights เจาะลึกรายหน้าเพื่อหาคอขวด ใช้ Lighthouse CI ทำ regression ก่อนออกเวอร์ชันทุกครั้ง อย่าทำกลับกัน คือเอาคะแนนจากแล็บมาเป็นผลงานออนไลน์ นั่นคือการหลอกตัวเองที่พบบ่อยที่สุดในการปรับประสิทธิภาพ

สาม、ปรับ LCP: ภาพใหญ่หน้าแรกคือศัตรูอันดับหนึ่ง

ปัญหา LCP ของเว็บ B2B 80% มาจากภาพ hero และสไลด์หน้าแรก

คอขวด	อาการที่พบ	สิ่งที่ต้องทำ	ผลที่คาดว่าจะได้
ภาพแรกยังไม่บีบอัด	ภาพ hero เป็น PNG ขนาด 500KB ขึ้นไป	แปลงเป็น WebP/AVIF คุณภาพ 80 ใช้ srcset หลายขนาด	LCP ลดลง 0.5 ถึง 1.5 วินาที
ภาพแรกไม่ได้ preload	เบราว์เซอร์เจอภาพ hero ช้า	ใส่ preload ชี้ไปที่ภาพแรกใน head	LCP ลดลง 0.2 ถึง 0.5 วินาที
ฟอนต์บล็อกการเรนเดอร์	ฟอนต์กำหนดเองโหลดช้าทำให้จอขาว	font-display: swap โหลดเฉพาะน้ำหนักที่ใช้	LCP ลดลง 0.3 ถึง 0.8 วินาที
เซิร์ฟเวอร์ตอบสนองช้า	TTFB เกิน 1.8 วินาที	ใช้ CDN เปิด HTTP/2 แคช PHP	LCP ลดลง 0.4 ถึง 1 วินาที
สคริปต์บุคคลที่สามหน่วงการเพนต์ครั้งแรก	สคริปต์ติดตามใน head บล็อก	ใช้ defer หรือเลื่อนไปโหลดหลัง idle	LCP ลดลง 0.2 ถึง 0.6 วินาที

จุดที่มักมองข้าม: เว็บ B2B มักใช้ภาพมุมกว้างโรงงานหรือภาพสินค้าขนาดใหญ่เป็น hero ซึ่งมักเป็นภาพถ่ายต้นฉบับขนาด 2MB ขึ้นไป บีบอัดให้เหลือไม่เกิน 200KB ใช้ WebP และใส่ preload ทำสามอย่างนี้เสร็จ LCP มักลดลงครึ่งหนึ่ง ถ้าเซิร์ฟเวอร์อยู่ในจีนแต่ลูกค้าอยู่ยุโรปและอเมริกา TTFB จะสูงโดยธรรมชาติ ต้องใช้ CDN

สี่、ปรับ INP: สคริปต์บุคคลที่สามคือตัวการหลัก

หลัง INP มาแทน FID เว็บ B2B พังกันถ้วนหน้า เพราะเว็บประเภทนี้ติดสคริปต์การตลาดและแชทไว้เยอะเกินไป

ประเภทสคริปต์	แหล่งที่มาที่พบบ่อย	ผลต่อ INP	วิธีจัดการ
แชทสด	Intercom, Zendesk, Tawk	งานยาวบน main thread 200 ถึง 800ms	โหลดหลังหน้าแรก 3 วินาที หรือรอเลื่อนถึงล่างสุดก่อนโหลด
ระบบอัตโนมัติการตลาด	HubSpot, Marketo, Pardot	ฟอร์มและป๊อปอัปบล็อกการโต้ตอบ	โหลดเฉพาะหน้าที่ต้องการ เอาออกจากหน้าอื่น
ฮีตแมปและวิเคราะห์	Hotjar、FullStory	สคริปต์บันทึกกิน main thread ตลอด	สุ่มเก็บ 10% ของผู้ใช้ ไม่บันทึกทั้งหมด
ป๊อปอัปแชท	WhatsApp、หน้าต่างลอย WeCom	คลิกป๊อปอัปแล้วดีเลย์	ใช้ปุ่มเนทีฟ โหลดสคริปต์หลังคลิก
สไลด์ที่เขียนเอง	สไลด์สินค้าหน้าแรก	งานยาวจาก JS เล่นอัตโนมัติ	เปลี่ยนเป็นสไลด์ CSS ปิดเล่นอัตโนมัติ

หาคอขวดโดยอัดการโต้ตอบบนหน้าเว็บหนึ่งครั้งด้วยแผง Performance ใน Chrome DevTools ดูงานยาวสีม่วงบน main thread ตัวไหนกินเวลานานสุดก็จัดการก่อน หลักการ: สคริปต์ใดที่ไม่จำเป็นต่อหน้าแรก ให้เลื่อนไปโหลดหลังผู้ใช้เลื่อนหน้าครั้งแรกหรือหลัง idle 5 วินาที เรื่องปลั๊กอินต้องรู้จักยับยั้งชั่งใจ ดูเพิ่มเติมที่ชุดปลั๊กอิน 4 ตัวสำหรับเว็บไซต์ที่ทำตลาดต่างประเทศ ยิ่งติดตั้งมาก INP ยิ่งผ่านยาก

5. การปรับ CLS: กำหนดขนาดให้สื่อทุกชนิด

CLS เป็นตัวชี้วัดที่แก้ไขง่ายที่สุด แต่กลับถูกละเลยมากที่สุด

สาเหตุการเลื่อน	เหตุผล	วิธีแก้ไข	CLS หลังแก้ไข
รูปภาพไม่มีขนาด	img ไม่มี width/height	เพิ่ม attribute width/height หรือ aspect-ratio	ใกล้ 0
พื้นที่โฆษณาสำรองไม่เพียงพอ	โฆษณาโหลดแบบ async แล้วดันพื้นที่	กำหนดความสูงขั้นต่ำให้ container ล่วงหน้า	ลดลง 0.05 ถึง 0.15
การสลับฟอนต์	FOIT/FOUT ทำให้เกิดการจัดวางใหม่	font-display: swap พร้อมสำรองขนาดฟอนต์ fallback	ลดลง 0.02 ถึง 0.08
เนื้อหาที่แทรกแบบไดนามิก	แทรกหลังส่วนแนะนำหรือบทความที่เกี่ยวข้อง	สำรองความสูงให้ container placeholder	ลดลง 0.05 ถึง 0.1
รูป lazy load มาช้า	รูป loading=lazy โหลดช้าแล้วดันเนื้อหาด้านล่าง	ใช้รูป placeholder หรือ aspect-ratio	ลดลง 0.03 ถึง 0.07

กฎตายตัวข้อหนึ่ง: img, video, iframe ทุกตัวบนหน้าต้องระบุ attribute width และ height ใน HTML ส่วน CSS ใช้ aspect-ratio เพื่อรองรับ responsive เรื่องนี้ไม่ต้องรอคิวพัฒนา แก้เทมเพลตครั้งเดียวได้ผลทั้งเว็บ การเข้าถึงและประสิทธิภาพเป็นงานที่มาจากต้นทางเดียวกันในเรื่องการสำรองขนาด ดูเพิ่มที่ขอบเขตการเข้าถึงของเว็บไซต์ B2B。

6. ลำดับความสำคัญในการปรับและจังหวะการทำซ้ำ

ระยะ	ระยะเวลา	เป้าหมาย	การดำเนินการ	ตัวชี้วัดการยอมรับ
สัปดาห์แรก	วินิจฉัย	ระบุเทมเพลตที่มีปัญหา	ดึงข้อมูล 28 วันจาก Search Console แล้วลิสต์ 10 หน้าที่แย่ที่สุด	รายการเทมเพลตที่มีปัญหา
สัปดาห์ที่สอง	บุก LCP	LCP ของทุกเทมเพลตเข้า 2.5 วินาที	บีบอัดรูป + preload + ปรับฟอนต์	การกระจาย LCP ใน PSI
สัปดาห์ที่สาม	บุก INP	ลดสคริปต์บุคคลที่สาม	เลื่อนการโหลด สุ่มบันทึก ลบสคริปต์ที่ไม่จำเป็น	จำนวน long task ลดลง 50%
สัปดาห์ที่สี่	ปิดงาน CLS	CLS ทั้งเว็บต่ำกว่า 0.1	attribute width/height, container placeholder	GSC ไม่มีหน้าที่มีข้อผิดพลาด CLS
ต่อเนื่อง	การมอนิเตอร์	ปล่อยเวอร์ชันแล้วไม่ถอยกลับ	รัน Lighthouse CI ทุกครั้งที่ deploy	คะแนนไม่ต่ำกว่าเวอร์ชันก่อน

การดูแลเว็บไซต์มีจังหวะที่แน่นอนอยู่แล้ว ประสิทธิภาพเป็นเพียงหนึ่งในนั้น ดูเพิ่มที่งานดูแลรายเดือน 6 อย่าง หลังปรับดีไซน์หรือย้ายระบบ ประสิทธิภาพมักถอยกลับ ต้องทำ regression ควบคู่กับ การย้าย 301 และการรักษา SEO กลับมาเริ่มกันใหม่

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

Lighthouse ได้คะแนน 90 ขึ้น แต่ Search Console กลับแสดงว่าไม่ผ่าน เพราะอะไร?

เพราะ Lighthouse วัดข้อมูลในห้องแล็บ วัดครั้งเดียวในสภาพแวดล้อมที่สะอาด ส่วน Search Console ใช้ข้อมูลผู้ใช้จริง 28 วัน รวมถึง 4G ที่สัญญาณอ่อน มือถือเก่า และสคริปต์บุคคลที่สามจริง ตัวอย่างของทั้งสองต่างกันโดยสิ้นเชิง วิธีที่ถูกต้องคือใช้ GSC เป็นผู้ตัดสิน ใช้ PSI เป็นเครื่องมือวินิจฉัย: GSC แสดงว่าเทมเพลตไหนไม่ผ่าน ก็ใช้ PSI รันหน้าเดี่ยวของเทมเพลตนั้นเพื่อหาคอขวด ไม่ต้องไล่ให้ Lighthouse ได้คะแนนเต็ม

เว็บไซต์ B2B มีทราฟฟิกน้อย ตัวอย่าง CrUX ไม่เพียงพอ ทำอย่างไร?

เว็บเล็ก ๆ สามารถใช้ Web Vitals.js เก็บข้อมูลผู้ใช้จริงของตัวเองได้ ติดตั้งโค้ดประมาณ 1KB ไว้ใน head ของหน้าเว็บ แล้วส่งค่า LCP, INP และ CLS ไปยัง data warehouse ของตัวเอง วิธีนี้ทำให้คุณมีข้อมูลภาคสนามของตัวเอง แม้ CrUX จะไม่มีข้อมูลของคุณ ข้อควรระวังคือเก็บเฉพาะค่าตัวชี้วัด ไม่เก็บข้อมูลส่วนตัวของผู้ใช้ เพื่อให้สอดคล้องกับ GDPR ดูเพิ่มเติมที่GDPR กับความสอดคล้องด้านข้อมูล Cookie。

สไลด์โชว์หน้าแรก ควรทำหรือไม่?

จากมุมมองด้านประสิทธิภาพ แนะนำให้ตัดสไลด์โชว์อัตโนมัติออก เพราะผู้ใช้แทบไม่เห็นภาพที่สองและสาม แต่ต้องดาวน์โหลด แยกวิเคราะห์ และรัน JS ของสไลด์โชว์ ซึ่งเป็นภาระทั้งต่อ LCP และ INP เปลี่ยนเป็นภาพ hero เดียวพร้อม CTA หรือใช้ CSS ทำปุ่มเลื่อนด้วยมือแทน หากธุรกิจจำเป็นต้องมีสไลด์โชว์ ให้ใส่ loading=lazy กับภาพตั้งแต่ภาพที่สองเป็นต้นไป และไม่ให้ JS ของสไลด์โชว์บล็อกการแสดงผลหน้าแรก

การปรับ INP ต้องลบปลั๊กอินแชทหรือไม่?

ไม่ต้องลบ แต่ให้เลื่อนการโหลด สคริปต์แชทอย่าง Intercom หรือ Zendesk มีคุณค่าต่อการแปลงลูกค้า B2B แต่ไม่ควรทำงานตั้งแต่โหลดหน้าแรก วิธีคือรอ 3 วินาทีหลังโหลดหน้าแรก หรือรอจนผู้ใช้เลื่อนหน้า 20% ของ viewport ก่อน แล้วค่อย inject สคริปต์ วิธีนี้ยังคงช่องทางติดต่อลูกค้าไว้ โดยไม่บล็อกการโต้ตอบครั้งแรก ปุ่มลอย WhatsApp ก็เช่นกัน ใช้ปุ่ม native แล้วค่อยโหลด web SDK เมื่อคลิก

CLS อยู่ที่ประมาณ 0.15 ตลอด จะลดให้ต่ำกว่า 0.1 ได้อย่างไร?

ใช้แผง Layout Shift ใน DevTools หาองค์ประกอบที่เกิดการเลื่อน สาเหตุที่พบบ่อยที่สุดในเว็บ B2B มีสามข้อ: รูปภาพไม่ได้ระบุ width/height, ส่วนบทความที่เกี่ยวข้องหรือส่วนแนะนำถูกแทรกด้วย JS แบบอะซิงโครนัสโดยไม่จองพื้นที่ไว้, และตัวอักษรจัดเรียงใหม่หลังโหลดฟอนต์ เมื่อแก้ครบสามข้อ CLS มักลดลงต่ำกว่า 0.05 วิธีทำคือใส่ความกว้างความสูงให้ img ทุกตัว ตั้ง aspect-ratio ให้คอนเทนเนอร์อะซิงโครนัสทุกตัว และใช้ font-display: swap พร้อมเลือกฟอนต์ระบบสำรองที่มีขนาดใกล้เคียงกัน

CDN แก้ปัญหาประสิทธิภาพได้มากแค่ไหน?

CDN แก้ปัญหา TTFB และการกระจายไฟล์ static เป็นหลัก ช่วยเรื่อง LCP ประมาณ 0.3 ถึง 1 วินาที แต่แทบไม่มีผลกับ INP และ CLS หากเซิร์ฟเวอร์ของคุณอยู่ในไทยและลูกค้าอยู่ในยุโรปหรืออเมริกา TTFB อาจสูงเกิน 2 วินาที การใช้ CDN จึงเป็นสิ่งแรกที่ต้องทำ แต่ถ้า TTFB ต่ำกว่า 600ms อยู่แล้ว การใช้ CDN จะได้ผลตอบแทนจำกัด ควรลงทุนกับรูปภาพและสคริปต์แทน Cloudflare แบบฟรีก็เพียงพอสำหรับเว็บเล็ก ส่วนเว็บองค์กรแนะนำ Cloudflare Pro หรือ AWS CloudFront

ทิ้งท้าย

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

ลงมือ 3 ขั้นตอน: สัปดาห์นี้ดึงเทมเพลตที่แย่ที่สุด 10 อันจาก Search Console มาทำลิสต์; สัปดาห์ที่สองบีบอัดภาพ hero แล้วเพิ่ม preload; สัปดาห์ที่สามเลื่อนการโหลดสคริปต์แชทและมาร์เก็ตติ้งทั้งหมด ทำครบสามขั้นนี้แล้วค่อยกลับไปดู GSC อัตราไม่ผ่านมักลดลงเกินครึ่ง

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