ถ้าเคยเอาเว็บไปใส่ใน PageSpeed Insights คุณคงเจอวงกลมสีเขียวหรือสีส้มพร้อมตัวเลขหนึ่งตัว คนมักจำแต่ตัวเลขนั้น แต่มันเป็นส่วนที่เล่าเรื่องได้น้อยที่สุดในหน้า
บทความนี้อธิบายสามตัววัดที่ Google เรียกว่า Core Web Vitals ว่าวัดอะไร ค่าเท่าไรถึงถือว่าดี และต่างจากคะแนนรวมอย่างไร โดยใช้ตัวเลขจริงจากเว็บของเราเองที่วัดเมื่อวันที่ 15 ตุลาคม 2569
สามตัววัดที่ต้องรู้จัก
Core Web Vitals คือสามตัววัดที่อธิบายประสบการณ์ของคนที่เปิดหน้าเว็บ แต่ละตัวตอบคำถามเดียว
LCP: เนื้อหาหลักขึ้นมาเมื่อไหร่
Largest Contentful Paint คือเวลาที่ส่วนใหญ่ที่สุดของหน้า มักเป็นภาพหลักหรือหัวข้อใหญ่ แสดงผลเสร็จ ถือว่าดีเมื่อไม่เกิน 2.5 วินาที และแย่เมื่อเกิน 4 วินาที
INP: กดแล้วหน้าตอบสนองเร็วแค่ไหน
Interaction to Next Paint วัดว่ากดปุ่ม แตะ หรือพิมพ์แล้วต้องรอนานแค่ไหนกว่าหน้าจะเปลี่ยนให้เห็น ถือว่าดีเมื่อไม่เกิน 200 มิลลิวินาที และแย่เมื่อเกิน 500 มิลลิวินาที ตัวนี้เข้ามาแทน FID ในเดือนมีนาคม 2024
CLS: หน้าเลื่อนหนีนิ้วหรือเปล่า
Cumulative Layout Shift วัดว่าองค์ประกอบกระโดดไปมาระหว่างโหลดมากแค่ไหน เช่น ภาพที่ไม่ได้กำหนดขนาดดันข้อความลงไปจนกดผิดปุ่ม ถือว่าดีเมื่อไม่เกิน 0.1 และแย่เมื่อเกิน 0.25 ตัวนี้ไม่มีหน่วย
ข้อมูลจากผู้ใช้จริงกับการวัดในแล็บ
PageSpeed Insights แสดงข้อมูลสองชุดในหน้าเดียวกัน และมันเป็นคนละอย่าง
ชุดแรกคือข้อมูลภาคสนาม (field data) มาจาก Chrome ของผู้เข้าชมจริงในช่วง 28 วันที่ผ่านมา ค่าที่ใช้ตัดสินคือเปอร์เซ็นไทล์ที่ 75 ของการเข้าชม คือสามในสี่ของครั้งที่คนเข้ามาต้องได้ประสบการณ์ระดับดีขึ้นไปถึงจะผ่าน เว็บที่คนเข้าน้อยอาจไม่มีข้อมูลชุดนี้เลย
ชุดที่สองคือการวัดในแล็บ (lab data) Lighthouse โหลดหน้าหนึ่งครั้งบนเครื่องจำลองที่ถูกจำกัดความเร็ว แล้วให้คะแนน มันดีสำหรับหาสาเหตุ เพราะทำซ้ำได้และบอกว่าอะไรช้า แต่ไม่ใช่ผู้ใช้จริง และ INP วัดในแล็บไม่ได้ เพราะไม่มีใครกดอะไร จึงใช้ตัวแทนที่เรียกว่า Total Blocking Time แทน
เว็บเดียวกัน คะแนนไม่เท่ากัน
เมื่อวันที่ 15 ตุลาคม 2569 เรารัน Lighthouse 13.5 กับหน้าแรกของเว็บนี้ รวมหกรอบในเวลาไม่ถึงสองนาที สามรอบบนเดสก์ท็อปได้ 74, 79 และ 83 สามรอบบนมือถือได้ 84, 86 และ 90 หน้าเดียวกัน โค้ดเดียวกัน
ความแกว่งนี้ไม่ใช่ข้อผิดพลาด การจำลองเครือข่ายและ CPU ในแต่ละรอบไม่เหมือนกันเป๊ะ และเมื่อ LCP อยู่ใกล้เส้นแบ่ง มันก็ข้ามไปมาได้ ผลคือคนที่เอาคะแนนรอบเดียวมาอ้างอาจได้ทั้งตัวเลขที่ดีกว่าและแย่กว่าความจริง
ต้องบอกให้ครบด้วย ในหกรอบนั้น LCP บนมือถือในแล็บอยู่ที่ 2.8 ถึง 3.8 วินาที ซึ่งยังไม่ถึงเป้า 2.5 วินาทีที่เราตั้งไว้ ส่วนบนเดสก์ท็อปอยู่ที่ 1.8 ถึง 2.5 วินาที เรารู้ว่าสิ่งที่อาจช่วยมือถือได้คือบันเดิล JavaScript ที่เล็กลง
อ่านผลอย่างไรให้ได้ประโยชน์
ดูข้อมูลภาคสนามก่อน ถ้ามี มันคือสิ่งที่คนจริงเห็น และคือสิ่งที่ Google ใช้
ถ้ามีแต่ผลแล็บ ให้รันอย่างน้อยสามรอบ แล้วดูช่วงของคะแนน ไม่ใช่ตัวเลขเดียว
เปิดส่วนวินิจฉัย ดูว่าองค์ประกอบ LCP คืออะไร ภาพหลักหรือหัวข้อ และอะไรทำให้มันมาช้า
ดู CLS ว่าอะไรกระโดด ภาพที่ไม่มีขนาด ฟอนต์ที่มาช้า หรือแบนเนอร์ที่แทรกเข้ามาทีหลัง
อย่าไล่คะแนนเป็นเป้า ไล่สิ่งที่ผู้ใช้รู้สึก คะแนนจะตามมาเอง
ถามอะไรเมื่อมีคนบอกคะแนนมา
เป็นข้อมูลภาคสนามหรือผลในแล็บ
มือถือหรือเดสก์ท็อป และจำลองเครือข่ายแบบไหน
หน้าไหน และรันกี่รอบ
LCP ของหน้านั้นคือองค์ประกอบอะไร
ถ้าคนที่บอกคะแนนมาตอบสี่ข้อนี้ไม่ได้ ตัวเลขนั้นก็ยังไม่ใช่ข้อมูล
