PWA คืออะไรกันแน่?

เว็บกับแอป — ปัญหาคู่ขนาน

เป็นเวลาหลายปีที่นักพัฒนาต้องเลือกระหว่างสองโลก: เว็บไซต์ที่ทุกคนเข้าถึงได้ผ่าน URL แต่รู้สึกด้อยกว่าบนมือถือ หรือแอป native ที่ให้ประสบการณ์ที่ดีแต่ต้องผ่านขั้นตอนของ app store และผู้ใช้ต้องดาวน์โหลดก่อนจึงจะลอง

Google แนะนำคำว่า Progressive Web App ในปี 2015 เพื่ออธิบายแนวทางที่สาม: ใช้ web platform เป็นพื้นฐาน แต่เพิ่ม API สมัยใหม่เข้าไปจนเว็บไซต์นั้นทำสิ่งที่ผู้ใช้คาดหวังจาก native app ได้ — ติดตั้งได้, ทำงาน offline ได้, และโหลดเร็วบนทุกเครือข่าย

ตัวอย่างในโลกจริง

ผลกระทบของ PWA วัดได้จริง กรณีที่มีเอกสารยืนยันชัดเจนที่สุดคือของ Twitter:

Twitter Lite สร้าง PWA แทนเว็บมือถือเดิมโดยใช้ app shell model ผลลัพธ์ที่เผยแพร่: pages per session เพิ่มขึ้น 65%, tweet ที่ส่งเพิ่มขึ้น 75%, bounce rate ลดลง 20% — ทั้งหมดนี้จากการดาวน์โหลดเริ่มต้นราว 600 KB เทียบกับแอป Android แบบ native ที่ 23.5 MB (เล็กกว่าประมาณ 97%) (web.dev/twitter, ตรวจสอบล่าสุดปี 2026)

เว็บไซต์ retail, productivity และข่าวรายใหญ่อื่นๆ อีกหลายเจ้ารายงานผลในทิศทางเดียวกัน — ติดตั้งเบากว่า โหลดซ้ำเร็วกว่า และมี engagement สูงขึ้น — หลังจากใช้แนวทาง app shell ร่วมกับ service worker แบบเดียวกัน แต่ตัวเลขเปอร์เซ็นต์เฉพาะจากบทความใดบทความหนึ่งควรระวัง — ตรวจสอบกับแหล่งที่ยัง live อยู่ก่อนนำไปอ้างซ้ำ และควรอ้างอิงผลวัดของทีมตัวเองหลัง ship จริงจะน่าเชื่อถือกว่า

สิ่งที่ทำให้กรณีเหล่านี้มีความสำคัญไม่ใช่เทคโนโลยีเฉพาะตัว — แต่คือการที่เว็บ URL เดียวสามารถเข้าถึงผู้ใช้ทั่วโลกได้ ขณะที่ยังมอบประสบการณ์เทียบเท่า native app

อะไรทำให้เว็บไซต์เป็น PWA?

ไม่มี binary flag ที่บอกว่าเว็บไซต์คือ PWA หรือไม่ใช่ แต่มีข้อกำหนดขั้นต่ำสามประการที่ browser ใช้ตัดสินว่าเว็บไซต์นั้น installable และ reliable พอหรือไม่:

1. ให้บริการผ่าน HTTPS

Service worker ทำหน้าที่เป็น network proxy ที่สามารถอ่านและแก้ไข request ทุกรายการ ดังนั้น browser จึงอนุญาตให้ลงทะเบียนได้บน origin ที่เชื่อถือได้เท่านั้น ซึ่งหมายถึง https:// หรือ localhost เพื่อการพัฒนา

2. มี Web App Manifest

ไฟล์ JSON ที่ลิงก์จาก <head> ซึ่งอธิบายว่าแอปควรแสดงผลอย่างไรเมื่อถูกติดตั้ง:

<link rel="manifest" href="/manifest.webmanifest" />

manifest ต้องมีอย่างน้อย name (หรือ short_name), start_url, display mode เป็น standalone หรือ fullscreen, และ icon อย่างน้อยหนึ่งขนาดที่ 192×192 ขึ้นไป:

{
  "name": "My PWA",
  "short_name": "MyApp",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#5A0FC8",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

3. มี Service Worker ที่ลงทะเบียนแล้ว

Service worker ต้องมี fetch event handler อยู่ด้วย แม้จะเป็นแค่ handler ที่ pass-through ก็ตาม นี่คือสัญญาณบอก browser ว่าแอปมีกลยุทธ์สำหรับ offline request Service worker ที่ handle แค่ install กับ activate ก็ผ่านเกณฑ์การลงทะเบียนได้ แต่จะไม่ได้ความสามารถ offline ใดๆ

// sw.js — minimal service worker that qualifies a page as installable
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((cached) => {
      return cached ?? fetch(event.request);
    })
  );
});

เมื่อทั้งสามเงื่อนไขนี้ครบ browser จะประเมินว่าเว็บไซต์ผ่านเกณฑ์ installability หรือไม่ และอาจแสดง install prompt ให้กับผู้ใช้

PWA ทำได้และทำไม่ได้อะไรบ้างเมื่อเทียบกับ native?

PWA ครอบคลุมสิ่งที่ native app ทำได้มากกว่าที่หลายคนคิด ตารางด้านล่างสะท้อนสถานะ browser API ปี 2026 “จำกัด” หมายถึง API มีอยู่แต่ยังมีช่องว่างระหว่าง platform (ปกติ iOS/Safari ตามหลัง Chrome/Android)

ความสามารถ	PWA	Native	หมายเหตุ
Offline access	ได้	ได้	ผ่าน Cache API และ service worker
ติดตั้งที่ home screen	ได้	ได้	PWA ไม่ต้องผ่านการ review ของ app store
Push notifications	ได้	ได้	จำกัดบน iOS Safari ก่อนเวอร์ชัน 16.4
Camera / microphone	ได้	ได้	ผ่าน `getUserMedia` — ต้องขอ permission
Background sync	ได้	ได้	`BackgroundSyncManager`; จำกัดบน iOS
File system access	ได้	ได้	File System Access API; ไม่มีบน Firefox
Payments	ได้	ได้	Payment Request API
Bluetooth	จำกัด	ได้	Web Bluetooth API; ไม่มีบน Firefox หรือ iOS
NFC	จำกัด	ได้	Web NFC; เฉพาะ Chrome บน Android
SMS / โทรออก	ไม่ได้	ได้	ไม่มี web API ที่เทียบเท่า
App store listing	ทางเลือก	จำเป็น	PWA Builder ห่อ PWA ขึ้น store ได้
Auto-update	ได้	ต้องกดเอง	service worker เวอร์ชันใหม่ activate แบบเงียบๆ
Deep OS integration	จำกัด	ได้	มี shortcuts, share target, protocol handler แล้ว; lock-screen widget ยังไม่มี

ช่องว่างที่เหลือใหญ่ที่สุดคือ deep OS integration — lock-screen widget, background process ที่ทำงานตลอดเวลา และ hardware access ระดับต่ำ (NFC บน iOS, Bluetooth บน Firefox) สำหรับ use case ส่วนใหญ่ — content, commerce, productivity — PWA ครอบคลุมสิ่งที่ผู้ใช้ต้องการได้ครบแล้ว

เกณฑ์ installability ในทางปฏิบัติ

“Installable” ไม่ใช่มาตรฐานเดียวที่ใช้ทั่วโลก แต่ละ browser engine มี heuristic ของตัวเองที่เพิ่มเข้ามาบนสามข้อกำหนดบังคับ:

Chromium (Chrome, Edge, Samsung Internet) — แสดง install prompt เมื่อครบสามข้อกำหนดและผู้ใช้มี interaction กับหน้าเว็บแล้ว เกณฑ์ engagement ที่แน่นอนตั้งใจให้คลุมเครือและเปลี่ยนไปเรื่อยๆ
Safari (iOS และ macOS) — ไม่แสดง install prompt แบบ ambient ผู้ใช้ต้องกด share sheet แล้วเลือก “Add to Home Screen” เอง
Firefox — เลิกมี install UI ของตัวเองแล้ว แต่ยังรองรับ service worker และ manifest; ติดตั้งผ่าน extension ได้

หมายความว่า PWA ของคุณต้องทำงานได้ดีในฐานะเว็บไซต์ธรรมดาเสมอ ความสามารถในการติดตั้งที่เพิ่มขึ้นมาเป็นแบบ progressive — ตามชื่อของมัน

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

ตัวเลือก	Benefit	Cost
PWA (เว็บเป็นฐาน)	เข้าถึงได้ผ่าน URL เดียว ไม่ต้องผ่าน app store ก่อนลอง	เข้าถึง API บางตัวของอุปกรณ์ได้จำกัดกว่า native เต็มรูปแบบ
Native App	เข้าถึง hardware/OS API ได้เต็มรูปแบบ	ต้องผ่าน app store ผู้ใช้ต้องดาวน์โหลดก่อนถึงจะลองได้

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

คิดว่า “มี manifest แล้ว = เป็น PWA” — ทั้งที่ยังขาด HTTPS หรือ service worker ที่ลงทะเบียนสำเร็จ
เข้าใจว่า PWA ต้องเลือกแทนที่ native app เสมอ — หลายทีมใช้ทั้งสองคู่กัน (PWA สำหรับ reach, native สำหรับ power user)
มองข้ามข้อจำกัดบน iOS Safari (ไม่มี install prompt แบบ ambient, พื้นที่เก็บข้อมูลจำกัดกว่า) แล้วออกแบบเหมือนทุก platform เท่ากันหมด