การ Audit PWA ด้วย Lighthouse

Lighthouse คือเครื่องมือคุณภาพที่ built-in มากับ Chrome โดยรัน automated check กับหน้าของคุณแล้วสร้าง report แบบแยกหมวดหมู่พร้อมคะแนน ตั้งแต่ Lighthouse 12 (ปี 2024 มากับ Chrome DevTools ราวๆ Chrome 126) report มีสี่หมวด: Performance, Accessibility, Best Practices และ SEO ส่วนหมวดเดิม Progressive Web App — ที่เคยแสดง pass/fail ของเกณฑ์ installability แต่ละข้อ — ถูก ลบออกไปแล้ว Lighthouse ไม่ให้คะแนนหมวด PWA อีกต่อไป การตรวจสอบ installability และเช็คเฉพาะทางของ PWA ย้ายไปอยู่ที่ Application panel ใน DevTools แทน

การสร้างนิสัยในการเช็คแอปแต่เนิ่นๆ — ก่อนที่คุณจะเชื่อมต่อ caching strategy หรือ push notification — หมายความว่าคุณจับส่วนที่ขาดหายไปได้ตอนที่ codebase ยังเล็กอยู่ Lighthouse ดูแลเรื่อง performance และ best practices ส่วน Application panel ดูแลเรื่อง installability

วิธีรัน Lighthouse

เปิด Chrome และนำทางไปยังแอปของคุณ (ต้อง serve ผ่าน HTTPS หรือ localhost)
เปิด DevTools ด้วย F12 หรือ Cmd+Option+I
คลิก tab Lighthouse (คุณอาจต้องคลิกลูกศร overflow » เพื่อค้นหา)
ภายใต้ Categories เลือกหมวดที่ต้องการ — Performance, Accessibility, Best Practices, SEO
คลิก Analyze page load

Lighthouse โหลดหน้าซ้ำ เก็บข้อมูล และแสดง report พร้อมคะแนนแยกตามหมวด สังเกตว่า ไม่มีหมวด Progressive Web App ให้ติ๊กแล้ว — หมวดนี้ถูกลบไปใน Lighthouse 12 หากต้องการยืนยันว่าแอปติดตั้งได้ ให้ใช้ Application panel ที่อธิบายต่อจากนี้

ทัวร์ Application tab

tab Application ใน DevTools คือที่ที่ installability ย้ายมาอยู่ตอนนี้ คุณตรวจสอบ state สดของ PWA ได้ตลอดเวลาโดยไม่ต้องโหลดซ้ำ

Panel	สิ่งที่แสดง
Manifest	`manifest.webmanifest` ที่ถูก parse — name, icons (พร้อม preview), `start_url`, `display`, สี banner คำเตือนจะปรากฏหาก field ที่จำเป็นขาดหายไป
Service Workers	SW ที่ register แล้วทุกตัวสำหรับ origin นี้: URL ของ script, status (`activated and is running`, `waiting to activate`, `stopped`) และปุ่ม skipWaiting เพื่อ force-activate SW ที่รอ
Storage	รายการ Cache Storage ที่สร้างโดย SW ของคุณ มีประโยชน์สำหรับการตรวจสอบ pre-cache list
Background Services	Log สำหรับ Background Fetch, Background Sync, Push Messaging — มีประโยชน์เมื่อคุณเพิ่ม API เหล่านั้น

เปิด panel Manifest ก่อนเป็นอันดับแรกสำหรับ PWA ที่ไม่คุ้นเคย panel นี้บอกได้ทันทีว่า browser ได้ parse manifest ที่ถูกต้องหรือไม่ และพบ icon อะไรบ้าง

เกณฑ์ installability (ตรวจสอบใน Application panel)

เกณฑ์การ install ของ Chrome คือสิ่งที่ browser ต้องการก่อนจะเสนอให้ติดตั้งแอป panel Application → Manifest จะเตือน installability warning สำหรับข้อที่ยังไม่ผ่าน:

เกณฑ์	สิ่งที่ต้องเป็นจริง
Web app manifest	มี tag `<link rel="manifest">` อยู่และไฟล์เข้าถึงได้
`name` หรือ `short_name`	มีอย่างน้อยหนึ่งอยู่ใน manifest
`start_url`	มีอยู่และตอบกลับด้วย 200 เมื่อถูก fetch
`display`	ตั้งค่าเป็น `standalone`, `fullscreen` หรือ `minimal-ui`
Icons	มี icon อย่างน้อยหนึ่งที่ขนาด 192 × 192 และหนึ่งที่ 512 × 512 (หรือใหญ่กว่า) Icon ต้องประกาศ `src`, `sizes` และ `type`
Service worker	SW ถูก register และควบคุมหน้า
HTTPS	หน้าอยู่บน secure origin (`https://` หรือ `localhost`)

ความล้มเหลวที่พบบ่อยและวิธีแก้ไข

ข้อความความล้มเหลว	สาเหตุ	วิธีแก้ไข
`No manifest detected`	ขาด `<link rel="manifest">` หรือไฟล์ return 404	เพิ่ม `<link rel="manifest" href="/manifest.webmanifest">` ใน `<head>` และตรวจสอบว่าไฟล์ถูก serve
`Manifest does not contain a 192px icon`	array icons ว่างเปล่าหรือ icon ทั้งหมดเล็กกว่า 192 px	เพิ่ม entry ที่มี `"sizes": "192x192"` และอีกอันที่มี `"sizes": "512x512"`
`Page controlled by a service worker` ล้มเหลว	ไม่มี SW register, SW throw ระหว่าง install หรือ scope ของ SW ไม่ครอบคลุมหน้า	Register SW จาก root (`/sw.js`) และยืนยันว่า console ไม่แสดง registration error
`Does not redirect HTTP to HTTPS`	Production server ไม่ enforce HTTPS	กำหนดค่า host หรือ CDN ของคุณให้ออก 301 redirect จาก `http://` ไปยัง `https://`
`start_url does not respond with a 200`	`start_url` ชี้ไปยัง path ที่ return 404 หรือ SW ไม่จัดการ request นั้น	ตรวจสอบว่า `start_url` เป็น route จริงและ fetch handler ของ SW return บางอย่างให้ route นั้น
`display is not one of standalone, fullscreen, minimal-ui`	`"display": "browser"` หรือ field ขาดหายไป	เปลี่ยนเป็น `"display": "standalone"`

ทดลองแบบ live

demo ด้านล่างเป็น PWA ขั้นต่ำที่ผ่านเกณฑ์ installability ทุกข้อ เปิดใน StackBlitz แล้วเปิด Application → Manifest ภายใน preview เพื่อยืนยันว่าไม่มี installability warning และรัน Lighthouse หากต้องการดูคะแนน Performance และ Best Practices ด้วย

Runs a real service worker + manifest in your browser.

ข้อแลกเปลี่ยน

ตัวเลือก	Benefit	Cost
รัน Lighthouse audit ใน CI ทุก PR	จับ regression ของ PWA checklist ได้ทันทีก่อน merge	เพิ่มเวลา build/CI และต้อง maintain threshold score
รัน Lighthouse แบบ manual เป็นครั้งคราว	ไม่เพิ่ม overhead ให้ pipeline	พลาด regression ได้ง่าย เพราะไม่มีใครนึกจะรันจนกว่าจะมีปัญหา

ข้อผิดพลาดที่พบบ่อย

อ่านแค่ตัวเลขคะแนนรวมโดยไม่ดู audit item ที่ fail จริง ทำให้แก้ปัญหาผิดจุด
รัน Lighthouse บน localhost ที่ไม่มี production build/caching จริง แล้วเข้าใจผิดว่าคะแนนใน production จะเหมือนกัน
ไม่รันซ้ำหลายรอบ — คะแนน performance ผันผวนตาม network throttling และ CPU ของเครื่องที่รัน

💡 ตัวอย่างจากของจริง

web.dev/measure — ทีม Chrome ใช้ Lighthouse เป็นมาตรฐานกลางสำหรับ PWA checklist ที่นักพัฒนาทั่วโลกอ้างอิง

Lighthouse CI ของ Google — หลายทีมตั้ง budget คะแนนขั้นต่ำใน pipeline เพื่อกัน regression ก่อนขึ้น production