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

Core Web Vitals ไม่ใช่แบบทดสอบบุคลิกภาพของเว็บไซต์คุณ

Core Web Vitals มักถูกปฏิบัติเหมือนบัตรคะแนนลึกลับ หน้าเว็บได้ตัวเลขสีแดง มีคนโพสต์ภาพหน้าจอใน Slack แล้วทีมก็เริ่มถกเถียงกันเรื่อง JavaScript frameworks

นั่นไม่ค่อยมีประโยชน์นัก

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

• เนื้อหาหลักใช้เวลานานเกินไปกว่าจะปรากฏ
• เพจตอบสนองช้าเมื่อผู้ใช้พยายามทำบางอย่าง
• เลย์เอาต์กระโดดไปมาระหว่างที่ผู้ใช้กำลังอ่านหรือแตะ

สิ่งเหล่านี้คือ Core Web Vitals ทั้งสาม: LCP, INP และ CLS

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

เมตริกทั้งสามในประโยคเดียวต่อรายการ

ก่อนลงรายละเอียด นี่คือเวอร์ชันแบบภาษาง่าย ๆ:

• LCP หรือ Largest Contentful Paint วัดว่าเนื้อหาหลักที่มองเห็นได้ใช้เวลานานเท่าใดในการโหลด
• INP หรือ Interaction to Next Paint วัดว่าเพจตอบสนองต่อการโต้ตอบของผู้ใช้ได้เร็วเพียงใดตลอดการเข้าชม
• CLS หรือ Cumulative Layout Shift วัดว่าเพจขยับไปมาอย่างไม่คาดคิดมากเพียงใด

เกณฑ์ทั่วไปคือ:

| Metric | Good | Needs improvement | Poor | |---|---:|---:|---:| | LCP | 2.5s หรือน้อยกว่า | 2.5s–4.0s | มากกว่า 4.0s | | INP | 200ms หรือน้อยกว่า | 200ms–500ms | มากกว่า 500ms | | CLS | 0.1 หรือต่ำกว่า | 0.1–0.25 | มากกว่า 0.25 |

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

หากคุณกำลังจ้องรายงานอัตโนมัติและไม่แน่ใจว่าจะเริ่มตรงไหน การแยกการวินิจฉัยออกจากความตื่นตระหนกจะช่วยได้ เรามีคู่มือแยกต่างหากเกี่ยวกับวิธีอ่านรายงาน Lighthouse โดยไม่ตื่นตระหนก ซึ่งอธิบายเวิร์กโฟลว์นั้นโดยละเอียดกว่า

LCP: เมื่อใดที่เพจรู้สึกว่าโหลดแล้ว?

Largest Contentful Paint วัดเวลา render ขององค์ประกอบเนื้อหาที่มองเห็นได้ซึ่งใหญ่ที่สุดใน viewport ในทางปฏิบัติ มักเป็น:

• hero image,
• heading ขนาดใหญ่,
• รูปภาพบทความเด่น,
• รูปภาพสินค้า,
• บล็อกข้อความขนาดใหญ่

LCP ไม่ได้ถามว่า script, tracking pixel และรูปภาพ below-the-fold ทุกชิ้นโหลดเสร็จเมื่อใด แต่มันถามว่า: สิ่งหลักที่ผู้ใช้เข้ามาดูปรากฏให้เห็นเมื่อใด?

สิ่งนี้ทำให้ LCP เป็นเมตริกที่ใกล้กับประสบการณ์มนุษย์มากกว่า “page load time” แบบเก่า เพจหนึ่งอาจโหลดเสร็จในเชิงเทคนิคช้า แต่ยังรู้สึกเร็วได้หากเนื้อหาหลักปรากฏอย่างรวดเร็ว ในทางกลับกันก็จริงเช่นกัน: เพจอาจยิง load event แล้ว ในขณะที่พื้นที่ hero ยังว่าง เบลอ หรือถูกหน่วงด้วย render delay

สาเหตุทั่วไปของ LCP ที่แย่

ปัญหา LCP ที่ไม่ดีส่วนใหญ่มาจากจุดที่คาดเดาได้ไม่กี่อย่าง:

1. การตอบสนองของเซิร์ฟเวอร์ช้า

หากเอกสาร HTML มาถึงช้า ทุกอย่างที่เหลือก็เริ่มช้า

1. CSS หรือ JavaScript ที่ขวางการ render

เบราว์เซอร์มีเนื้อหาแล้ว แต่ยัง paint ไม่ได้

1. hero images ที่ไม่ได้ปรับให้เหมาะสม

องค์ประกอบที่ใหญ่ที่สุดมีขนาดใหญ่เกินไป อยู่ในฟอร์แมตที่ไม่เหมาะสม ไม่ถูกจัดลำดับความสำคัญ หรือถูกโหลดแบบ lazy-load โดยผิดพลาด

1. Web fonts ทำให้การ render ข้อความล่าช้า

heading ขนาดใหญ่อาจเป็นองค์ประกอบ LCP และการโหลดฟอนต์อาจหน่วงหรือเปลี่ยนรูปลักษณ์ของมัน

1. ความล่าช้าจาก client-side rendering

หากเพจต้องใช้ JavaScript bundle ขนาดใหญ่ก่อนจะแสดงเนื้อหาที่มีความหมายได้ LCP จะได้รับผลกระทบ

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

เริ่มจากองค์ประกอบ LCP จริง อย่าปรับแต่ง asset แบบสุ่มจนกว่าคุณจะรู้ว่าเบราว์เซอร์กำลังวัดอะไร

แนวทางแก้ไขเชิงปฏิบัติ ได้แก่:

• ส่ง HTML ให้เร็ว: ใช้ cache เมื่อเหมาะสม ลดงานฝั่ง backend หลีกเลี่ยง redirect ที่ช้า
• ปรับรูปภาพ LCP ให้เหมาะสม: ใช้มิติ การบีบอัด และฟอร์แมตที่เหมาะสม
• อย่า lazy-load hero image ที่อยู่ above-the-fold
• ใช้ fetchpriority="high" อย่างระมัดระวังสำหรับรูปภาพหลักเมื่อมันเป็นลำดับความสำคัญจริง ๆ
• Inline critical CSS เฉพาะเมื่อช่วยลด render delay ได้อย่างมีนัยสำคัญ
• ลด JavaScript ที่จำเป็นก่อน first meaningful render
• ใช้ font-display: swap หรือกลยุทธ์ฟอนต์อื่นที่ตั้งใจไว้

รูปภาพและฟอนต์เป็นผู้ร้ายที่พบบ่อย สำหรับรูปภาพ การแลกเปลี่ยนไม่ได้มีแค่ “ไฟล์เล็กคือดี” การเลือกฟอร์แมต ความพยายามในการเข้ารหัส และการรองรับของเบราว์เซอร์ล้วนสำคัญ นั่นคือเหตุผลที่เรามี decision tree เชิงปฏิบัติสำหรับ เมื่อใดที่ AVIF เหนือกว่า WebP และเมื่อใดที่ไม่ใช่ สำหรับเพจที่เน้นตัวอักษร web fonts ยังคงเป็นหนึ่งในชัยชนะด้าน performance ที่ง่ายที่สุด เพราะหลายไซต์ส่งไฟล์ฟอนต์มากกว่าที่ใช้งานจริง

INP: เพจตอบสนองเมื่อถูกแตะหรือไม่?

Interaction to Next Paint วัดความตอบสนอง กล่าวให้เฉพาะเจาะจงขึ้นคือ มันดูความหน่วงระหว่างการโต้ตอบของผู้ใช้กับการอัปเดตภาพครั้งถัดไปหลังจากเบราว์เซอร์ประมวลผลการโต้ตอบนั้นแล้ว

การโต้ตอบรวมถึงสิ่งต่าง ๆ เช่น:

• คลิกปุ่ม,
• แตะเมนู,
• เลือก checkbox,
• พิมพ์ในช่องฟอร์ม,
• เปิด accordion

INP เข้ามาแทน First Input Delay ในฐานะ Core Web Vital ในปี 2024 นั่นเป็นการเปลี่ยนแปลงที่ดี First Input Delay ดูเฉพาะการโต้ตอบครั้งแรกเท่านั้น INP กว้างกว่า: มันพิจารณาการโต้ตอบตลอดการเข้าชมเพจ และรายงานการโต้ตอบที่มี latency สูงเป็นคะแนนความตอบสนองของเพจ

พูดง่าย ๆ: INP จับเพจที่ดูเหมือนโหลดแล้ว แต่รู้สึกค้าง

คุณน่าจะเคยใช้เพจแบบนี้ มันดูพร้อมใช้งาน คุณแตะเมนู ไม่มีอะไรเกิดขึ้นครึ่งวินาที คุณแตะอีกครั้ง จากนั้นสองอย่างเกิดขึ้นพร้อมกัน นั่นคือปัญหา INP

สาเหตุทั่วไปของ INP ที่แย่

INP มักเป็นปัญหา main-thread เบราว์เซอร์ต้องการตอบสนอง แต่ JavaScript งาน rendering หรือการคำนวณ layout ขวางอยู่

สาเหตุทั่วไป ได้แก่:

• JavaScript bundles ขนาดใหญ่,
• event handlers ที่มีต้นทุนสูง,
• งาน hydration บนแอปที่ render ฝั่ง client,
• third-party scripts ที่แย่ง main thread,
• งานที่รันนานหลัง page load,
• การอัปเดต DOM ที่ซับซ้อนซึ่งถูกกระตุ้นจากการโต้ตอบเล็ก ๆ,
• layout thrashing ซึ่ง code อ่านและเขียนค่า layout ซ้ำไปมา

Marketing tags, analytics, chat widgets และ consent banners ล้วนมีส่วนได้ นี่ไม่ได้หมายความว่า “ลบทุกอย่าง” แต่หมายความว่า script ทุกตัวบนเพจมีต้นทุน และ interaction latency คือจุดที่ต้นทุนนั้นมักปรากฏให้เห็น

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

การปรับปรุง INP ไม่ได้เกี่ยวกับ attribute วิเศษเพียงตัวเดียว แต่เกี่ยวกับการลดการแย่งชิง main thread

แนวทางที่มีประโยชน์ ได้แก่:

• แบ่งงาน JavaScript ที่ยาวออกเป็นชิ้นเล็กลง
• เลื่อนงานที่ไม่จำเป็นออกไปจนกว่าเพจจะใช้งานได้
• ลบ JavaScript ที่ไม่ได้ใช้ แทนที่จะเพียง minify มัน
• ทำให้ event handlers เล็กและคาดเดาได้
• หลีกเลี่ยงการ re-render ส่วนใหญ่ของอินเทอร์เฟซเพราะการเปลี่ยน state เล็กน้อย
• ใช้ CSS สำหรับสถานะภาพที่เรียบง่ายเมื่อเป็นไปได้
• ตรวจสอบ third-party scripts และโหลดเฉพาะในที่ที่จำเป็น

ควรดู interaction design ด้วย ปุ่มที่ให้ visual feedback ทันทีอาจรู้สึกตอบสนองกว่า แม้งานถัดไปจะใช้เวลานานกว่า นั่นไม่ใช่สิ่งทดแทน performance แต่เป็นส่วนหนึ่งของวิศวกรรมอินเทอร์เฟซที่ดี checklist ของเราสำหรับ ปุ่มเว็บที่ accessible มีส่วนที่ทับซ้อนกับเรื่องนี้: สถานะที่ชัดเจน semantics ที่ถูกต้อง และพฤติกรรมที่คาดเดาได้ช่วยทั้งผู้ใช้และเบราว์เซอร์

CLS: เพจอยู่ในตำแหน่งที่ผู้ใช้คาดหวังหรือไม่?

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

CLS ไม่ได้วัดเป็นวินาที แต่มันเป็นคะแนนตามปริมาณเนื้อหาที่ขยับและระยะที่ขยับ ยิ่งต่ำยิ่งดี

คำสำคัญคือ ไม่คาดคิด การเปลี่ยน layout ที่เกิดจากการกระทำของผู้ใช้มักไม่ถูกนับในลักษณะเดียวกัน หากมีคนแตะ “แสดงเพิ่มเติม” แล้วเนื้อหาขยาย นั่นเป็นสิ่งที่คาดได้ หาก newsletter banner ปรากฏด้านบนหลังผ่านไปสามวินาทีและดันทุกอย่างลง นั่นไม่ใช่

สาเหตุทั่วไปของ CLS ที่แย่

ความล้มเหลวของ CLS มักเป็นเรื่องธรรมดา:

• รูปภาพที่ไม่มี attributes width และ height,
• โฆษณาหรือ embeds ที่ไม่มีพื้นที่สำรอง,
• cookie banners ที่ถูกแทรกเหนือเนื้อหา,
• web fonts ที่สลับเข้ามาพร้อม metrics ที่ต่างกัน,
• promotional bars ที่โหลดช้า,
• เนื้อหาที่ถูก inject แบบ dynamic ใกล้ด้านบนของเพจ

การแก้ไขมักคือการสำรองพื้นที่ก่อนที่เนื้อหาจะมาถึง เบราว์เซอร์ควรรู้รูปร่างของเพจให้เร็วที่สุด

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

เริ่มจากการขยับที่มองเห็นได้ ดู recording หรือใช้เครื่องมือของเบราว์เซอร์เพื่อระบุว่าองค์ประกอบใดขยับ

จากนั้นใช้วิธีแก้ไขพื้นฐานเหล่านี้:

• เพิ่ม attributes width และ height ที่ชัดเจนให้รูปภาพ
• ใช้ CSS aspect-ratio สำหรับ responsive media containers
• สำรองพื้นที่แบบ fixed หรือ minimum สำหรับโฆษณา embeds และ iframes
• หลีกเลี่ยงการ inject banners เหนือเนื้อหาที่มีอยู่หลังโหลด
• เลือก font fallbacks ที่มี metrics ใกล้เคียงกับฟอนต์สุดท้าย
• หลีกเลี่ยง animations ที่เปลี่ยน layout properties เช่น top, left, width หรือ height; ควรใช้ transforms

CLS เป็นหนึ่งในเมตริก performance ไม่กี่ตัวที่วินัยชนะความชาญฉลาด หากเพจมีกล่องที่เสถียร มันมักได้คะแนนดี

Field data และ lab data ต่างก็มีประโยชน์ แต่ตอบคำถามคนละแบบ

แหล่งความสับสนที่พบบ่อยคือเครื่องมือต่างกันแสดงตัวเลขต่างกัน นั่นเป็นเรื่องปกติ

Field data มาจากผู้ใช้จริง สะท้อนอุปกรณ์ เครือข่าย ตำแหน่งที่ตั้ง และสภาพเบราว์เซอร์จริง Google’s Chrome User Experience Report เป็นตัวอย่างของ field data

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

ใช้ field data เพื่อตัดสินว่าผู้ใช้มีปัญหาจริงหรือไม่ ใช้ lab data เพื่อจำลองและ debug ปัญหานั้น

อย่าลืมด้วยว่า Core Web Vitals มักถูกประเมินต่อ URL หรือกลุ่ม URL ไม่ใช่ในฐานะคุณสมบัตินามธรรมเดียวของแบรนด์คุณ หน้า home page, บทความบล็อก, pricing page และ checkout อาจมี bottlenecks ที่ต่างกันมาก

ลำดับงานที่สมเหตุสมผล

หากเมตริกทั้งสามแย่ทั้งหมด สิ่งล่อใจคือเริ่มทำทุกที่ จงต้านไว้

ลำดับที่ปฏิบัติได้คือ:

1. แก้ CLS ที่เห็นชัดก่อน

มิติรูปภาพที่ขาดหายและแบนเนอร์ที่ไม่เสถียรมักเป็น quick wins

1. ปรับปรุง LCP สำหรับ templates สำคัญ

โฟกัสเพจที่สำคัญ: product pages, landing pages, articles, sign-up flows

1. ตรวจสอบ INP ด้วยการโต้ตอบจริง

คลิกสิ่งที่ผู้ใช้คลิกจริง เมนู filters ฟอร์ม และ checkout controls มักเปิดเผยมากกว่า trace การโหลดเริ่มต้น

1. ตรวจสอบ third-party scripts

เก็บตัวที่คุ้มกับต้นทุนไว้ ลบหรือเลื่อนตัวที่ไม่คุ้ม

1. ตั้ง performance budget

หากไม่มี budget การปรับปรุง performance จะเสื่อมลง script รูปภาพ และ design components ใหม่จะค่อย ๆ ทำให้งานที่ทำไว้หายไปโดยไม่รู้ตัว

ประเด็นสำคัญ: อย่าปรับแต่งเพื่อ badge จงปรับเพื่อ user journey การปรับคะแนนเล็กน้อยบนเพจที่มี traffic ต่ำอาจสำคัญน้อยกว่าการโต้ตอบ checkout ที่ยังไม่สมบูรณ์แบบแต่เร็วขึ้นมาก

<!-- tool-cta:start -->

💡 ลองทำสิ่งนี้: เนื่องจาก LCP มักเป็นปัญหาเกี่ยวกับรูปภาพ ให้ย่อขนาด hero asset ของคุณด้วย Image Compressor เพื่อเป็นชัยชนะง่าย ๆ อย่างแรก

<!-- tool-cta:end -->

สิ่งที่ Core Web Vitals ไม่ได้บอกคุณ

Core Web Vitals มีประโยชน์ แต่ไม่ครบถ้วน

มันไม่ได้บอกว่าเนื้อหาของคุณดีหรือไม่ ไม่ได้บอกว่า navigation ของคุณสมเหตุสมผลหรือไม่ ไม่ได้รับประกัน accessibility ไม่ได้วัด privacy, security, trust, readability หรือว่าเพจตอบคำถามของผู้ใช้หรือไม่

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

ปฏิบัติต่อ LCP, INP และ CLS เหมือนสัญญาณเตือนควัน เมื่อมันดัง ให้ตรวจสอบ เมื่อมันเงียบ ให้ดูแลอาคารต่อไป