เปิด PageSpeed Insights แล้วเห็นคะแนนมือถือ 58 สีส้ม อย่าเพิ่งสรุปว่าเว็บคุณ “ช้าและ SEO แย่” สิ่งที่ควรดูจริงก่อนคือ ข้อมูลผู้ใช้จริงหรือ Field Data โดยเฉพาะ LCP, INP และ CLS จากนั้นค่อยใช้คะแนน Performance และ Lab Data เพื่อหาสาเหตุว่าต้องแก้ตรงไหน เพราะคะแนน 0–100 เป็นผลจากการทดสอบจำลองเพียงครั้งหนึ่ง ไม่ใช่ภาพทั้งหมดของประสบการณ์ผู้ใช้จริงบนเว็บไซต์คุณ
PageSpeed Insights มีตัวเลขเยอะขนาดนี้ ต้องเริ่มดูตรงไหน?
เวลาเราตรวจเว็บลูกค้าหรือเว็บ WordPress ที่เพิ่งปรับเสร็จ ผมจะไม่เริ่มจากวงกลม Performance Score ด้านล่าง แต่จะเริ่มจากส่วนที่บอกว่า Discover what your real users are experiencing ก่อน เพราะนี่คือข้อมูลจาก Chrome User Experience Report หรือ CrUX ซึ่งสะท้อนประสบการณ์ของผู้ใช้ Chrome จริงในช่วงประมาณ 28 วันที่ผ่านมา
PageSpeed Insights แบ่งข้อมูลหลักออกเป็นสองกลุ่มที่คุณต้องแยกให้ออกตั้งแต่แรก ได้แก่
- Field Data: ข้อมูลจากผู้ใช้งานจริง หลายอุปกรณ์ หลายความเร็วอินเทอร์เน็ต และหลายสภาพแวดล้อม
- Lab Data: ผลทดสอบจาก Lighthouse ภายใต้สภาพแวดล้อมจำลอง ใช้สำหรับค้นหาปัญหาและทดลองแก้เว็บ
สองชุดนี้มีหน้าที่ต่างกัน ดังนั้นกรณี Field Data ดี แต่คะแนน Performance ได้ 65 ไม่ได้แปลว่าเว็บมีปัญหาร้ายแรงเสมอไป และในทางกลับกัน คะแนน Lighthouse 98 ก็ไม่ได้รับประกันว่าลูกค้าจริงจะใช้งานเว็บได้เร็วทุกคน Google เองระบุว่า Lab Data เหมาะกับการวิเคราะห์ปัญหา ส่วน Field Data เหมาะกับการดูประสบการณ์ที่เกิดขึ้นจริง
Core Web Vitals ตัวไหนต้องสนใจจริง?
ถ้าคุณเป็นเจ้าของธุรกิจและไม่อยากจำศัพท์เทคนิคสิบกว่าตัว ให้จำสามตัวนี้ก่อน: LCP, INP และ CLS เพราะนี่คือ Core Web Vitals ชุดปัจจุบันที่ Google ใช้วัดประสบการณ์ด้านการโหลด การตอบสนอง และความนิ่งของหน้าเว็บ
LCP คืออะไร และควรได้เท่าไร?
LCP หรือ Largest Contentful Paint วัดว่าคอนเทนต์หลักขนาดใหญ่ในหน้าจอ เช่น Hero Image หรือหัวข้อใหญ่ ใช้เวลานานแค่ไหนกว่าจะปรากฏให้ผู้ใช้เห็น โดยเป้าหมายระดับ “Good” คือ ไม่เกิน 2.5 วินาที ที่เปอร์เซ็นไทล์ที่ 75 ของการเข้าชม
ตัวอย่างที่เจอบ่อยใน WordPress คือ Banner หน้าแรกเป็นไฟล์ JPEG ขนาด 1.8 MB แล้วยังโหลดผ่าน Slider Plugin อีกชั้น ต่อให้ Hosting ไม่ได้ช้า LCP ก็สามารถพุ่งเกิน 4 วินาทีได้ การแก้ที่ได้ผลจริงอาจเป็นการแปลงภาพเป็น WebP/AVIF ลดขนาดไฟล์ และอย่า Lazy Load รูปที่เป็น LCP
ถ้าปัญหามาจากฟอนต์หรือไฟล์ CSS ด้วย ลองอ่านเรื่อง Web Font ทำเว็บช้าไหม และโหลดฟอนต์ยังไงให้เว็บเร็ว ต่อ เพราะหลายเว็บบีบรูปแล้วแต่ยังช้า เนื่องจาก Browser ต้องรอ CSS หรือ Font ก่อนแสดงส่วนสำคัญของหน้า
INP คืออะไร ทำไมเว็บโหลดเร็วแต่กดยังหน่วง?
INP หรือ Interaction to Next Paint วัดความเร็วในการตอบสนองหลังผู้ใช้กด คลิก หรือแตะองค์ประกอบบนหน้าเว็บ เป้าหมายที่ดีคือ ไม่เกิน 200 มิลลิวินาที ที่เปอร์เซ็นไทล์ที่ 75
นี่คือเหตุผลที่บางเว็บ “เปิดหน้าเร็ว” แต่พอกดเมนู เปิด Popup หรือเลือกสินค้าแล้วรู้สึกหน่วง สาเหตุที่เราเจอบ่อยคือ JavaScript ทำงานหนัก มี Tag ยิงโฆษณาหลายตัว หรือ Plugin หลายตัวแย่ง Main Thread ของ Browser
จุดสำคัญคือ Lighthouse ไม่สามารถวัด INP แบบเดียวกับผู้ใช้จริงได้ เพราะการทดสอบอัตโนมัติไม่มีผู้ใช้มานั่งคลิกเว็บตลอด Session ดังนั้นใน Lab Data จะใช้ Total Blocking Time หรือ TBT เป็นตัวช่วยวิเคราะห์แทน ถ้า Field INP แย่และ TBT สูงมาก คุณควรเริ่มไล่ JavaScript เป็นอันดับต้นๆ
CLS คืออะไร ทำไมหน้าเว็บกระโดดไปมา?
CLS หรือ Cumulative Layout Shift วัดความไม่เสถียรของ Layout เช่น คุณกำลังจะกดปุ่ม “สั่งซื้อ” แต่ภาพด้านบนเพิ่งโหลดแล้วดันปุ่มเลื่อนลงจนกดผิด เป้าหมายระดับ Good คือ CLS ไม่เกิน 0.1
เว็บ WordPress ที่ CLS สูงมักเกิดจากรูปที่ไม่ได้กำหนด width/height, Banner หรือ Embed ที่ไม่มีพื้นที่สำรอง, Font เปลี่ยนหลังโหลดเสร็จ และองค์ประกอบที่ถูกแทรกเข้ามาภายหลัง ปัญหานี้เกี่ยวกับ Conversion โดยตรง เพราะหน้าเว็บที่ขยับเองสร้างความรำคาญและทำให้ผู้ใช้กดผิดได้
Performance Score 0–100 สำคัญแค่ไหน?
คะแนน Performance มีประโยชน์ แต่ผมมองมันเป็น Dashboard สำหรับ Debug ไม่ใช่ KPI ทางธุรกิจ คะแนนตั้งแต่ 90 ขึ้นไปถูกจัดเป็นสีเขียว แต่ Google ก็ระบุชัดว่าคะแนน Lab ที่ดีไม่ได้หมายความว่าประสบการณ์ผู้ใช้จริงจะดีตามไปด้วย
Lighthouse คำนวณคะแนนจากหลาย Metrics แบบถ่วงน้ำหนัก ไม่ได้ดูแค่ว่าเว็บโหลดเสร็จกี่วินาที ตัวอย่างใน Lighthouse 10 ได้แก่ TBT 30%, LCP 25%, CLS 25%, FCP 10% และ Speed Index 10% และน้ำหนักเหล่านี้สามารถเปลี่ยนไปตามเวอร์ชันของ Lighthouse ได้
ดังนั้นการไล่จาก 96 ไป 100 อาจใช้เวลาหลายชั่วโมง แต่แทบไม่มีผลต่อยอดขาย ในขณะที่เว็บอีกหน้าหนึ่งมี LCP 5 วินาทีบนมือถือ ซึ่งกระทบลูกค้าจริงมากกว่า ผมจะเลือกใช้เวลาพัฒนาไปแก้หน้าหลังทันที
FCP, TBT และ Speed Index ต้องดูไหม?
ต้องดู แต่ควรใช้เป็น เบาะแสในการหาสาเหตุ มากกว่าจะตั้งเป้าว่าทุกค่าต้องเป็นสีเขียวทั้งหมด
- FCP – First Contentful Paint: เวลาที่ Browser เริ่มแสดงข้อความหรือภาพแรก ถ้าช้ามากให้สงสัย Server Response, Redirect, CSS และทรัพยากรที่ขวางการ Render
- TBT – Total Blocking Time: เวลาที่ Main Thread ถูกงานหนักบล็อก เหมาะมากสำหรับตามหาปัญหา JavaScript
- Speed Index: บอกว่าพื้นที่ที่ผู้ใช้มองเห็นถูกเติมด้วยเนื้อหาเร็วแค่ไหน
ตัวอย่างเช่น LCP ช้า 4.2 วินาที ถ้า TTFB และ FCP ก็ช้าตามกัน ปัญหาอาจเริ่มตั้งแต่ Server, Cache หรือ CDN แต่ถ้า FCP เร็วแล้ว LCP กระโดดไปช้ามาก ให้หาว่า LCP Element คือรูปไหนและไฟล์นั้นถูกโหลดอย่างไร วิธีคิดแบบนี้เร็วกว่าการเปิดรายการ Opportunities แล้วแก้ทุกบรรทัดจากบนลงล่างมาก
ทำไมทดสอบ PageSpeed หลายครั้งแล้วคะแนนไม่เท่ากัน?
เป็นเรื่องปกติ คุณอาจกดครั้งแรกได้ 72 ครั้งต่อมาได้ 81 เพราะ Lab Test ได้รับผลจาก Network, Server Load, การโหลด Resource ภายนอก, Ads, A/B Test และสภาพแวดล้อมในการทดสอบ คะแนน Lighthouse จึงมีความผันผวนได้
เวลาทำงานจริงผมจึงไม่วัดก่อนแก้หนึ่งครั้งและหลังแก้อีกหนึ่งครั้งแล้วประกาศว่าเว็บเร็วขึ้น 20 คะแนน แต่จะทดสอบหลายรอบ ดูแนวโน้มของ LCP/TBT/CLS และกลับไปดู Field Data หลังมีข้อมูลผู้ใช้สะสมเพียงพอ
หลังแก้ใหญ่ เช่น เปลี่ยน Theme, Hosting หรือระบบ Cache ก็ควรมีรอบตรวจเว็บเป็นประจำตามแนวทางใน Website Maintenance รายเดือนสำหรับ WordPress เพราะ Performance สามารถแย่ลงได้อีกหลังอัปเดต Plugin หรือเพิ่ม Script ใหม่
ควรแก้ PageSpeed ตามลำดับไหนให้คุ้มที่สุด?
ถ้าต้องจัดลำดับงานเพื่อให้ใช้ Budget คุ้ม ผมแนะนำ Workflow แบบนี้แทนการวิ่งไล่คะแนน 100
- อันดับ 1: เปิด Mobile และดู Field Data ว่า Core Web Vitals ผ่านหรือไม่
- อันดับ 2: หา Metric ที่แย่ที่สุดระหว่าง LCP, INP และ CLS
- อันดับ 3: ใช้ Lab Data และ Diagnostics หา Root Cause ของ Metric นั้น
- อันดับ 4: แก้ปัญหาที่กระทบ Template หรือผู้ใช้จำนวนมากก่อน เช่น Hero Image, JavaScript กลางเว็บ, Theme หรือ Font
- อันดับ 5: ทดสอบซ้ำหลายครั้งและเช็กทั้งมือถือกับ Desktop
- อันดับ 6: หลัง Deploy แล้วติดตาม Field Data และรายงาน Core Web Vitals ใน Search Console ต่อ
ถ้ากำลังทำเว็บไซต์ใหม่หรือย้าย Theme อย่ารอจนเปิดเว็บแล้วค่อยตรวจความเร็ว เพราะโครงสร้าง Theme, Page Builder และ Script ที่เลือกตั้งแต่ต้นมีผลสูงมาก การวางแผน Performance ควรอยู่ในขั้นตอนเดียวกับ การ Redesign เว็บโดยไม่ให้อันดับ SEO และลูกค้าหาย
PageSpeed มีผลกับ SEO และยอดขายแค่ไหน?
Core Web Vitals เป็นส่วนหนึ่งของสัญญาณที่ระบบจัดอันดับของ Google ใช้ แต่ เว็บไซต์ที่ได้คะแนน PageSpeed 100 ไม่ได้แปลว่าจะอันดับ 1 เพราะ Google ยังพิจารณาความเกี่ยวข้อง คุณภาพเนื้อหา และสัญญาณอื่นอีกจำนวนมาก Google ระบุด้วยว่าการพยายามทำคะแนนสมบูรณ์แบบเพียงเพื่อ SEO อาจไม่ใช่การใช้เวลาที่คุ้มที่สุด
ในเชิงธุรกิจ เป้าหมายจึงควรเป็น “เว็บเร็วพอให้ลูกค้าใช้งานได้ดี” มากกว่า “เว็บได้ 100 คะแนน” ถ้าปรับ LCP จาก 5 วินาทีเหลือ 2.2 วินาที ทำให้หน้า Landing Page แสดงข้อเสนอเร็วขึ้น นั่นมีคุณค่ามากกว่าการใช้เวลาครึ่งวันเพื่อขยับ Performance จาก 97 เป็น 100
สำหรับเอกสารต้นทาง สามารถอ่านรายละเอียดเพิ่มเติมจาก Google PageSpeed Insights Documentation และเอกสาร Core Web Vitals ของ Google ได้โดยตรง [PageSpeed Insights documentation](https://developers.google.com/speed/docs/insights/v5/about?authuser=2&hl=en&utm_source=chatgpt.com) [Core Web Vitals documentation](https://developers.google.com/search/docs/appearance/core-web-vitals?utm_source=chatgpt.com)
อ้างอิงเพิ่มเติม: web.dev — Web Vitals (Google)
คำถามที่พบบ่อย
PageSpeed Insights ต้องได้ 100 ไหม?
ไม่จำเป็น คะแนน 90 ขึ้นไปถือว่าอยู่ในกลุ่มสีเขียวสำหรับ Lab Performance แล้ว และการพยายามไล่ให้ได้ 100 อาจไม่คุ้มเวลา ให้ให้ความสำคัญกับ Core Web Vitals ของผู้ใช้จริงและปัญหาที่มีผลต่อ UX หรือ Conversion มากกว่า
ควรดูคะแนน Mobile หรือ Desktop มากกว่ากัน?
ควรดูทั้งคู่ แต่ถ้าลูกค้าส่วนใหญ่เข้าเว็บผ่านมือถือ ให้เริ่มจาก Mobile ก่อน เพราะอุปกรณ์และเครือข่ายของผู้ใช้มือถือมีความหลากหลายกว่า อย่าลืมตรวจข้อมูล Analytics ของเว็บไซต์ตัวเองประกอบด้วย
ทำไม PageSpeed คะแนนดี แต่ Core Web Vitals ยังไม่ผ่าน?
เพราะคะแนน Performance มาจาก Lab Test ในสภาพแวดล้อมจำลอง ขณะที่ Core Web Vitals ใน Field Data มาจากประสบการณ์ผู้ใช้จริงย้อนหลังหลายวัน จึงเป็นไปได้ที่ Lighthouse จะทดสอบได้เร็ว แต่ผู้ใช้จริงบางกลุ่มเจออุปกรณ์ช้า อินเทอร์เน็ตช้า หรือปัญหาที่เกิดหลังโหลดหน้าเว็บ ดังนั้นเวลาตัดสินคุณภาพเว็บไซต์ ควรอ่านสองชุดข้อมูลร่วมกัน ไม่ใช่ดูคะแนนวงกลมเพียงตัวเดียว