# Core Web Vitals อ่านอย่างไร โดยไม่ต้องเป็นโปรแกรมเมอร์

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

เขียนโดย Fluke Thammasat · 15 ตุลาคม 2569 · อ่าน 4 นาที

![ภาพแถบสามแถบแทน LCP ที่ดีไม่เกิน 2.5 วินาที INP ที่ดีไม่เกิน 200 มิลลิวินาที และ CLS ที่ดีไม่เกิน 0.1 ช่วงดีเป็นสีน้ำเงิน ช่วงต้องปรับปรุงเป็นสีเทา และช่วงแย่เป็นสีอ่อน](https://notstatic.co/media/m/agSjF8nGzc1H/lg.webp)

ถ้าเคยเอาเว็บไปใส่ใน 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 ตัวนี้ไม่มีหน่วย

![แผนภาพช่วงค่าของ LCP, INP และ CLS แต่ละตัวมีเส้นแบ่งที่ค่า ดี และค่า แย่ LCP ที่ 2.5 และ 4 วินาที INP ที่ 200 และ 500 มิลลิวินาที CLS ที่ 0.1 และ 0.25](https://notstatic.co/media/m/zJguAd9_OebW/lg.webp)
*ช่วงค่าของสามตัววัด แถบสีน้ำเงินคือช่วงที่ถือว่าดี ช่วงถัดไปคือต้องปรับปรุง และช่วงสุดท้ายคือแย่*

## ข้อมูลจากผู้ใช้จริงกับการวัดในแล็บ

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 หน้าเดียวกัน โค้ดเดียวกัน

![แผนภาพสองช่อง ช่องซ้ายคือข้อมูลภาคสนามจาก Chrome ของผู้เข้าชมจริง ย้อนหลัง 28 วัน ตัดสินที่เปอร์เซ็นไทล์ 75 ช่องขวาคือผลในแล็บจาก Lighthouse ที่รันครั้งเดียว พร้อมจุดหกรอบของเว็บเดียวกัน เดสก์ท็อป 74, 79, 83 และมือถือ 84, 86, 90](https://notstatic.co/media/m/PI7HkjwnBgsG/lg.webp)
*ข้อมูลภาคสนามมาจากผู้เข้าชมจริง ส่วนผลในแล็บเป็นการรันครั้งเดียว และคะแนนต่างกันได้ทุกรอบ*

ความแกว่งนี้ไม่ใช่ข้อผิดพลาด การจำลองเครือข่ายและ CPU ในแต่ละรอบไม่เหมือนกันเป๊ะ และเมื่อ LCP อยู่ใกล้เส้นแบ่ง มันก็ข้ามไปมาได้ ผลคือคนที่เอาคะแนนรอบเดียวมาอ้างอาจได้ทั้งตัวเลขที่ดีกว่าและแย่กว่าความจริง

ต้องบอกให้ครบด้วย ในหกรอบนั้น LCP บนมือถือในแล็บอยู่ที่ 2.8 ถึง 3.8 วินาที ซึ่งยังไม่ถึงเป้า 2.5 วินาทีที่เราตั้งไว้ ส่วนบนเดสก์ท็อปอยู่ที่ 1.8 ถึง 2.5 วินาที เรารู้ว่าสิ่งที่อาจช่วยมือถือได้คือบันเดิล JavaScript ที่เล็กลง

## อ่านผลอย่างไรให้ได้ประโยชน์

1. ดูข้อมูลภาคสนามก่อน ถ้ามี มันคือสิ่งที่คนจริงเห็น และคือสิ่งที่ Google ใช้
2. ถ้ามีแต่ผลแล็บ ให้รันอย่างน้อยสามรอบ แล้วดูช่วงของคะแนน ไม่ใช่ตัวเลขเดียว
3. เปิดส่วนวินิจฉัย ดูว่าองค์ประกอบ LCP คืออะไร ภาพหลักหรือหัวข้อ และอะไรทำให้มันมาช้า
4. ดู CLS ว่าอะไรกระโดด ภาพที่ไม่มีขนาด ฟอนต์ที่มาช้า หรือแบนเนอร์ที่แทรกเข้ามาทีหลัง
5. อย่าไล่คะแนนเป็นเป้า ไล่สิ่งที่ผู้ใช้รู้สึก คะแนนจะตามมาเอง

## ถามอะไรเมื่อมีคนบอกคะแนนมา

- เป็นข้อมูลภาคสนามหรือผลในแล็บ
- มือถือหรือเดสก์ท็อป และจำลองเครือข่ายแบบไหน
- หน้าไหน และรันกี่รอบ
- LCP ของหน้านั้นคือองค์ประกอบอะไร

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

## บทความอื่น

- [หน้า 3D ที่คะแนน PageSpeed ตก เพราะเครื่องวัดไม่มี GPU](https://notstatic.co/blog/pagespeed-no-gpu-webgl-worker): บนเครื่องที่มี GPU หน้านี้ลื่นปกติ แต่ในแล็บของ PageSpeed การสร้าง WebGL ด้วยซอฟต์แวร์ใช้เวลาราวหนึ่งวินาที นี่คือวิธีที่เราหาสาเหตุและแก้
- [เว็บเทมเพลตกับเว็บออกแบบเอง ต่างกันตรงไหนที่ลูกค้าตรวจเองได้](https://notstatic.co/blog/template-vs-designed-website): เทมเพลตไม่ได้แย่ และมีงานที่ควรใช้มัน แต่ความต่างตรวจเองได้ในสิบนาทีด้วยหกข้อ ไม่ต้องเชื่อคำของใคร รวมถึงของเรา

## อยากได้เว็บไซต์ที่ออกแบบแบบนี้

เล่าโจทย์ให้เราฟัง แล้วเราจะตอบกลับพร้อมขอบเขตงานและแพ็กเกจที่เหมาะกับคุณ [เริ่มโปรเจกต์](https://notstatic.co/#contact)

---

ที่มา: https://notstatic.co/blog/how-to-read-core-web-vitals
English: https://notstatic.co/en/blog/how-to-read-core-web-vitals