วิธีอ่านรายงาน Lighthouse โดยไม่ตื่นตระหนก
คู่มือเชิงปฏิบัติสำหรับทำความเข้าใจว่าอะไรสำคัญในการตรวจสอบประสิทธิภาพของคุณ—และอะไรที่คุณมองข้ามได้อย่างปลอดภัย
สารบัญ
- กฎข้อแรก: คะแนนของคุณไม่ใช่เว็บไซต์ของคุณ
- สิ่งที่ควรอ่านก่อน: Core Web Vitals
- Opportunities กับ Diagnostics: รู้ความแตกต่าง
- รายการ audit ที่โดยทั่วไปมองข้ามได้
- จะทำอย่างไรเมื่อทุกอย่างเป็นสีแดง
- Lab data กับ field data: การตรวจสอบกับความจริง
- ควรรัน Lighthouse ซ้ำเมื่อใด
- เครื่องมือที่ช่วยให้คุณลงมือกับผลลัพธ์จาก Lighthouse
- ข้อสรุปสำคัญ
- FAQ
- Sources
กฎข้อแรก: คะแนนของคุณไม่ใช่เว็บไซต์ของคุณ
เมื่อเปิดรายงาน Lighthouse เป็นครั้งแรก คุณจะเจอกับตัวเลขจำนวนมาก กล่องสีต่าง ๆ และคำเตือนเกี่ยวกับสิ่งที่คุณอาจไม่เคยได้ยินมาก่อน ปฏิกิริยาตามธรรมชาติคือความตื่นตระหนก คะแนนเป็นสีแดง มีการตรวจสอบที่ไม่ผ่านสิบเจ็ดรายการ แปลว่าเว็บไซต์เสียแล้วอย่างนั้นหรือ?
อาจไม่ใช่ Lighthouse เป็นเครื่องมือวินิจฉัย ไม่ใช่ใบรายงานผล คะแนนคือ benchmark สังเคราะห์ที่รันภายใต้เงื่อนไขในห้องแล็บ—มักอยู่บนการเชื่อมต่อที่ถูกจำกัดความเร็ว และจำลองโทรศัพท์ระดับกลางจากปี 2017 มันบอกคุณว่าเว็บไซต์ทำงานอย่างไรในสถานการณ์เฉพาะนั้น ไม่ใช่ว่าผู้ใช้จริงสัมผัสประสบการณ์อย่างไรในโลกจริง
ประเด็นนี้สำคัญ เพราะทีมส่วนใหญ่มักยึดติดกับคะแนนและพลาดบริบท คะแนน 65 อาจถือว่าใช้ได้สำหรับเว็บแอปที่ซับซ้อนและมีข้อมูลแบบ real-time คะแนน 95 ก็ยังอาจให้ประสบการณ์ที่ไม่ดีได้ หากไป optimize ผิดจุด คะแนนเป็นจุดเริ่มต้นของการตรวจสอบ ไม่ใช่ตัวชี้วัดความสำเร็จ
สิ่งที่ควรอ่านก่อน: Core Web Vitals
ข้ามคะแนน performance โดยรวมไปก่อน เลื่อนลงไปที่ส่วน Metrics แล้วดูตัวเลขสามตัว: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), และ Interaction to Next Paint (INP) สิ่งเหล่านี้คือ Core Web Vitals และเป็น metric ด้าน performance เพียงชุดเดียวที่ Google ใช้เป็นสัญญาณในการจัดอันดับ
- LCP วัดว่าองค์ประกอบที่มองเห็นได้ขนาดใหญ่ที่สุดใช้เวลานานเท่าใดจึงจะแสดงผล เป้าหมาย: ต่ำกว่า 2.5 วินาที หากเกิน 4 วินาที ผู้ใช้กำลังรอนานเกินไปกว่าจะเห็นเนื้อหาที่มีความหมาย
- CLS วัดความเสถียรทางสายตา—หน้ากระโดดหรือขยับมากแค่ไหนขณะโหลด เป้าหมาย: ต่ำกว่า 0.1 หากเกิน 0.25 ผู้ใช้มีโอกาสคลิกผิดสิ่งโดยไม่ตั้งใจเพราะปุ่มขยับตำแหน่ง
- INP วัดการตอบสนอง—หน้าเว็บตอบสนองต่อการคลิก การแตะ และการกดแป้นพิมพ์เร็วเพียงใด เป้าหมาย: ต่ำกว่า 200ms หากเกิน 500ms เว็บไซต์จะรู้สึกอืด
metric ทั้งสามนี้สัมพันธ์กับความหงุดหงิดของผู้ใช้จริง แก้สิ่งเหล่านี้ก่อนที่จะกังวลเรื่องอื่น
Opportunities กับ Diagnostics: รู้ความแตกต่าง
Lighthouse แบ่งผลลัพธ์ออกเป็นสองหมวด: Opportunities และ Diagnostics Opportunities จะถูกจัดอันดับตามเวลาที่คาดว่าจะประหยัดได้ ส่วน Diagnostics คือบริบทเพิ่มเติม—สิ่งที่อาจเป็นปัญหา หรืออาจไม่ใช่ก็ได้
เริ่มจาก Opportunities หาก Lighthouse บอกว่า "Eliminate render-blocking resources" อาจประหยัดได้ 1.2 วินาที นั่นคือชัยชนะที่จับต้องได้ หากบอกว่า "Reduce unused JavaScript" อาจประหยัดได้ 0.1 วินาที ก็น่าจะไม่คุ้มกับการ refactor
Diagnostics ซับซ้อนกว่า "Avoid an excessive DOM size" ฟังดูไม่ดี แต่หาก CLS ของคุณดีและ INP เร็ว DOM ขนาดใหญ่ก็อาจไม่ได้ทำร้ายใคร Diagnostics คือเบาะแส ไม่ใช่คำสั่ง ให้ตรวจสอบรายการที่สอดคล้องกับ metric จริงของคุณ
รายการ audit ที่โดยทั่วไปมองข้ามได้
คำเตือนบางอย่างของ Lighthouse เป็นสิ่งตกค้างจากอดีตหรือเข้มงวดเกินไป ต่อไปนี้คือรายการที่มักทำให้เกิดความตื่นตระหนกโดยไม่จำเป็นมากที่สุด:
- "Does not use passive listeners to improve scrolling performance" — นี่คือ micro-optimization ที่แทบไม่เปลี่ยนผลลัพธ์อย่างมีนัยสำคัญ เว้นแต่คุณมีหลักฐานว่า scrolling กระตุก ให้ข้ามไป
- "Image elements do not have explicit width and height" — เรื่องนี้สำคัญต่อ CLS แต่เฉพาะเมื่อรูปภาพเป็นสาเหตุของ layout shifts หาก CLS ของคุณดีอยู่แล้ว อย่า refactor เพียงเพื่อให้ผ่าน audit
- "Serve images in next-gen formats" — ใช่ WebP และ AVIF มีขนาดเล็กกว่า แต่หากรูปภาพของคุณถูก optimize แล้วและ LCP เร็ว นี่คือสิ่งที่มีไว้ก็ดี ไม่ใช่วิกฤต
- "Avoid enormous network payloads" — Lighthouse จะ flag ทุกอย่างที่เกิน 1.6 MB แต่หน้า 2 MB ที่โหลดเร็ว ดีกว่าหน้า 500 KB ที่บล็อกการ render ให้โฟกัสที่ว่า byte ถูกส่งมอบ อย่างไร ไม่ใช่แค่ยอดรวม
จะทำอย่างไรเมื่อทุกอย่างเป็นสีแดง
หากคะแนน Lighthouse ของคุณต่ำกว่า 50 และ audit ส่วนใหญ่ไม่ผ่าน คุณอาจกำลังเจอกับสาเหตุหลักหนึ่งในสามอย่างนี้:
- ฟอนต์ที่ยังไม่ optimize Web fonts ยังคงเป็นชัยชนะด้าน performance ที่ทำได้ง่ายที่สุดในเว็บไซต์ส่วนใหญ่ ตรวจสอบว่าคุณโหลดฟอนต์หกน้ำหนักทั้งที่ใช้จริงแค่สอง หรือส่ง WOFF แทน WOFF2 อยู่หรือไม่
- CSS และ JavaScript ที่บล็อกการ render หาก First Contentful Paint (FCP) ของคุณเกิน 3 วินาที มีบางอย่างกำลังขวาง browser ไม่ให้วาดหน้า มองหาไฟล์ CSS ขนาดใหญ่หรือ script แบบ synchronous ใน
<head> - รูปภาพขนาดใหญ่เกินไป หากองค์ประกอบ LCP ของคุณเป็นรูปภาพและมีขนาด 4 MB นั่นคือปัญหา บีบอัดรูปนั้น ทำ lazy-load ให้รูปภาพ below-the-fold และใช้ syntax ของ responsive image
แก้หนึ่งในสิ่งเหล่านี้แล้วรัน Lighthouse อีกครั้ง คุณมักจะเห็นคะแนนกระโดดขึ้น 20-30 คะแนน จากนั้นค่อยจัดการเรื่องถัดไป
Lab data กับ field data: การตรวจสอบกับความจริง
Lighthouse รันในห้องแล็บ มันจำลองการเชื่อมต่อที่ช้าและอุปกรณ์ที่ช้า แต่ไม่สามารถจำลองพฤติกรรมผู้ใช้จริงได้—ผู้คนเลื่อนหน้าอย่างไร คลิกอะไร หรืออยู่บน Wi-Fi ที่ไม่เสถียรหรือไม่
เพื่อเช็กกับความเป็นจริง ให้เปรียบเทียบผล Lighthouse ของคุณกับ field data จาก Chrome User Experience Report (CrUX) CrUX แสดงให้เห็นว่าผู้ใช้ Chrome จริงสัมผัสประสบการณ์เว็บไซต์ของคุณอย่างไรในช่วง 28 วันที่ผ่านมา หาก Lighthouse บอกว่า LCP ของคุณคือ 4 วินาที แต่ CrUX แสดง 2 วินาที ให้เชื่อ CrUX หากทั้งคู่แย่ แสดงว่าคุณมีปัญหาจริง
คุณดูข้อมูล CrUX ได้ใน PageSpeed Insights (เวอร์ชันเว็บของ Lighthouse) หรือใน Google Search Console ภายใต้ "Core Web Vitals" หากมีความไม่ตรงกัน ให้ตรวจสอบสาเหตุ บางทีผู้ใช้จริงของคุณอาจอยู่บนเครือข่ายที่เร็วกว่า หรือบางที Lighthouse อาจกำลังทดสอบ dev build ที่ยังไม่ optimize
ควรรัน Lighthouse ซ้ำเมื่อใด
Lighthouse มีความผันผวน รันสามครั้งติดกันแล้วคุณอาจได้คะแนนต่างกันสามชุด แม้จะเป็นหน้าเดียวกันก็ตาม เพราะ performance มีความแปรปรวน—process เบื้องหลัง network jitter และ heuristics ของ browser ล้วนส่งผลต่อผลลัพธ์
เพื่อให้ได้ baseline ที่เสถียร ให้รัน Lighthouse ใน incognito mode โดยปิด extension ทั้งหมด หรือใช้ CLI พร้อม flag --preset=desktop เพื่อให้ผลลัพธ์สม่ำเสมอกว่า รันสามครั้งแล้วเฉลี่ยคะแนน หากคุณเห็นการแกว่งรุนแรง (มากกว่า 10 คะแนน) มีบางอย่างผิดปกติ—อาจเป็น server ช้า หรือหน้าโหลด resource ต่างกันในแต่ละครั้ง
รัน Lighthouse ซ้ำหลังการเปลี่ยนแปลงสำคัญทุกครั้ง Deploy กลยุทธ์ฟอนต์ใหม่หรือไม่? ตรวจ LCP ทำ lazy-load รูปภาพหรือไม่? ตรวจ CLS เพิ่ม third-party script หรือไม่? ตรวจ INP Performance ไม่ใช่การแก้ครั้งเดียวจบ แต่เป็นงบประมาณที่คุณต้องปกป้อง
เครื่องมือที่ช่วยให้คุณลงมือกับผลลัพธ์จาก Lighthouse
Lighthouse บอกคุณว่าอะไรช้า แต่มันไม่ได้บอกเสมอไปว่าจะแก้อย่างไร สำหรับเรื่องนั้น คุณต้องใช้เครื่องมือเพิ่มเติม:
- WebPageTest ให้มุมมองแบบ filmstrip ว่าหน้าโหลดอย่างไรทีละ frame จำเป็นมากสำหรับวินิจฉัยปัญหา LCP และ CLS
- Chrome DevTools Performance panel แสดงให้เห็นอย่างชัดเจนว่า JavaScript ใดกำลังบล็อก main thread ใช้เพื่อหาต้นตอของคะแนน INP ที่ไม่ดี
- เครื่องมือบีบอัดรูปภาพ ช่วยให้คุณ optimize รูปภาพได้โดยตรงใน browser ซึ่งเร็วกว่าและเป็นส่วนตัวกว่าการอัปโหลดไปยังบริการ third-party การประมวลผลรูปภาพฝั่ง client เป็นชัยชนะด้านความเป็นส่วนตัว เพราะรูปภาพของคุณไม่เคยออกจากเครื่อง
Lighthouse คือจุดเริ่มต้น เครื่องมือเหล่านี้ช่วยให้คุณทำงานให้เสร็จ
ข้อสรุปสำคัญ
- คะแนน Lighthouse ของคุณคือ benchmark ในห้องแล็บ ไม่ใช่การวัดประสบการณ์ผู้ใช้จริง เปรียบเทียบกับ field data จาก CrUX ก่อนจะตื่นตระหนก
- โฟกัสที่ Core Web Vitals (LCP, CLS, INP) ก่อน สิ่งเหล่านี้คือ metric ที่สัมพันธ์กับความหงุดหงิดของผู้ใช้และผลกระทบต่อ SEO
- จัดลำดับความสำคัญของ Opportunities ตามเวลาที่คาดว่าจะประหยัดได้ มองข้าม Diagnostics ที่ไม่สอดคล้องกับปัญหา performance จริงของคุณ
- audit บางอย่าง—เช่น passive listeners หรือ next-gen image formats—เป็น micro-optimization ให้แก้เรื่องใหญ่ก่อน
- รัน Lighthouse สามครั้งแล้วเฉลี่ยผลลัพธ์ Performance มีความแปรปรวน และการรันเพียงครั้งเดียวอาจทำให้เข้าใจผิดได้
FAQ
Q: ทำไมคะแนน Lighthouse ของฉันเปลี่ยนทุกครั้งที่รัน?
A: Lighthouse วัด performance ภายใต้เงื่อนไขที่แปรผัน—ความเร็วเครือข่าย โหลดของ CPU และ heuristics ของ browser ล้วนส่งผลต่อผลลัพธ์ ให้รันสามครั้งใน incognito mode แล้วเฉลี่ยคะแนนเพื่อให้ได้ baseline ที่เสถียรกว่า
Q: ควร optimize สำหรับ mobile หรือ desktop ก่อน?
A: Mobile. Lighthouse ตั้งค่าเริ่มต้นเป็นการจำลอง mobile เพราะ traffic เว็บส่วนใหญ่มาจาก mobile และอุปกรณ์ mobile ช้ากว่า หากคะแนน mobile ของคุณดี คะแนน desktop มักจะดีด้วย
Q: คะแนน Lighthouse ของฉันคือ 95 แต่เว็บไซต์ยังรู้สึกช้า เกิดอะไรขึ้น?
A: Lighthouse วัดการโหลดหน้า ไม่ใช่การโต้ตอบหลังโหลด ตรวจคะแนน INP และใช้ Chrome DevTools Performance panel เพื่อ profile สิ่งที่เกิดขึ้นเมื่อผู้ใช้คลิกหรือเลื่อนหน้า คุณอาจมีปัญหา JavaScript ที่ Lighthouse ตรวจไม่เจอ
Q: จำเป็นต้องได้คะแนนเต็ม 100 หรือไม่?
A: ไม่จำเป็น คะแนน 90+ ถือว่ายอดเยี่ยม การไล่ล่า 100 มักหมายถึงการ optimize สิ่งที่ไม่สำคัญต่อผู้ใช้ ให้โฟกัส metric จริง—LCP, CLS, INP—และมองข้ามคะแนน
Q: ฉันเชื่อ Lighthouse ได้ไหมหากใช้ third-party scripts จำนวนมาก?
A: Lighthouse จะ flag third-party scripts ว่าเป็นปัญหา แต่มันไม่สามารถแยกได้เสมอไปว่าอันไหนจำเป็นหรือไม่จำเป็น ใช้ audit "Avoid enormous network payloads" และ "Reduce JavaScript execution time" เพื่อระบุตัวการที่แย่ที่สุด จากนั้นค่อยตัดสินใจว่าคุ้มที่จะเก็บไว้หรือไม่
Sources
- "Lighthouse performance scoring" — Google Developers
- "Core Web Vitals" — web.dev
- "Chrome User Experience Report" — Google Developers
- "WebPageTest Documentation" — WebPageTest.org
คำถามที่พบบ่อย
ทำไมคะแนน Lighthouse ของฉันเปลี่ยนทุกครั้งที่รัน?
ควร optimize สำหรับ mobile หรือ desktop ก่อน?
คะแนน Lighthouse ของฉันคือ 95 แต่เว็บไซต์ยังรู้สึกช้า เกิดอะไรขึ้น?
จำเป็นต้องได้คะแนนเต็ม 100 หรือไม่?
ฉันเชื่อ Lighthouse ได้ไหมหากใช้ third-party scripts จำนวนมาก?
แหล่งข้อมูล & การอ่านเพิ่มเติม
