如要充分利用讓 PWA 穩定、可安裝和強大功能的技術，那麼在設計應用程式時，必須先瞭解應用程式的限制和限制，並選擇適合兩者的架構。
SPA 與 MPA
目前，網頁開發有兩種主要的架構模式：單頁應用程式 (SPA) 和多頁應用程式 (MPA)。
單頁應用程式的定義是讓用戶端 JavaScript 根據擷取或提供給應用程式的資料，控制網頁的大部分或所有 HTML 轉譯作業。應用程式會覆寫瀏覽器的內建導覽功能，並替換為其轉送和檢視處理功能。
多頁面應用程式通常會將預先算繪的 HTML 直接傳送至瀏覽器，並在瀏覽器載入 HTML 後，使用用戶端 JavaScript 進行強化，並依賴瀏覽器內建的導覽機制來顯示後續檢視畫面。
這兩種架構皆可用於建立 PWA。
每種方法各有優缺，因此請根據您的用途和情境，選擇合適的做法，為使用者提供快速可靠的體驗。
單頁面應用程式
- 大多是原子網頁內更新。
- 啟動時載入的用戶端依附元件。
- 後續載入作業會因為使用快取而快速完成。
- 初始載入成本高。
- 效能取決於裝置硬體和網路連線。
- 應用程式複雜度越高，
單頁應用程式適合以下架構：
- 使用者互動主要是以同一個網頁上顯示的互連資料為主，例如即時資料資訊主頁或影片編輯應用程式。
- 應用程式有僅限用戶端的初始化依附元件，例如第三方驗證服務供應商，其啟動成本過高。
- 檢視區塊載入所需的資料取決於特定的用戶端專屬情境，例如顯示已連結硬體的控制項。
- 應用程式體積小且簡單，因此其大小和複雜度不會影響上述缺點。
如果符合下列情況，SPA 可能不是理想的架構：
- 初始載入效能至關重要。SPA 通常需要載入更多 JavaScript，才能決定要載入哪些內容，以及如何顯示。結合此 JavaScript 的剖析和執行時間以及擷取內容，比傳送轉譯的 HTML 慢。
- 您的應用程式主要在低功耗至中等功耗的裝置上執行。由於 SPA 會使用 JavaScript 進行轉譯，因此使用者體驗會比 MPA 更明顯地受到特定裝置效能的影響。
由於 SPA 需要使用路由取代瀏覽器內建的導覽功能，因此 SPA 需要具備最低程度的複雜度，才能有效更新目前檢視畫面、管理導覽變更，以及清除瀏覽器原本會處理的先前檢視畫面，整體而言更難維護，對使用者的裝置造成的負擔也更大。
多頁面應用程式
- 大多是全頁更新。
- 初始算繪速度至關重要。
- 用戶端指令碼是一項增強功能，
- 次要檢視畫面需要其他伺服器呼叫。
- 內容不會在檢視畫面之間保留。
- 需要伺服器或預先轉譯。
如果符合下列條件，多頁應用程式就是不錯的架構選擇：
- 使用者互動主要圍繞單一資料的檢視畫面，以及可選的依情境而異的資料，例如新聞或電子商務應用程式。
- 初始轉譯速度至關重要，因為將已轉譯完成的 HTML 傳送至瀏覽器，比起在載入、剖析及執行以 JavaScript 為基礎的替代方案後，從資料要求中組合 HTML 更快。
- 在初始載入後，您可以將用戶端互動或內容納入為強化功能，例如在轉譯的網頁上疊加設定檔，或是新增次要的用戶端依內容而異的元件。
在下列情況下，MPA 可能不是理想的架構選擇：
- 重新下載、重新剖析及重新執行 JavaScript 或 CSS 所費不貲。在 PWA 中，服務工作站可減輕這項缺點。
- 用戶端內容 (例如使用者位置) 無法在檢視畫面之間順暢轉移，重新取得該內容可能會耗費大量資源。您必須擷取並擷取資料，或是在檢視畫面之間重新要求。
因為個別檢視畫面需要由伺服器動態轉譯，或在存取前預先轉譯，因此可能會限制代管或增加資料複雜度。
要選擇哪一個？
即使採用上述優缺點，只要兩種架構都有效，即可建立您的 PWA。您可以根據需求，根據應用程式的不同部分混用這兩種模式。舉例來說，讓商店資訊遵循 MPA 架構，且結帳流程遵循 SPA 架構。
無論您選擇哪種做法，下一步都應瞭解如何最佳運用服務工作者，以提供最佳體驗。
Service worker 的強大功能
Service Worker 不但基本轉送與傳送快取和網路回應，還提供許多功能。我們可以建立複雜的演算法，改善使用者體驗和成效。
Service worker 包含 (SWI)
使用 Service Worker 做為網站架構的組成部分，新興的模式包括服務工作人員 (SWI)。SWI 會根據快取需求，將個別素材資源 (通常為 HTML 網頁) 分割成多個部分，然後在服務工作站中將這些部分重新拼接，以改善一致性、效能和可靠性，同時縮減快取大小。
這張圖片是範例網頁。其中包含五個不同部分，將網頁分成以下幾個部分：
- 整體版面配置。
- 全域標頭 (頂端深色橫條)。
- 內容區域 (中間左線和圖片)。
- 側欄 (右中間的深灰色高欄)。
- 頁尾 (深色底部列)。
整體版面配置
整體版面配置不太可能經常變更，且沒有任何依附元件。建議您採用預先快取功能。
頁首和頁尾
全域頁首和頁尾包含頂端選單和網站頁尾等內容，並帶來特殊挑戰：如果網頁是整個快取，則這些內容可能會在網頁載入期間變更，具體取決於特定網頁的快取時間。
將這兩者分開，並獨立於內容快取，即可確保使用者無論何時快取，都會取得相同的版本。因為這類更新並不常更新，因此也適合預先快取。不過，它們具有相依性，例如網站的 CSS 和 JavaScript。
CSS 和 JavaScript
在理想情況下，網站的 CSS 和 JavaScript 應納入過時的快取，同時重新驗證策略，以允許漸進式更新而不需更新 Service Worker，這點和預先快取資產的情況相同。不過，服務工作者更新為新的全域標頭或標尾時，也必須維持最低版本。因此，服務工作者安裝時，也應更新快取，以便使用最新版本的素材資源。
內容區域
接著是內容區域。視更新頻率而定，在重新驗證時選擇網路或過時。如先前討論的，圖片應採用快取優先策略進行快取。
側欄
最後，假設側欄內容包含標記和相關項目等次要內容，則不必從網路中提取。Stale while revalidate 策略適用於此情況。
完成所有操作後，您可能會認為這類快取功能只能用於單頁應用程式。不過，只要採用以邊緣端 include (或伺服器端包含) 為靈感的模式，即 Service Worker 中的部分進階 Service Worker 功能，上述任一架構都適用。
親自試試
您可以透過下一個程式碼研究室，試用服務工作者包含的內容：
串流回應
在 SPA 世界中，您可以使用應用程式殼層模型建立先前的頁面，其中會先快取應用程式殼層，然後提供服務，並在用戶端載入內容。隨著 Streams API 的推出和廣泛應用，應用程式殼層和內容可在服務工作者中合併，並串流傳輸至瀏覽器，讓您享有應用程式殼層的快取彈性，以及 MPA 的速度。
原因如下：
- 串流也能以非同步的方式建構，讓串流的不同部分能從其他來源流傳。
- 串流要求者可以在第一個資料區塊可用時立即開始處理回應，而不需要等待整個項目完成。
- 針對串流最佳化的剖析器 (包括瀏覽器) 可以在串流完成前逐步顯示內容，加快回應的效能。
由於串流有這三種特性，因此以串流為基礎的架構通常比其他架構擁有更快的效能。
Streams API 複雜且層級較低，因此使用起來可能會有些困難。幸好，Workbox 模組可協助您為服務工作程式設定串流回應。
網域、來源和 PWA 範圍
網路工作站 (包括服務工作站、儲存空間，甚至是已安裝的 PWA 視窗) 都受到網路上最重要的安全機制之一：同源政策的規範。在同一來源中，系統會授予權限、共用資料，而 Service Worker 則可與不同的用戶端通訊。在不同來源之間，系統不會自動授予權限，且資料會處於隔離狀態，無法在不同來源之間存取。
同來源政策
如果兩個網址的通訊協定、通訊埠和主機相同，就會定義為具有相同來源。
例如：https://squoosh.app 和 https://squoosh.app/v2 有相同的來源，但 http://squoosh.app、https://squoosh.com、https://app.squoosh.app 和 https://squoosh.app:8080 則來自不同來源。如要瞭解更多資訊和範例，請參閱同來源政策 MDN 參考資料。
變更子網域並非主機唯一可變更的方式。每個主機都由頂層網域 (TLD)、次要層級網域 (SLD) 和零個或多個標籤 (有時稱為子網域) 組成，這些標籤之間以點號分隔，並在網址中由右至左讀取。變更任何項目都會導致主機變更。
在視窗管理模組中，我們已瞭解使用者從已安裝的 PWA 前往其他來源時，應用程式內瀏覽器的樣貌。
即使網站具有相同的 TLD 和 SLD，但由於標籤不同，這個應用程式內瀏覽器也會視為不同的來源。
在網路瀏覽情境中，來源的其中一個重要層面是儲存空間和權限的運作方式。一個來源會在其中的所有內容和 PWA 之間共用許多功能，包括：
- 儲存空間配額和資料 (IndexedDB、Cookie、Web 儲存空間、快取儲存空間)。
- Service Worker 註冊。
- 授予或拒絕的權限 (例如網路推送、地理位置、感應器)。
- 網路推播註冊。
從一個來源移至另一個來源時，系統會撤銷先前的所有存取權，因此必須重新授予權限，且 PWA 無法存取儲存空間中的所有資料。