อธิบาย Core Web Vitals: LCP INP และ CLS แบบเข้าใจง่าย

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

ถ้า Search Console แจ้งว่า URL ของคุณ “แย่” นี่คือคำอธิบายว่าค่าวัดแต่ละตัววัดอะไร อะไรมักทำให้หน้าเว็บไม่ผ่าน วิธีแก้แรกที่ควรลอง และวิธีอ่านรายงาน

คำตอบสั้น ๆ

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

• LCP (Largest Contentful Paint) วัดการโหลด คือเวลาที่ใช้จนรูปภาพหรือบล็อกข้อความที่ใหญ่ที่สุดในจอปรากฏขึ้น ค่าที่ดีคือไม่เกิน 2.5 วินาที
• INP (ระยะเวลาจากการโต้ตอบถึงการแสดงผลถัดไป) วัดการตอบสนอง คือหน้าเว็บใช้เวลานานแค่ไหนกว่าจะตอบสนองให้เห็น หลังการคลิก แตะ หรือกดแป้น ค่าที่ดีคือไม่เกิน 200 มิลลิวินาที
• CLS (Cumulative Layout Shift) วัดความนิ่งของหน้าจอ คือเนื้อหาขยับโดยไม่คาดคิดมากแค่ไหน ค่าที่ดีคือไม่เกิน 0.1

หน้าเว็บจะผ่าน เมื่อทั้งสามค่าอยู่ในเกณฑ์ดี ที่เปอร์เซ็นไทล์ที่ 75 ของการเข้าชมจริง โดยประเมินแยกกันระหว่างมือถือและเดสก์ท็อป INP เข้ามาแทน FID หรือ First Input Delay ในฐานะ Core Web Vital ตั้งแต่มีนาคม 2024

เกณฑ์ Core Web Vitals และวัดจากใคร

Google แบ่งค่าวัดแต่ละตัวออกเป็น 3 ระดับ:

ข้อมูลมาจากผู้เข้าชมจริง Google ใช้ Chrome UX Report (CrUX) คือค่าวัดแบบไม่ระบุตัวตน จากผู้ใช้ Chrome บนเดสก์ท็อปและ Android ที่เลือกเข้าร่วม เก็บต่อเนื่องย้อนหลัง 28 วัน หน้าที่โหลดทันทีบน Wi-Fi ของออฟฟิศ อาจยังไม่ผ่านสำหรับผู้เข้าชมที่ใช้มือถือระดับกลาง และเน็ตมือถือที่สัญญาณไม่นิ่ง

3 ใน 4 ของการเข้าชมต้องดี การเข้าชมที่ช้ามากเพียงไม่กี่ครั้ง ไม่ทำให้ผลล้มเหลว แต่ค่าเฉลี่ยที่เร็วก็ไม่พอ ถ้ามากกว่าหนึ่งในสี่ของการเข้าชม ต้องรอเนื้อหาหลักเกิน 2.5 วินาที หน้านั้นจะไม่ผ่าน LCP

นี่คือเหตุผลที่คะแนน Lighthouse ใน PageSpeed Insights มักไม่ตรงกับ Search Console เพราะ Lighthouse คือการโหลดหน้าแบบจำลองหนึ่งครั้ง โดยไม่มีใครโต้ตอบ มีประโยชน์ในการวินิจฉัย แต่ไม่ใช่สิ่งที่ Google ประเมิน คู่มือ การอ่านรายงาน PageSpeed Insights ของเราอธิบายความต่างนี้ และ คู่มือเพิ่มความเร็วเว็บไซต์ ครอบคลุมงานด้านความเร็วในภาพที่กว้างกว่า

LCP: เนื้อหาหลักมาถึงหรือยัง?

LCP หรือ Largest Contentful Paint คือเวลาตั้งแต่ผู้เข้าชมเริ่มโหลดหน้า จนรูปภาพ วิดีโอ หรือบล็อกข้อความที่ใหญ่ที่สุดในพื้นที่แสดงผล ถูกวาดขึ้นจอ บนเว็บไซต์ธุรกิจส่วนใหญ่ สิ่งนั้นคือรูปภาพหลักด้านบน (hero) หรือหัวข้อหลัก

สาเหตุที่มักทำให้ LCP แย่

แนวทางของ web.dev จาก Google แบ่ง LCP ออกเป็น 4 ส่วน แต่ละส่วนแก้ต่างกัน:

1. การตอบสนองของเซิร์ฟเวอร์: HTML ใช้เวลานานแค่ไหนกว่าจะมาถึง โฮสติ้งที่ช้า และการไม่มีแคชหน้าเว็บ (page caching) คือสาเหตุที่พบบ่อย
2. ความล่าช้าก่อนโหลด: นานแค่ไหนกว่าเบราว์เซอร์จะค้นพบรูปภาพ รูปหลักที่ตั้งเป็น lazy load ตั้งเป็นพื้นหลังใน CSS หรือถูกสไลเดอร์แทรกเข้ามา จะถูกพบช้า
3. เวลาโหลด: ไฟล์ใช้เวลาดาวน์โหลดนานแค่ไหน ซึ่งมักเป็นรูปจากกล้องที่ไม่ได้บีบอัด
4. ความล่าช้าในการแสดงผล: ช่วงเวลาก่อนรูปที่ดาวน์โหลดแล้วจะปรากฏ มักเป็นเพราะสไตล์ชีต สคริปต์ หรือฟอนต์ ยังบล็อกหน้าอยู่

วิธีแก้ LCP ที่ควรลองก่อน

• หาองค์ประกอบ LCP ให้เจอก่อน PageSpeed Insights ระบุไว้ในส่วนการวินิจฉัย บางครั้งเป็นหัวข้อ ไม่ใช่รูปที่คุณคาดไว้
• อย่าใช้ lazy load กับองค์ประกอบนี้ lazy loading มีไว้สำหรับรูปที่อยู่ถัดลงไปด้านล่าง การเพิ่ม fetchpriority="high" ให้รูปหลัก คือการขอให้เบราว์เซอร์ดึงรูปนั้นตั้งแต่เนิ่น ๆ
• ปรับขนาดให้พอดี รูปหลักที่ปรับขนาดให้พอดีกับหน้าจอ และบันทึกเป็น WebP หรือ AVIF มักมีขนาดเพียงเศษเสี้ยวของต้นฉบับ ตามที่ คู่มือปรับแต่งรูปภาพ ของเราอธิบายไว้
• แก้เซิร์ฟเวอร์ที่ช้า ถ้าแค่ HTML ก็กินงบเวลา 2.5 วินาทีไปมากแล้ว การปรับรูปภาพก็ไม่ช่วย ให้เพิ่มแคชหน้าเว็บ หรือย้ายไปโฮสติ้งที่ดีกว่า
• กำจัดสิ่งที่บล็อกการแสดงผล บทความ อธิบายทรัพยากรที่บล็อกการแสดงผล พาไล่ดูวิธีแก้มาตรฐาน สำหรับ CSS สคริปต์ และฟอนต์ที่หนัก

INP: แตะแล้วหน้าเว็บตอบสนองไหม?

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

ทำไม INP จึงมาแทน FID

FID หรือ First Input Delay วัดเฉพาะเวลารอ ก่อนที่เบราว์เซอร์จะ เริ่ม จัดการการโต้ตอบครั้งแรก โดยไม่นับการประมวลผล การอัปเดตหน้าจอ และทุกการโต้ตอบหลังจากนั้น หน้าเว็บจึงผ่าน FID ได้สบาย ๆ แต่ยังรู้สึกอืดอยู่ INP ครอบคลุมการโต้ตอบทั้งหมดตลอดการเข้าชม และเข้ามาแทน FID ในฐานะ Core Web Vital เมื่อ 12 มีนาคม 2024 ซึ่งเป็นเหตุผลที่บางเว็บไซต์เห็นคำเตือนใหม่หลังการเปลี่ยนแปลง

สาเหตุที่มักทำให้ INP แย่

เกือบทุกครั้งคือ JavaScript ที่ทำให้เธรดหลัก (main thread) ของเบราว์เซอร์ยุ่งอยู่ การคลิกถูกจัดการบนเธรดเดียวกับที่รันสคริปต์ การแตะระหว่างงานที่ใช้เวลานานจึงต้องรอ ตัวการที่พบบ่อย:

• ตัวจัดการแท็ก (tag manager) ที่แบกแท็กการตลาดเก่าสะสมมาหลายปี
• วิดเจ็ตแชต เครื่องมือขอความยินยอมคุกกี้ วิดเจ็ตรีวิว และโพสต์โซเชียลที่ฝังไว้
• ตัวสร้างหน้า (page builder) สไลเดอร์ และไลบรารีแอนิเมชัน ที่โหลดสคริปต์หนัก ๆ ในทุกหน้า
• หน้าที่ใหญ่มากจนมีองค์ประกอบนับพัน ซึ่งทำให้การอัปเดตหน้าจอทุกครั้งต้องทำงานมากขึ้น
• ตัวจัดการการคลิก (click handler) ที่ทำงานหนักก่อนอัปเดตหน้าจอ

วิธีแก้ INP ที่ควรลองก่อน

• ตรวจว่ามีอะไรรันอยู่บนหน้า ลบแท็กและปลั๊กอินที่ไม่ได้ใช้ และโหลดที่เหลือเฉพาะหน้าที่จำเป็น คู่มือ สคริปต์ภายนอกกับความเร็วเว็บไซต์ ของเราแสดงวิธีดูว่ามีอะไรโหลดอยู่บ้าง
• โหลดวิดเจ็ตเมื่อต้องใช้ วิดเจ็ตแชต แผนที่ หรือวิดีโอ รอให้มีคนคลิกก่อนค่อยโหลดก็ได้
• ตอบสนองก่อน ทำงานทีหลัง แสดงสถานะว่าถูกกด หรือไอคอนหมุนทันที แล้วค่อยทำงานหนัก นักพัฒนาเรียกสิ่งนี้ว่าการคืนเธรดหลัก (yielding)
• ทดสอบด้วยมือ การทดสอบ Lighthouse มาตรฐานวัด INP ไม่ได้ เพราะไม่มีใครโต้ตอบกับหน้า จึงรายงาน Total Blocking Time แทน ถ้าจะทำให้ปัญหาเกิดซ้ำ ให้ใช้แผง Performance ใน Chrome DevTools โดยเปิดการจำกัดความเร็ว CPU แล้วลองแตะเมนูและแบบฟอร์มไปเรื่อย ๆ

CLS: หน้าเว็บอยู่นิ่งไหม?

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

สาเหตุที่มักทำให้ CLS แย่

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

วิธีแก้ CLS ที่ควรลองก่อน

• กำหนดขนาดให้รูปภาพและสิ่งที่ฝังไว้ แอตทริบิวต์ width และ height หรือ aspect-ratio ใน CSS ช่วยให้เบราว์เซอร์จองพื้นที่ไว้ การกำหนดความสูงขั้นต่ำก็ช่วยจองพื้นที่ให้วิดเจ็ตที่โหลดช้าได้เช่นกัน
• ให้แบนเนอร์ลอยทับ อย่าแทรก ประกาศคุกกี้ที่ติดอยู่ด้านล่างของจอ ไม่ทำให้อะไรขยับ
• ปรับฟอนต์สำรองให้ใกล้เคียง ด้วยค่าปรับอย่าง size-adjust เพื่อให้ตอนสลับฟอนต์ ข้อความแทบไม่ขยับ
• ตรวจตลอดการเข้าชม การทดสอบแบบแล็บมาตรฐาน บันทึกการขยับเฉพาะตอนหน้ากำลังโหลด ถ้า Search Console แจ้ง CLS ที่ Lighthouse ไม่เจอ ให้เลื่อนหน้าบนมือถือดู รูปที่ไม่ได้กำหนดขนาดซึ่งอยู่ลึกลงไป และส่วนหัวติดจอที่เปลี่ยนขนาด คือตัวการที่พบบ่อย

วิธีอ่านรายงาน Core Web Vitals ใน Search Console

รายงานอยู่ในส่วน “ประสบการณ์” ของ Search Console มีกราฟแยกสำหรับมือถือและเดสก์ท็อป แสดงว่า URL ที่จัดทำดัชนีแล้ว มีกี่รายการที่ “แย่” “ต้องปรับปรุง” หรือ “ดี” URL จะได้สถานะตามค่าวัดที่แย่ที่สุดของมัน LCP และ CLS ดี แต่ INP แย่ ก็ยังนับเป็น URL ที่แย่

ถ้ารายงานไม่แสดงข้อมูลเลย มักเป็นเพราะ Chrome UX Report ยังมีการเข้าชมจริงของเว็บไซต์คุณไม่มากพอ ซึ่งพบบ่อยในเว็บไซต์ที่มีผู้เข้าชมน้อย และไม่ใช่ความผิดพลาด ให้ทดสอบเทมเพลตหลักในแล็บ และตรวจว่า PageSpeed Insights มีข้อมูลภาคสนาม (field data) ของทั้งเว็บไซต์ (origin) หรือไม่

ทำไม URL จึงถูกจัดกลุ่ม

Search Console ไม่ได้ตัดสิน URL ทีละรายการ แต่จัดกลุ่มหน้าที่ให้ประสบการณ์คล้ายกัน ซึ่งมักเป็นหน้าที่สร้างจากเทมเพลตเดียวกัน รายงานค่าเปอร์เซ็นไทล์ที่ 75 หนึ่งค่าต่อกลุ่ม และให้ทุก URL ในกลุ่มมีสถานะนั้น คำเตือนบน 400 URL จึงแทบไม่เคยหมายถึง 400 ปัญหา ส่วนใหญ่คือเทมเพลตเดียว (ทุกหน้าบล็อก หน้าสินค้า หรือหน้าโครงการ) ที่มีปัญหาเดียว และการแก้ปัญหานั้น ก็แก้ได้ทั้งกลุ่ม

ไล่แก้ทีละปัญหา

1. เริ่มจากปัญหาระดับ “แย่” บนมือถือ ซึ่งปัญหามักหนักที่สุด
2. เปิดดูปัญหา เพื่อดูกลุ่มที่ได้รับผลกระทบ ค่าของแต่ละกลุ่ม และ URL ตัวอย่าง
3. ทดสอบ URL ตัวอย่างใน PageSpeed Insights แล้วใช้ส่วนการวินิจฉัยหาสาเหตุ
4. แก้ที่เทมเพลต แล้วยืนยันว่าดีขึ้น ด้วยการทดสอบในแล็บ
5. คลิก “เริ่มติดตาม” บนหน้าปัญหา จากนั้น Search Console จะเฝ้าดูข้อมูลภาคสนามใหม่ของปัญหานั้น ในช่วง 28 วัน

ทำไมต้องรอราว 28 วันกว่าจะเห็นผล

ข้อมูลภาคสนามคือช่วงเวลาย้อนหลัง 28 วัน ที่เลื่อนไปเรื่อย ๆ วันถัดจากการแก้ ตัวอย่างข้อมูลยังมีการเข้าชมที่ช้ากว่าอยู่ 27 วัน ค่าเปอร์เซ็นไทล์ที่ 75 จึงดีขึ้นทีละน้อยตลอดราว 4 สัปดาห์ เมื่อข้อมูลเก่าหลุดออกไป ระหว่างนั้น การทดสอบในแล็บคือสิ่งที่ยืนยันผลให้คุณ

Core Web Vitals มีผลต่ออันดับใน Google แค่ไหน?

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

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

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

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

ต้องได้คะแนน Lighthouse 100 ถึงจะผ่าน Core Web Vitals ไหม?

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

ข้อมูล Core Web Vitals รวมผู้เข้าชมจาก iPhone ด้วยไหม?

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

TTFB และ FCP นับเป็น Core Web Vitals ไหม?

ไม่นับ TTFB (เวลาจนได้รับข้อมูลไบต์แรก) และ FCP หรือ First Contentful Paint เป็นค่าวัดเสริมที่แสดงใน PageSpeed Insights และมีประโยชน์ในการวินิจฉัย เช่น TTFB ที่ช้ามักอธิบายได้ว่าทำไม LCP จึงแย่ มีเพียง LCP INP และ CLS ที่นับในการประเมิน

เว็บไซต์ WordPress ผ่าน Core Web Vitals ได้ไหม?

ได้ เมื่อเลือกโฮสติ้ง ธีม ตัวสร้างหน้า และปลั๊กอิน โดยคำนึงถึงความเร็ว คู่มือ เพิ่มความเร็วเว็บไซต์ WordPress ของเราเรียงลำดับไว้ว่าควรทำอะไรก่อนหลัง

ทำอะไรต่อ

หน้าที่ไม่ผ่านส่วนใหญ่มีสาเหตุจากเซิร์ฟเวอร์ที่ช้า รูปหลักที่ใหญ่เกินไป JavaScript ที่มากเกินไป หรือพื้นที่ที่ไม่มีใครจองไว้ แก้ทีละเทมเพลต เริ่มจากปัญหาระดับ “แย่” บนมือถือ แล้วรอให้ช่วง 28 วันตามทัน

การรักษาผลไว้ยากกว่า ทุกปลั๊กอิน แท็ก วิดเจ็ต และรูปภาพขนาดใหญ่ที่เพิ่มเข้ามา ล้วนดึงตัวเลขให้แย่ลง ความเร็วจึงควรเป็นส่วนหนึ่งของการดูแลประจำ ไม่ใช่โครงการครั้งเดียว แผนดูแลเว็บไซต์ ของเราดูแลให้ WordPress อัปเดต สำรองข้อมูล และมีการเฝ้าติดตาม และแผน Growth เพิ่มการปรับปรุงรายเดือน และงานด้านความเร็ว อยากได้ความเห็นที่สองเรื่องคำเตือนใน Search Console ก่อนไหม? ตรวจสอบเว็บไซต์ฟรี จะตรวจความเร็วเว็บไซต์ของคุณ และบอกว่าควรเริ่มตรงไหน