pwa是什麼？漸進式網頁應用差異、導入情境與SEO重點

PWA 是什麼？一句話理解漸進式網頁應用

PWA（Progressive Web App，漸進式網頁應用）是用 Web 技術打造，卻能提供接近平台 App 體驗的網站或 Web App。根據 MDN 與 web.dev 的說明，PWA 的核心在於可安裝、離線或弱網路可用、背景能力、Web App Manifest 與 Service Worker。搜尋 pwa是什麼時，真正要判斷的不是名詞，而是網站是否需要補上 App 型體驗。

• PWA 仍然是網站，可以被搜尋、分享網址，也能跨裝置使用。
• PWA 可加入主畫面，搭配圖示、啟動畫面與獨立視窗，降低回訪摩擦。
• PWA 要做得好，重點在快取、更新、權限與 SEO，而不是只加一份 manifest 檔案。

PWA 的全名與中文意思

PWA 的全名是 Progressive Web App，中文常譯為漸進式網頁應用或漸進式網頁應用程式。「漸進式」指的是網站可以依照瀏覽器與裝置能力逐步加上功能；支援度高的環境得到更完整體驗，支援度較低的環境仍可正常瀏覽主要內容。

PWA 和一般網站差在哪

一般網站多半依賴瀏覽器入口，使用者要記得網址、搜尋品牌，或從 LINE、Email、廣告連回來。PWA 多了可安裝網站、主畫面圖示、離線頁、快取策略與推播通知等能力，適合會員、電商、預約、內容收藏、票券與企業內部後台。

PWA 不是「省錢版 App」，而是 Web App 的體驗升級

我會把 PWA 視為 Web App 的體驗升級，而不是拿來包裝成便宜 App 的替代品。若商業需求是重度遊戲、深度藍牙、NFC、生物辨識或 App Store 搜尋曝光，原生 App 仍可能更合理；若需求是回訪、低摩擦入口、弱網路備援與內容可搜尋，PWA 才有討論價值。

為什麼會需要 PWA：Web App 原本少了什麼

PWA 主要補上 Web App 在手機使用上的幾個缺口：入口不夠固定、網路差就中斷、回訪提醒弱、安裝感不足。它保留網站容易分享與搜尋的優勢，同時讓常用功能更像 App 一樣容易回來使用。

一般網站在手機上常見的摩擦

手機網站常見的摩擦不是頁面打不開，而是使用者第二次找不到、登入後操作太慢、切換網路時流程中斷，或活動現場人多時票券頁載不出來。展示型網站不一定需要 PWA，但有互動流程的網站，這些摩擦會直接影響成交與客服量。

Web App 的限制：每次都要開瀏覽器、網路差就中斷、回訪提醒弱

Web App 若只存在於瀏覽器分頁，回訪要靠書籤、搜尋、社群連結或廣告再觸達。網路不穩時，表單、購物車、會員資料與內部報表也容易中斷。這些問題不一定靠重新設計頁面解決，常常要靠快取、離線頁與權限設計一起處理。

PWA 保留 Web 的低摩擦，同時吸收部分原生 App 體驗

PWA 的價值在於不用先要求使用者到商店下載 App，也能建立固定入口。對台灣中小企業來說，PWA 的價值通常在第二次造訪，不在第一次曝光；沒有回訪需求，PWA 很容易變成額外維護成本。

原本問題	PWA 補足方式	適合觀察的商業訊號
使用者找不到入口	加入主畫面、App 圖示、獨立視窗	回訪率、會員登入次數、收藏功能使用率
網路差造成流程中斷	Service Worker 快取、offline page、背景同步	活動現場、外勤、地下室、通勤場景
通知只能靠 Email 或 LINE	Web Push 與 Notifications API	訂單、預約、票券、課程提醒
每次載入都太重	靜態資源快取、stale-while-revalidate	重複瀏覽、後台查詢、會員中心

PWA 的核心組成：Manifest、Service Worker、HTTPS 與可安裝體驗

完整 PWA 通常需要 Web App Manifest、Service Worker（背景代理程式）、HTTPS、安全的快取策略、圖示與可安裝體驗。只讓網站能加到主畫面，不代表已經處理離線、更新、推播與跨瀏覽器品質。

核心元件	用途	商業判斷
Web App Manifest	定義安裝後名稱、圖示、啟動畫面與顯示模式	品牌入口是否需要像 App 一樣固定
Service Worker	攔截請求、管理 Cache Storage、回應離線頁	是否有弱網路、重複瀏覽或離線備援需求
HTTPS	提供安全連線，是多數 PWA 能力的前提	會員、付款、推播與資料同步不可省略
Web Push	在使用者同意後發送通知	是否有真正值得提醒的事件
Lighthouse	檢查安裝性、效能、可存取性與最佳實務	上線前要有可重複驗收的依據

Web App Manifest 決定安裝後名稱、圖示與啟動畫面

Web App Manifest 是一份 JSON 設定檔，告訴瀏覽器安裝後要顯示什麼名稱、圖示、主題色與啟動網址。它處理的是「像不像一個可被使用者留下來的入口」，不是網站內容本身。

必講欄位：name、short_name、start_url、scope、display、icons、theme_color

name 與 short_name 影響主畫面和系統介面的顯示；start_url 決定啟動頁；scope 控制 PWA 的有效範圍；display 可設定為 standalone；icons 與 theme_color 影響品牌辨識與啟動畫面。這些欄位小，但會影響使用者是否把它當成可信入口。

Service Worker 負責攔截請求、快取與離線回應

Service Worker 是跑在瀏覽器背景的程式，可攔截頁面請求、決定使用網路回應或本機快取，並在離線時回傳 offline page。實務上，PWA 專案最常卡住的不是 manifest 欄位，而是快取規則和內容更新。

快取策略：cache-first、network-first、stale-while-revalidate

cache-first 適合圖示、CSS、字型等不常變動的靜態資源；network-first 適合價格、庫存、會員資料等需要新鮮內容的頁面；stale-while-revalidate 可先顯示快取，再背景更新，常用於內容列表或重複瀏覽頁。錯把會員資料或庫存快取太久，會比沒有 PWA 更麻煩。

HTTPS 是基本門檻

PWA 涉及權限、快取、推播與背景能力，必須建立在安全連線上。若網站仍有混合內容、過期憑證或第三方腳本安全問題，應先處理基礎網站健康度，再談 PWA 升級。

可安裝不等於完整 PWA，還要看離線、更新與體驗品質

使用者能加入主畫面，只是安裝體驗的一部分。完整 PWA 還要處理離線時顯示什麼、更新後舊快取怎麼清、推播權限如何取得、iOS 與 Android 是否都能完成主要流程。

PWA 的優點：對企業與使用者有什麼幫助

PWA 的優點包含跨平台、更新快、入口固定、弱網路可用、內容仍可被搜尋。它適合已經有回訪和互動需求的網站，但不應被包裝成轉換率保證。

不用走 App Store / Google Play 也能建立主畫面入口

PWA 可讓使用者從瀏覽器加入主畫面，減少下載 App 的心理門檻。對預約、會員中心、活動票券、補習班系統這類低頻但重要的功能，主畫面入口比要求安裝完整 App 更容易被接受。

同一套網站可服務手機、平板、桌機

同一套 Web App 可以支援手機、平板、桌機與不同瀏覽器，維護成本通常比同時維護 iOS、Android 和網站低。不過前提是 RWD、效能與互動設計先過關，可參考 企業網站建置 與 設計系統 的基礎規劃。

更新速度比原生 App 快

PWA 更新不需要每次送審商店，內容、介面與功能修正可以跟網站部署流程整合。這對活動頁、會員功能、價格方案與營運訊息很有幫助，但也要求團隊做好版本控管與回滾。

對會員、電商、預約與活動頁能降低回訪摩擦

會員中心可保留登入狀態，電商可加快購物車與收藏頁載入，預約系統可用推播提醒時段，活動票券可提供弱網路備援。PWA 的商業價值不在炫技，而在減少使用者回來完成任務的阻力。

優點	適用條件	不該過度承諾
跨平台維護	核心功能可用 Web 技術完成	不代表所有硬體能力都能取代原生 App
回訪入口固定	使用者有重複登入或查詢需求	不代表使用者一定會安裝
更新較快	已有穩定部署與測試流程	快取錯誤仍可能讓舊內容殘留
內容可搜尋	公開內容可被爬取與索引	PWA 本身不是直接排名因子

PWA 的限制與風險：哪些地方不能過度期待

PWA 有瀏覽器差異、iOS 行為差異、硬體 API 限制、快取風險與安裝教育成本。若團隊只看到開發成本較低，卻忽略測試與維護，後續容易變成客服與 SEO 問題。

iOS 已支援更多 PWA 能力，但仍要做實機測試

依 WebKit 說明，iOS / iPadOS 16.4 起，加入主畫面的 Web App 支援 Web Push，但通知權限仍需由使用者互動觸發，且要符合 Home Screen Web App 條件。iPhone、iPad、Safari、第三方瀏覽器的安裝流程都要實測。

NFC、藍牙、背景常駐、深度硬體整合仍可能受限

PWA 可使用部分裝置能力，但不能假設所有原生 App 能做的事都能完整搬到 Web。若產品核心價值來自高效能遊戲、長時間背景運作、深度藍牙、NFC 或生物辨識，技術窗口應先列出硬體 API 需求，再決定架構。

快取策略錯誤會讓使用者看到舊內容

快取最怕「該新的沒更新，該保留的被清掉」。電商價格、庫存、會員權益、訂單狀態與表單送出結果，都不適合粗暴快取。我會先要求團隊標記內容類型，再決定 cache-first 或 network-first。

使用者不一定知道可以安裝到主畫面

PWA 需要安裝教育，但不能用干擾式彈窗逼使用者。較好的做法是在完成登入、收藏、預約或購買後，於合理時機提醒「可加入主畫面方便下次使用」。推播也一樣，先讓使用者理解通知價值，再請求權限。

限制或風險	可能造成的問題	補救方式
iOS 與 Android 行為差異	安裝、推播、圖示顯示不一致	用實機測試常見流程
硬體 API 不完整	核心功能無法達到原生 App 體驗	先列功能矩陣，再選 PWA 或原生 App
快取規則錯誤	顯示舊價格、舊內容或錯誤狀態	分離靜態資源、公開內容與會員資料
安裝教育不足	做了 PWA 卻沒人加入主畫面	在高意圖操作後提示安裝

PWA、RWD、Web App、原生 App 怎麼選

若網站只需要瀏覽資訊，先做好 RWD 與速度；若需要登入與資料操作，Web App 是基礎；若需要安裝、離線、推播與回訪，PWA 值得評估；若核心依賴深度硬體或商店曝光，原生 App 較合理。

只需要瀏覽資訊：先做好 RWD

公司介紹、服務頁、作品集、部落格與一次性活動頁，多數情況先把 RWD、內容架構、載入速度與表單體驗做好。若這些基礎沒完成，PWA 只會把問題包進主畫面圖示裡。

需要登入、互動、資料操作：Web App

會員中心、報名系統、訂單查詢、課程後台與企業內部報表，通常先是 Web App 問題。這時要先處理權限、資料同步、表單狀態、錯誤訊息與後台流程，再評估 PWA 能補上哪些體驗。

需要安裝、離線、推播、回訪：PWA

當使用者會重複回來，或任務常在手機上完成，PWA 才開始有明確價值。例如預約提醒、票券查驗、收藏清單、購物車、外勤工單、課程進度與會員點數查詢。

需要深度硬體、高效能或商店曝光：原生 App

若商業策略依賴 App Store 或 Google Play 搜尋曝光，或產品需要高效能繪圖、深度硬體權限、長時間背景服務，原生 App 仍是主要選項。PWA 可以是輔助入口，但不宜硬扛所有核心能力。

方案	適合需求	主要優勢	主要限制
RWD 網站	資訊瀏覽、品牌介紹、SEO 內容	建置清楚、搜尋友善	回訪與離線能力弱
Web App	登入、表單、資料操作	跨平台、維護集中	入口與通知能力有限
PWA	安裝、推播、離線、回訪	兼具 Web 可搜尋與 App 型入口	瀏覽器與硬體能力需驗證
原生 App	高效能、深度硬體、商店曝光	平台整合完整	開發與維護成本較高

台灣企業常見 PWA 適用場景

台灣企業評估 PWA 時，應優先看回訪、會員、預約、電商、票券、課程與內部系統。LINE 官方帳號可以做觸達，但不等於網站體驗；PWA 處理的是使用者回到功能本身的入口與穩定性。

電商與會員中心：收藏、購物車、回訪提醒

電商網站適合把商品列表、收藏、購物車與會員中心做得更快。價格、庫存與結帳資料要以網路優先，圖片與介面資源可快取。若正在規劃平台，可搭配 CMS 選擇指南 檢查內容與商品管理能力。

餐飲與服務業預約：低摩擦入口與通知

餐廳、美容、診所、課程顧問與到府服務，常見需求是預約查詢、時段提醒、候補通知與取消規則。PWA 可以讓使用者把預約入口留在手機主畫面，但通知頻率要克制；我不會把推播當成免費廣告位，權限一旦被關掉，很難再要回來。

活動票券與展覽頁：離線票券或弱網路備援

展覽、講座、市集與演唱活動現場常遇到人潮、地下室或訊號不穩。PWA 可預先快取票券摘要、QR Code 顯示頁或入場說明，但驗票狀態仍應以伺服器為準，避免離線內容和實際狀態不一致。

企業內部系統：報表、工單、外勤查詢

外勤維修、業務拜訪、倉儲盤點與主管報表，常需要在手機上快速查資料。PWA 可以改善入口與弱網路體驗，但權限、資料保存、離線同步與設備遺失風險要先處理，不要把內部後台直接變成可離線的資料包。

台灣場景	為何適合 PWA	注意事項
電商會員	購物車、收藏、訂單查詢需要回訪	價格與庫存不可長時間快取
餐飲預約	主畫面入口與預約提醒有明確價值	推播需由使用者同意
活動票券	現場弱網路時可提供備援	驗票狀態需回伺服器確認
補習班系統	課表、通知、教材與家長查詢會重複使用	學生資料與權限要嚴格控管
企業內部後台	外勤與主管查詢需要快速入口	離線資料範圍要保守

網站要如何加入 PWA 功能

既有網站加入 PWA，順序應是先確認 HTTPS 與 RWD，再建立 Manifest、註冊 Service Worker、設計快取與離線頁，最後用 Lighthouse、Search Console 和實機驗收。先做小範圍功能，比一次把整站都快取更穩。

1. 確認網站已有 HTTPS、RWD 與基本速度。
2. 盤點哪些頁面需要安裝、離線或推播。
3. 建立 Web App Manifest 與 icons。
4. 註冊 Service Worker。
5. 設計快取策略與 offline page。
6. 需要時加入 Web Push 與通知權限流程。
7. 用 Lighthouse、Search Console、iOS 與 Android 實機驗收。

確認網站已是 HTTPS 並具備 RWD

PWA 不該拿來補救爛手機體驗。若手機版排版、表單、選單、字級、速度與無障礙都沒做好，先處理 RWD 和 Core Web Vitals，再加 PWA。

建立 Manifest 與 icons

Manifest 要放在網站可存取的位置，並在 HTML 中引用。icons 要準備多尺寸，避免主畫面圖示模糊或被系統裁切。品牌色、啟動頁與顯示模式也要和網站設計系統一致。

註冊 Service Worker

Service Worker 應先從靜態資源、離線頁和少量公開內容開始，不要一開始就攔截所有請求。會員頁、付款頁、搜尋結果、庫存與價格要特別保守，避免快取讓使用者看到錯誤狀態。

設計快取策略與離線頁

離線頁不需要假裝所有功能都能用，應清楚告知目前無法連線，並提供可重試、可返回、可查看已保存資訊的路徑。好的 offline page 會減少挫折，不會讓使用者以為網站壞了。

需要推播時再加入 Web Push

推播應該對應具體事件，例如預約提醒、訂單狀態、票券入場、課程異動，不適合拿來天天發促銷。通知權限要在使用者完成高意圖操作後再詢問，成功率通常比一進站就跳出權限請求更合理。

用 Lighthouse、Search Console、實機測試驗收

Lighthouse 可檢查安裝性、效能與最佳實務，Search Console 可檢查索引與體驗報表，實機測試則要涵蓋 iOS Safari、Android Chrome、主畫面啟動、離線、推播、登入與更新後快取清除。

PWA 和多媒體嵌入功能怎麼一起做

PWA 可以和 YouTube 嵌入、Vimeo、音訊播放器、Google 地圖、iframe 表單與第三方腳本一起使用，但要控管載入時機、快取範圍、離線 fallback 與 Core Web Vitals。多媒體不是 PWA 的附屬品，會直接影響速度與互動。

嵌入影片或音訊時，不要把第三方資源錯誤快取

YouTube 嵌入、Vimeo、音訊播放器與串流資源通常由第三方平台管理，不應由自己的 Service Worker 粗暴快取。較好的做法是快取頁面框架、縮圖或替代訊息，播放本身交給原平台處理。

iframe、地圖、表單要設定載入時機與 fallback

Google 地圖、第三方表單、訂位系統和客服插件很容易拉高 JavaScript 負擔。可用 lazy loading 延後載入，並提供文字地址、電話、備用連結或離線提示，讓弱網路使用者仍知道下一步。

離線時顯示可理解的替代訊息

離線狀態下，影片、地圖與第三方表單可能無法使用。替代訊息應直接說明「目前離線，影片需連線後播放」或「地圖需網路連線，請先查看地址文字」，不要留下空白 iframe。

多媒體會影響 LCP、INP、CLS，要和 Core Web Vitals 一起測

Google 說明 Core Web Vitals 建議 LCP 在 2.5 秒內、INP 低於 200ms、CLS 低於 0.1。多媒體嵌入常拖慢 LCP，第三方腳本會影響 INP，未保留尺寸的 iframe 會造成 CLS，這些都要和 PWA 驗收一起看。

多媒體類型	PWA 注意事項	離線或弱網路處理
YouTube 或 Vimeo 影片	延後載入 iframe，避免阻塞首屏	顯示縮圖與需連線播放訊息
音訊播放器	不要未經授權快取串流音檔	提供節目摘要或播放失敗提示
Google 地圖	延後載入地圖腳本，保留容器尺寸	顯示地址、電話與外部地圖連結
第三方表單	檢查 iframe 權限與提交狀態	提供備用聯絡方式或稍後再試提示

PWA 對 SEO 有什麼影響

PWA 本身不是 Google 排名保證。SEO 重點仍是內容可爬、可渲染、可索引，URL、title、meta description、canonical 與結構化資料穩定，且 Service Worker 不阻擋 Googlebot 取得最新內容。

PWA 本身不等於 SEO 加分，內容仍要可爬、可渲染、可索引

Google 的 JavaScript SEO 文件提醒，伺服器端渲染或預渲染仍有速度與爬蟲優勢。若重要內容只在登入後、離線快取或客戶端互動後才出現，搜尋引擎不一定能穩定理解。

重要內容不要只在登入後或離線快取中出現

公開商品頁、服務頁、文章、FAQ 與品牌資訊應能直接由 URL 存取。會員資料、訂單與個人化內容可以登入後顯示，但不能拿來承載主要 SEO 關鍵字，否則搜尋頁面會變薄。

URL、title、meta description、canonical 要穩定

PWA 常用前端路由，容易讓 URL、canonical 與 meta 資訊處理不完整。每個可索引頁面都應有穩定 URL、描述性 title、meta description、canonical 與必要的 Article 或 FAQPage 結構化資料。

Service Worker 不應阻擋 Googlebot 取得最新內容

Service Worker 不該把 Googlebot 導向過期快取、離線頁或錯誤狀態。上線後要用 Search Console 檢查檢索與渲染結果，並在快取版本更新時保留回滾策略。對 SEO 來說，PWA 做壞時的傷害通常比做好的加分更明顯。

SEO 面向	PWA 可能影響	建議做法
索引	內容若只靠 JavaScript 產生，可能增加渲染不確定性	重要頁面採 SSR、預渲染或確保渲染後可見
URL 架構	前端路由可能讓頁面訊號混亂	每個主題頁有獨立 URL 與 canonical
Core Web Vitals	快取可改善重複瀏覽，但第三方腳本可能拖慢互動	監測 LCP、INP、CLS 與實際使用者資料
結構化資料	動態注入可能被漏讀	Article 與 FAQPage 優先穩定輸出在 HTML 中
Service Worker	錯誤攔截可能讓爬蟲看到舊內容	避免對爬蟲回傳離線頁或過期版本

PWA 成本、工期與維護項目怎麼估

PWA 成本取決於網站現況、快取複雜度、推播需求、離線資料、跨裝置測試與維護能力。不要用固定報價理解 PWA，應拆成小型升級、中型升級與完整 Web App 升級。

小型升級：Manifest + 基本安裝 + 離線提示

小型升級適合已有 RWD 與 HTTPS 的網站，目標是加入主畫面、品牌圖示、啟動畫面與基本 offline page。它能改善入口，但不會自動讓網站具備完整離線資料或推播能力。

中型升級：快取策略、會員回訪、推播、跨裝置測試

中型升級會碰到 Service Worker、Cache Storage、Web Push、Notifications API、會員狀態與 iOS / Android 測試。這階段最需要產品、行銷與工程一起決定哪些通知值得發，哪些資料不能快取。

大型升級：完整 Web App、離線資料、權限與同步

大型升級可能需要 IndexedDB、背景同步、離線表單、權限控管、衝突處理與內部後台調整。這已經不是「加一個 PWA 功能」，而是 Web App 架構設計，常要和 AI 架站工具 或既有 CMS 能力分開評估。

維護重點：快取版本、瀏覽器支援、內容更新、通知權限

若團隊無法維護版本與回滾，複雜離線能力反而會增加客服問題。PWA 上線後要定期檢查瀏覽器支援、Service Worker 更新、快取清除、通知退訂率、Search Console 與 Core Web Vitals。

等級	常見工作	主要成本來源	維護壓力
小型升級	Manifest、icons、基本離線頁	前端設定與測試	低到中
中型升級	快取策略、推播、會員回訪	前端工程、權限流程、跨裝置測試	中
大型升級	完整 Web App、離線資料、同步機制	架構、後端 API、資料一致性、QA	高
持續維護	快取版本、瀏覽器支援、內容更新	監測、修正、回滾、客服回報	視功能複雜度而定

PWA 上線前檢查清單

PWA 上線前要同時檢查技術、使用者體驗、SEO、多媒體與回滾。只通過 Lighthouse 不夠，因為真實問題常出現在 iPhone 安裝、推播權限、快取更新與第三方嵌入。

技術檢查

先確認 HTTPS、Manifest、icons、Service Worker 註冊、offline page、快取版本與錯誤處理。開發站和正式站要分開，避免測試用 Service Worker 污染正式環境。

使用者體驗檢查

檢查加入主畫面流程、啟動畫面、登入狀態、離線提示、返回按鈕、表單錯誤、推播訂閱與退訂。最不該省的是實機測試，尤其 iPhone 和 Android 的安裝流程差異。

SEO 檢查

確認公開內容可索引，title、meta description、canonical、結構化資料、robots.txt、HTTP 狀態碼與內部連結正常。若網站同時重做架構，可把 PWA 驗收和 網站速度檢查 放在同一輪。

多媒體嵌入檢查

檢查影片 iframe、音訊播放器、Google 地圖、第三方表單和客服腳本是否延後載入，是否保留尺寸，離線時是否有替代訊息。不要讓一個地圖嵌入拖垮整個首頁 LCP。

維護與回滾檢查

上線前要有清除 Service Worker、更新快取版本、撤回推播、回復舊版與通知客服的流程。沒有回滾計畫的 PWA，上線後每一次快取錯誤都會變成現場壓力。

類別	檢查項目	狀態
技術	HTTPS、Manifest、icons、Service Worker、offline page 已完成
使用者體驗	iOS、Android、桌機安裝與啟動流程已測
推播	權限請求、通知內容、退訂流程已測
SEO	可爬取、可渲染、可索引，canonical 與結構化資料正常
多媒體	影片、地圖、表單有 lazy loading 與 fallback
維護	快取版本、回滾、錯誤監測與客服說明已準備

哪些情況不建議優先做 PWA

一次性形象頁、沒有回訪需求、核心依賴 App 商店、預算不足、缺乏維護能力或公開內容不可索引時，不建議優先做 PWA。先把 RWD、速度、內容與基本轉換流程做好，通常更實際。

只有品牌形象曝光，先做好 RWD 與速度

若網站目標只是品牌介紹、案例展示或一次性活動曝光，PWA 的安裝、離線與推播價值有限。這類網站更該先投資內容架構、載入速度、表單轉換與手機閱讀體驗。

核心功能依賴 App Store 生態，先評估原生 App

若成長來源需要 App Store 或 Google Play 的搜尋、榜單、評價、訂閱與平台內曝光，PWA 無法完整替代商店生態。這時可以保留網站作為 SEO 與導流入口，再評估原生 App 的投入。

沒有維護能力，不要硬做複雜快取與推播

沒有工程維護、QA、監測與客服流程時，複雜快取和推播會製造新問題。最後的決策很直接：展示型網站先做好 RWD 與速度；需要回訪、安裝、離線、推播的網站，再把 PWA 放進升級清單。

不適合情境	原因	較合理的優先順序
一次性形象頁	使用者回訪需求低	RWD、速度、內容與表單
重度硬體整合	PWA API 支援可能不足	原生 App 或混合架構評估
沒有維護人力	快取與推播需要持續管理	先降低網站複雜度
內容不可索引	SEO 效益受限	先整理公開內容與 URL 架構

PWA 是什麼？

PWA 是 Progressive Web App，中文常稱漸進式網頁應用。它是用 Web 技術打造的網站或 Web App，但加入可安裝、離線、快取、推播與主畫面入口等能力，讓使用者在手機上得到更接近 App 的體驗。

PWA 跟一般網站差在哪？

一般網站多半依賴瀏覽器瀏覽；PWA 可加入主畫面，搭配 Web App Manifest、Service Worker、離線頁、快取與推播通知。差異不只在外觀，而是在回訪、弱網路與使用任務是否更順。

PWA 可以取代原生 App 嗎？

部分情境可以，例如會員中心、預約系統、活動票券、內容平台與企業內部查詢。若產品需要深度硬體整合、高效能遊戲、長時間背景常駐或 App Store 曝光，原生 App 仍可能更適合。

PWA 一定要有 Service Worker 嗎？

若要形成完整 PWA，Service Worker 是核心元件之一。它負責攔截請求、管理快取、處理離線回應與支援部分背景能力。只有 manifest 和圖示，通常只能算有安裝外觀，還不算完整體驗。

網站加到主畫面就是 PWA 嗎？

不一定。加入主畫面只是入口能力，還要看網站是否有正確的 Manifest、Service Worker、離線頁、快取策略、更新機制與良好的手機體驗。只有捷徑圖示，使用上仍可能只是一般網站。

PWA 對 SEO 有幫助嗎？

PWA 可能透過速度、回訪與使用體驗間接幫助網站，但它不是直接排名保證。SEO 仍要看內容品質、可爬取性、可渲染性、索引狀態、URL 架構、canonical、結構化資料與 Core Web Vitals。

台灣中小企業適合做 PWA 嗎？

有回訪、會員、預約、電商、通知、票券或內部查詢需求時，台灣中小企業可以評估 PWA。若網站只是形象曝光或單次活動頁，先做好 RWD、速度、內容與表單通常更值得。

PWA 可以做推播通知嗎？

可以，但必須取得使用者同意。iOS / iPadOS 16.4 起，加入主畫面的 Web App 支援 Web Push，但權限請求仍需來自使用者互動。推播應用在訂單、預約、票券與課程提醒，不適合濫發促銷。

PWA 開發成本會比 App 低嗎？

多數情境下，PWA 因為可共用網站技術與單一程式碼基礎，維護可能比同時做 iOS、Android 與網站輕。但若涉及離線資料、推播、同步、權限和跨瀏覽器測試，仍需要正式預算。

PWA 可以和影片、地圖、表單嵌入一起用嗎？

可以。YouTube、Vimeo、音訊播放器、Google 地圖和第三方表單都能和 PWA 共存，但要處理 lazy loading、第三方腳本、iframe 尺寸、快取範圍、離線 fallback 與 Core Web Vitals。