วิธีวัดความเร็วเว็บบน Hosting และตีความผล GTmetrix PageSpeed

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

เครื่องมือวัดความเร็วหลัก

• PageSpeed Insights — ของ Google ให้ทั้ง Lab Data (จำลอง) และ Field Data (CrUX จากผู้ใช้จริง) เหมาะที่สุดเพราะใช้เกณฑ์เดียวกับที่ Google ใช้จัดอันดับ
• GTmetrix — แสดง Waterfall ละเอียดว่าทรัพยากรแต่ละไฟล์โหลดเมื่อไหร่ ช่วยหาไฟล์ที่ถ่วงเวลา และเลือกตำแหน่งทดสอบได้
• WebPageTest — ลึกที่สุด เลือกอุปกรณ์ ความเร็วเน็ต และตำแหน่งได้หลากหลาย เหมาะกับการวิเคราะห์เชิงเทคนิค

แนะนำเริ่มที่ PageSpeed Insights เพื่อดูภาพรวมและ Core Web Vitals แล้วใช้ GTmetrix ดู Waterfall เพื่อหาว่าไฟล์ไหนช้า

ค่าที่ต้องเข้าใจ

ค่า	ความหมาย	เป้าหมาย
LCP (Largest Contentful Paint)	เวลาที่ Element ใหญ่ที่สุดแสดงเสร็จ	< 2.5 วินาที
CLS (Cumulative Layout Shift)	ความเสถียรของ Layout ขณะโหลด	< 0.1
INP (Interaction to Next Paint)	ความตอบสนองเมื่อผู้ใช้คลิก	< 200 มิลลิวินาที
TTFB (Time to First Byte)	เวลาจนได้ Byte แรกจาก Server	< 800 มิลลิวินาที

สามตัวแรก (LCP, CLS, INP) คือ Core Web Vitals ที่ Google ใช้เป็นส่วนหนึ่งของการจัดอันดับ ส่วน TTFB สะท้อนความเร็วของ Server และ Hosting โดยตรง

Lab Data กับ Field Data ต่างกันอย่างไร

จุดที่คนสับสนบ่อยคือเห็นคะแนนใน Lab สวยแต่เว็บจริงยังรู้สึกช้า เพราะสองค่านี้ต่างกัน:

• Lab Data — วัดจากการจำลองในสภาพแวดล้อมควบคุม (อุปกรณ์และเน็ตมาตรฐาน) ใช้ Debug ได้ดีเพราะทำซ้ำได้
• Field Data — เก็บจากผู้ใช้จริงผ่าน Chrome (CrUX) สะท้อนประสบการณ์จริงรวมถึงมือถือรุ่นเก่าและเน็ตช้า — นี่คือค่าที่ Google ใช้จริงในการประเมิน

ถ้า Lab ดีแต่ Field แย่ มักเป็นเพราะผู้ใช้จริงใช้มือถือสเปกต่ำหรือเน็ตช้ากว่าที่จำลอง ควรยึด Field Data เป็นหลักเมื่อมีข้อมูลพอ

อ่าน Waterfall ใน GTmetrix

Waterfall คือกราฟแสดงลำดับและเวลาโหลดของทรัพยากรแต่ละไฟล์ จุดที่ควรสังเกต:

• แถบแรกยาว (TTFB สูง) — Server ตอบช้า อาจเกิดจาก PHP/Database ช้า หรือ Hosting ไกลจากผู้ใช้
• ไฟล์ใหญ่ผิดปกติ — รูปภาพที่ไม่ได้บีบอัดหรือไฟล์ JS/CSS ก้อนใหญ่ที่ถ่วงการโหลด
• Request จำนวนมาก — เรียกไฟล์เยอะเกินไป ควรรวมหรือลดปลั๊กอินที่โหลดสคริปต์ฟุ่มเฟือย
• Render-blocking — CSS/JS ที่บล็อกการแสดงผล ควรเลื่อน (defer) หรือโหลดแบบ async

เว็บช้าเพราะ Hosting หรือเพราะเว็บ

คำถามสำคัญคือต้นเหตุอยู่ที่ไหน ดูได้จากตัวเลข:

• TTFB สูงเสมอ แม้หน้าเรียบง่าย → ชี้ไปที่ Server/Hosting เช่น ทรัพยากรน้อย เพื่อนบ้านบน Shared แย่งทรัพยากร หรือ Server อยู่ไกลผู้ชม
• TTFB ดีแต่ LCP แย่ → ปัญหาฝั่งหน้าเว็บ เช่น รูปใหญ่ ฟอนต์โหลดช้า หรือ JS บล็อกการแสดงผล
• CLS สูง → ปัญหา Layout เช่น รูปไม่กำหนดขนาด หรือโฆษณาแทรกดันเนื้อหา — ไม่เกี่ยวกับ Hosting

สำหรับเว็บไทยที่ผู้ชมอยู่ในไทย การใช้ Hosting ที่ Server อยู่ในไทยและเป็น SSD ช่วยลด TTFB ได้ตรงจุด เพราะระยะทางสั้นและดิสก์เร็ว

ความเข้าใจผิดเรื่องคะแนนความเร็ว

ความเข้าใจผิดที่พบบ่อยที่สุดคือการ ไล่คะแนนให้เต็ม 100 แล้วคิดว่าเว็บเร็วที่สุดแล้ว ความจริงคือคะแนนรวมเป็นเพียงการสรุปจากหลายปัจจัยมาเป็นตัวเลขเดียว เว็บที่ได้ 85 แต่ผ่าน Core Web Vitals ครบอาจให้ประสบการณ์ผู้ใช้ดีกว่าเว็บที่ได้ 95 แต่ค่า LCP จริงในมือถือยังแย่ ควรโฟกัสที่ค่าที่ผู้ใช้สัมผัสจริงมากกว่าตัวเลขสรุป

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

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

ลำดับการแก้ที่แนะนำ

1. ลด TTFB ก่อน — เปิด OPcache, ใช้ Object Cache, เลือก Hosting/Server ที่ใกล้ผู้ชมและเป็น SSD
2. Optimize รูปภาพ — แปลงเป็น WebP, กำหนดขนาด, ใช้ lazy load — มักช่วย LCP มากที่สุด
3. จัดการ CSS/JS — เลื่อนสคริปต์ที่ไม่จำเป็น ลบปลั๊กอินที่โหลดของฟุ่มเฟือย
4. เพิ่ม Cache และ CDN — Page Cache + Browser Cache + CDN สำหรับ Static
5. วัดซ้ำหลังแก้แต่ละขั้น — เปรียบเทียบก่อน-หลังเพื่อยืนยันว่าการแก้ได้ผลจริง

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

คะแนน PageSpeed ต้องได้เท่าไรถึงดี

ไม่มีตัวเลขตายตัวที่ต้องไล่ให้ครบ 100 สิ่งที่สำคัญกว่าคือผ่านเกณฑ์ Core Web Vitals คือ LCP < 2.5 วินาที, CLS < 0.1 และ INP < 200 มิลลิวินาที ซึ่งสะท้อนประสบการณ์ผู้ใช้จริงมากกว่าคะแนนรวม

Lab Data กับ Field Data ต่างกันอย่างไร

Lab Data วัดจากการจำลองในสภาพแวดล้อมควบคุม ใช้ Debug ได้ดี ส่วน Field Data เก็บจากผู้ใช้จริงผ่าน Chrome สะท้อนประสบการณ์จริงรวมมือถือรุ่นเก่าและเน็ตช้า Google ใช้ Field Data เป็นหลักในการประเมิน

TTFB สูงแก้ที่ไหน

TTFB สูงมักมาจากฝั่ง Server เช่น PHP/Database ช้า ทรัพยากรน้อย หรือ Server อยู่ไกลผู้ชม แก้ได้ด้วยการเปิด OPcache ใช้ Object Cache และเลือก Hosting SSD ที่ Server อยู่ใกล้กลุ่มผู้ชม

เว็บช้าเป็นเพราะ Hosting หรือเพราะเว็บ

ดูจากตัวเลข ถ้า TTFB สูงเสมอแม้หน้าเรียบง่ายมักเป็นที่ Hosting/Server แต่ถ้า TTFB ดีแต่ LCP แย่หรือ CLS สูง มักเป็นปัญหาฝั่งหน้าเว็บ เช่น รูปใหญ่หรือ Layout ไม่เสถียร