วิธีอ่านรายงาน PageSpeed Insights (และคะแนนหมายถึงอะไรจริง ๆ)

มีคนนำหน้าแรกของคุณไปทดสอบใน PageSpeed Insights แล้วส่งภาพหน้าจอมาให้ เป็นเลข 41 สีแดงบนมือถือ ตอนนี้เว็บไซต์ของคุณเลยถูกตั้งคำถาม และอาจมีใบเสนอราคาแนบมาด้วยว่าจะ “ทำให้ได้ 90”

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

คำตอบสั้น ๆ

• รายงานรวมข้อมูล 2 แบบ: ข้อมูลภาคสนาม (field data) จากผู้ใช้ Chrome จริงในช่วง 28 วันที่ผ่านมา ตามด้วยการทดสอบในแล็บด้วย Lighthouse ที่ให้คะแนนตั้งแต่ 0 ถึง 100
• ตัดสินหน้าเว็บจากข้อมูลภาคสนาม ถ้าผลประเมิน Core Web Vitals บอกว่า “Passed” แปลว่าผู้เข้าชมจริงส่วนใหญ่ได้รับประสบการณ์ที่ดี ไม่ว่าคะแนนแล็บจะเป็นเท่าไร
• ใช้คะแนนแล็บเพื่อวินิจฉัย ไม่ใช่เป็นเป้าหมาย การไล่ตามคะแนน 100 แทบไม่เปลี่ยนอะไรที่ผู้เข้าชมสังเกตได้
• คะแนนมือถือต่ำกว่าโดยตั้งใจ เพราะการทดสอบในแล็บจำลองมือถือระดับกลางที่ใช้การเชื่อมต่อช้า
• คะแนนต่างกันในแต่ละครั้งที่รัน จึงควรทดสอบหลายครั้ง แล้วใช้ผลที่อยู่ตรงกลาง

Field data กับ lab data: สองส่วนของรายงาน

รายงานจะเปิดที่แท็บ Mobile โดยมีแท็บ Desktop อยู่ข้าง ๆ ทั้งสองแท็บมี 2 ส่วนเหมือนกัน:

เมื่อสองส่วนนี้ขัดกัน ให้ยึดข้อมูลภาคสนาม เพราะเป็นสิ่งที่ผู้เข้าชมเจอจริง และข้อมูล CrUX ชุดเดียวกันนี้ ก็ใช้ในรายงาน Core Web Vitals ของ Search Console ด้วย

อ่านข้อมูลภาคสนาม

ผลประเมิน Core Web Vitals

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

ค่าที่อยู่ระหว่างนั้นถูกจัดว่า “ต้องปรับปรุง” (needs improvement) และตาม เอกสาร PageSpeed Insights ของ Google หน้าที่มีข้อมูล INP ไม่พอจะถูกประเมินจาก LCP และ CLS เท่านั้น นอกจากนี้ ยังมี First Contentful Paint หรือ FCP และ TTFB (เวลาจนได้รับไบต์แรกจากเซิร์ฟเวอร์) แสดงอยู่ด้วย สองค่านี้ไม่ใช่ Core Web Vitals แต่ถ้า TTFB ช้า ให้สงสัยเซิร์ฟเวอร์ก่อน รายละเอียดของค่าวัดแต่ละตัวและสาเหตุที่พบบ่อย ดูได้ที่ อธิบาย Core Web Vitals แบบเข้าใจง่าย

แถบสี เปอร์เซ็นไทล์ที่ 75 และปุ่มสลับ origin

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

ปุ่มสลับใช้เปลี่ยนระหว่าง URL นี้กับ origin (ทุกหน้าในเว็บไซต์รวมกัน) หน้าแรกที่เบาอาจผ่าน ขณะที่หน้าที่หนักกว่าดึงค่าของ origin ลง จึงควรตรวจทั้งสองแบบ

ข้อมูลภาคสนามมีข้อจำกัด คือครอบคลุมแค่ Chrome บนเดสก์ท็อปและ Android ของผู้ใช้ที่แชร์สถิติการใช้งาน การเข้าชมจาก iPhone, Safari และ Firefox จึงไม่ถูกนับ ข้อมูลเปลี่ยนช้า และบอกได้แค่ว่ามีอะไรช้า แต่ไม่บอกว่าทำไม

อ่านข้อมูลแล็บ และคะแนน Performance

คะแนน Performance ของ Lighthouse คิดอย่างไร

ส่วนล่างที่มีหัวข้อ “Diagnose performance issues” คือการทดสอบด้วย Lighthouse ซึ่งโหลดหน้าเว็บหนึ่งครั้ง ให้คะแนนค่าวัด 5 ตัว โดยเทียบกับข้อมูลจากเว็บไซต์จริง แล้วรวมกันด้วยน้ำหนักที่กำหนดไว้ตายตัว ตั้งแต่ Lighthouse 10 เป็นต้นมา Total Blocking Time หรือ TBT มีน้ำหนัก 30% ส่วน LCP และ CLS ตัวละ 25% และ FCP กับ Speed Index ตัวละ 10%

คะแนน 0–49 คือแย่ (สีแดง) 50–89 คือต้องปรับปรุง (สีส้ม) และ 90–100 คือดี (สีเขียว) ยิ่งใกล้คะแนนเต็ม คะแนนยิ่งขยับยาก เอกสาร Lighthouse ของ Google ระบุว่าการขยับจาก 99 เป็น 100 ต้องปรับค่าวัดให้ดีขึ้นพอ ๆ กับการขยับจาก 90 เป็น 94 การยกคะแนนหน้าสำคัญจาก 35 เป็น 75 มักคุ้มค่า แต่จาก 92 เป็น 100 แทบไม่คุ้ม

ทำไม TBT จึงใช้แทน INP

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

Treemap และคะแนนอื่น ๆ

ปุ่ม View Treemap แสดง JavaScript ของหน้าเว็บทีละไฟล์ รวมถึงส่วนที่ไม่ได้ใช้ ซึ่งมักเป็นสัญญาณแรกว่ามีปลั๊กอินที่โหลดโค้ดของตัวเองในทุกหน้า

คะแนน Accessibility, Best Practices และ SEO คือการตรวจพื้นฐานแบบอัตโนมัติ คะแนน SEO เต็ม ไม่ได้แปลว่าหน้าเว็บติดอันดับ และการตรวจการเข้าถึงแบบอัตโนมัติ จับอุปสรรคได้แค่บางส่วน ตามที่บทความ การตรวจการเข้าถึง และเครื่องมือตรวจอัตโนมัติ ของเราอธิบายไว้

ทำไมคะแนน PageSpeed บนมือถือจึงต่ำกว่า

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

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

ดังนั้น ให้เทียบผลแล็บบนมือถือ กับข้อมูลภาคสนามบนมือถือ:

• ข้อมูลภาคสนามผ่าน แต่คะแนนแล็บต่ำ: ผู้เข้าชมจริงส่วนใหญ่ไม่มีปัญหา ให้มองรายการจากแล็บเป็นการเตรียมพร้อมสำหรับอนาคต ไม่ใช่เรื่องฉุกเฉิน
• ข้อมูลภาคสนามก็ไม่ผ่าน: งานที่ต้องทำอยู่บนมือถือ และรายการจากแล็บบอกว่าควรเริ่มตรงไหน
• ไม่มีข้อมูลภาคสนาม: ผลจากแล็บคือหลักฐานที่ดีที่สุดในตอนนี้ (ดูหัวข้อเรื่องหน้าที่มีทราฟฟิกน้อยด้านล่าง)

ทำไมคะแนนเปลี่ยนทุกครั้งที่รัน

หน้าเดียวกัน อาจได้คะแนนต่างกันทุกครั้งที่รัน เพราะ:

• การตอบสนองของเซิร์ฟเวอร์ไม่คงที่ โดยเฉพาะบนโฮสติ้งแบบแชร์ที่มีคนใช้เยอะ หรือหลังล้างแคชใหม่ ๆ
• เนื้อหาจากบุคคลที่สามเปลี่ยนไป โฆษณา A/B test วิดเจ็ตแชต และ tag manager อาจโหลดสิ่งที่ต่างกันในแต่ละครั้ง
• เงื่อนไขการทดสอบต่างกัน เครื่องที่ใช้ทดสอบ และเส้นทางเครือข่ายไปยังเซิร์ฟเวอร์ของคุณ ต่างกันเล็กน้อยทุกครั้ง
• Lighthouse เองก็เปลี่ยน รายงานระบุว่าใช้เวอร์ชันไหน และเวอร์ชันใหม่อาจเปลี่ยนสิ่งที่วัด คะแนนเก่าจึงอาจเทียบกันไม่ได้

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

ควรแก้คำแนะนำไหนของ PageSpeed Insights ก่อน

ใต้คะแนนจะเป็นรายการสิ่งที่ตรวจพบ ณ เวลาที่เขียน (กันยายน 2026) PageSpeed Insights จัดกลุ่มเป็น Insights และ Diagnostics ส่วนรายงานและคู่มือรุ่นเก่า เรียกกลุ่มแรกว่า Opportunities แต่ละรายการชี้ไปที่สาเหตุ ซึ่งมักมีการประเมินเวลาที่จะประหยัดได้ด้วย

เริ่มจากค่าวัดที่ไม่ผ่าน

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

หาองค์ประกอบ LCP และดูว่าเวลาหมดไปกับอะไร

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

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

จัดลำดับที่เหลือ ตามขนาด ขอบเขต และการควบคุม

• ประหยัดได้มากแค่ไหน? ตัวเลขประเมินเป็นแค่ค่าคร่าว ๆ แต่ให้แก้เรื่องที่ประหยัดได้เป็นวินาที ก่อนเรื่องที่ประหยัดได้เป็นมิลลิวินาที
• มีกี่หน้าที่มีสาเหตุเดียวกัน? การแก้ที่ธีม ปลั๊กอิน หรือโฮสติ้ง ช่วยทุกหน้าพร้อมกัน
• คุณควบคุมได้ไหม? ไฟล์ของคุณเอง คุณเปลี่ยนได้ แต่วิดเจ็ตจากบุคคลที่สาม คุณทำได้แค่เก็บไว้ หน่วงการโหลด หรือเอาออก บทความ สคริปต์ภายนอกกับความเร็วเว็บไซต์ ของเรา ช่วยตัดสินใจเรื่องนี้

สิ่งที่มักปล่อยไว้ได้ คือรายการที่ประหยัดได้นิดเดียว คำเตือนเรื่องแคชของไฟล์ที่คนอื่นโฮสต์ (เช่น แผนที่ หรือวิดีโอที่ฝังไว้) และคะแนนไม่กี่คะแนนสุดท้ายก่อนถึง 100

จากนั้นแก้ไข ทดสอบใหม่ และรอให้ข้อมูลภาคสนามยืนยัน ถ้ารายการยังชี้ไปที่ธีม page builder หรือโฮสติ้งซ้ำ ๆ บทความ หาสาเหตุว่าทำไมเว็บไซต์ช้า ของเรา ปิดท้ายด้วยวิธีตัดสินใจว่าจะปรับแต่งของเดิมหรือสร้างใหม่

เมื่อหน้าเว็บมีทราฟฟิกไม่พอสำหรับข้อมูลภาคสนาม

เว็บไซต์ใหม่ หน้า B2B เฉพาะกลุ่ม และบทความแต่ละหน้าจำนวนมาก จะแสดงข้อความว่า Chrome UX Report มีข้อมูลจากโลกจริงไม่พอ นี่ไม่ใช่ข้อผิดพลาด คุณแค่ต้องใช้หลักฐานอื่น:

1. เปลี่ยนไปดูข้อมูล origin ทั้งเว็บไซต์อาจมีทราฟฟิกพอ แม้หน้านั้นจะไม่พอ
2. ตรวจ Search Console รายงาน Core Web Vitals ของ Search Console จัดกลุ่ม URL ที่คล้ายกัน หน้าที่คนเข้าน้อย จึงอาจปรากฏเป็นส่วนหนึ่งของกลุ่ม
3. ทดสอบเทมเพลต ไม่ต้องทุกหน้า ติดตามหน้าหนึ่งหน้าของแต่ละประเภท (หน้าแรก หน้าบริการ บทความ แลนดิ้งเพจ) ไปตามเวลา
4. ลองบนมือถือจริง โหลดหน้าสำคัญบนมือถือระดับกลาง ผ่านเน็ตมือถือ
5. เก็บข้อมูลภาคสนามเอง ไลบรารี JavaScript โอเพนซอร์สของ Google ชื่อ web-vitals วัด LCP INP และ CLS จากผู้เข้าชมของคุณ และส่งไปยังระบบวิเคราะห์ของคุณได้ (ดูเรื่องเบราว์เซอร์ที่รองรับในเอกสารของไลบรารี)

คู่มือเพิ่มความเร็วเว็บไซต์ ของเรา แสดงว่าการตรวจเหล่านี้เป็นส่วนหนึ่งของแผนที่ครบถ้วนได้อย่างไร

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

ต้องได้คะแนน PageSpeed Insights 100 ไหม?

ไม่ต้อง ตั้งแต่ 90 ขึ้นไป ก็อยู่ในช่วง “ดี” ของ Lighthouse แล้ว การผ่าน Core Web Vitals ในข้อมูลภาคสนาม เป็นเป้าหมายที่ดีกว่าคะแนนแล็บเต็ม ๆ มาก

คะแนน PageSpeed Insights มีผลต่ออันดับ Google ไหม?

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

ทำไมเครื่องมือวัดความเร็วอื่นให้คะแนนต่างกัน?

แต่ละเครื่องมือใช้อุปกรณ์ การเชื่อมต่อ ตำแหน่ง และการตั้งค่าของตัวเอง ส่วน Lighthouse ในเครื่องมือนักพัฒนาของ Chrome ก็รันบนคอมพิวเตอร์ของคุณเอง เลือกใช้เครื่องมือเดียว แล้วเทียบผลของเครื่องมือนั้นในแต่ละช่วงเวลา ไม่ใช่เทียบข้ามเครื่องมือ

ต้องรอนานแค่ไหน กว่าผลการแก้จะขึ้นในรายงาน?

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

ขั้นตอนถัดไป

อ่านรายงาน PageSpeed Insights ตามลำดับ: ข้อมูลภาคสนามก่อน ต่อด้วยค่าวัดในแล็บ แล้วจึงดูการแก้ไขที่ตรงกับสิ่งที่ไม่ผ่านจริง คะแนนคืออาการ ไม่ใช่การวินิจฉัย

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

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