為了充分利用能充分運用 PWA 的技術,讓 PWA 穩定、可安裝且功能強大,首先要瞭解應用程式本身及其限制,然後為這兩種應用程式選擇合適的架構。
SPA 與 MPA
現今的網站開發中有兩種主要架構模式:單頁應用程式、SPA 中心、多頁面應用程式或 MPA。
單頁應用程式的定義方式為:根據由應用程式擷取或提供給應用程式的資料,使用用戶端的 JavaScript 控制大部分或所有 HTML 轉譯功能。應用程式會覆寫瀏覽器的內建導覽功能,將其取代為本身的轉送和檢視處理功能。
多頁面應用程式通常會預先轉譯 HTML 直接傳送至瀏覽器,通常在瀏覽器載入 HTML 之後,以用戶端 JavaScript 加以強化,並透過瀏覽器內建的導覽機制來顯示後續的檢視畫面。
這兩種架構都可用於建立 PWA。
兩者各有優缺點,選擇適合的用途和情境,是為使用者提供快速可靠的體驗的關鍵。
單頁應用程式
- 大部分都是不可分割的網頁內更新。
- 啟動時載入的用戶端依附元件。
- 由於使用快取,後續載入的速度會很快。
- 初始載入成本很高。
- 實際效能取決於裝置硬體和網路連線。
- 必須使用額外的應用程式複雜度。
若是以下情況,單頁應用程式是絕佳架構的需求:
- 使用者互動主要是以相同頁面 (例如即時資料資訊主頁或影片編輯應用程式) 的互連資料更新為主。
- 應用程式具有僅限用戶端的初始化依附元件,例如啟動成本過高的第三方驗證服務供應商。
- 載入檢視畫面所需的資料取決於特定的用戶端內容,例如顯示部分連接硬體的控制項。
- 應用程式小巧且簡單,因此不會對上述缺點造成影響。
若發生以下情況,則 SPA 可能不適合架構:
- 初始載入效能至關重要。SPA 通常需要載入更多 JavaScript,才能判斷要載入的內容和顯示方式。這個 JavaScript 的剖析和執行時間結合擷取內容,比傳送轉譯的 HTML 慢。
- 應用程式主要在低到平均的裝置上執行。由於 SPA 仰賴 JavaScript 進行算繪,因此使用者體驗的決定遠比 MPA 多,遠遠取決於特定裝置的效能。
由於 SPA 需要將瀏覽器內建的導覽功能替換為其轉送機制,因此 SPA 需要最複雜的層面,包括有效率地更新目前檢視畫面、管理導覽變更,以及清除原本會由瀏覽器處理的檢視畫面,使整體的維護和負擔在使用者裝置方面變得更加困難。
多頁面應用程式
- 大部分為整頁更新。
- 初始轉譯速度非常重要。
- 用戶端指令碼也可以是增強功能。
- 次要檢視畫面需要其他伺服器呼叫。
- 結構定義不會在檢視畫面之間轉移。
- 需要伺服器或預先算繪。
在下列情況下,多頁面應用程式是不錯的架構選擇:
- 使用者互動主要聚焦在查看單一資料與比對內容相關資料,例如新聞或電子商務應用程式。
- 初始轉譯速度非常重要,因為在載入、剖析及執行以 JavaScript 為基礎的替代程式碼後,比起從資料要求組合出已轉譯的 HTML,初始顯示速度會更快。
- 在初次載入後,可將用戶端互動或內容納入強化效果,例如將個人資料疊加到轉譯的網頁,或是新增次要的用戶端內容相關元件。
若發生以下情況,就不適合使用 MPA 架構:
- 重新下載、重新剖析及重新執行 JavaScript 或 CSS 的費用昂貴。在使用 Service Worker 的 PWA 中可以減輕這種缺點。
- 用戶端的背景資訊 (例如使用者位置) 無法在檢視畫面之間順利切換,而且重新取得這類資訊的費用可能相當高昂。需要擷取和擷取串流,或在不同的檢視畫面之間重新要求。
因為個別檢視畫面必須在存取前由伺服器動態算繪,或在存取前預先算繪,因此可能限制託管作業或增加資料複雜度。
請問要選擇哪一個?
即使有上述優缺點,這兩種架構都有助於建立 PWA。您甚至可以根據需求,針對應用程式的不同部分混用這些參數。舉例來說,假設您在商店資訊採用 MPA 架構,而結帳流程符合 SPA 架構,就可以採用這種做法。
無論選擇哪一種,下一步就是瞭解如何充分運用 Service Worker,進而提供最佳體驗。
Service Worker 的效能
除了基本轉送與傳送快取和網路回應之外,Service Worker 還有許多效能。我們可以建立複雜的演算法,改善使用者體驗和執行效能。
Service Worker 包括 (瑞士)
將 Service Worker 做為網站架構的重要部分,新的模式為 Service Worker 包含 (瑞士戰爭)。SWI 會根據自家的快取需求將個別資產 (通常是 HTML 網頁) 分割成多個部分,接著將這些資產拼接回服務工作處理程序中,改善一致性、效能和穩定性,同時降低快取大小。
這張圖片是範例網頁。其中包含五個不同部分,將網頁細分為:
- 整體版面配置。
- 全域標頭 (頂端深色長條)。
- 內容區域 (中間線條和圖片)。
- 側欄 (右側半深的中等深色長條)。
- 頁尾 (深色底部列)。
整體版面配置
整體版面配置不太可能經常變更,也沒有依附元件。因此很適合考慮進行預先快取。
頁首和頁尾
全域標頭和頁尾含有頂端選單和網站頁尾等資訊,並存在一項特定挑戰:如果這是整個網頁快取,則視快取指定網頁的時間而定,網頁載入時間可能會有所變動。
只要將這些 API 與內容區隔開來並分別快取,即可確保使用者無論何時進行快取,取得的同一個版本一律相同。這些更新檔案不常更新,因此很適合預先快取。但具有依附元件:網站的 CSS 和 JavaScript。
CSS 和 JavaScript
在理想情況下,網站的 CSS 和 JavaScript 應存有過時的快取,並重新驗證策略,這樣就能在無需更新 Service Worker 的情況下啟用漸進式更新,如同使用預載素材資源的情況一樣。不過,每當 Service Worker 加入新的全域標頭或頁尾,也必須保留最低版本。因此,Service Worker 安裝時也應將快取的資產更新為最新版本的資產。
內容區域
接著是內容區域視更新頻率而定,建議先讓網路優先或過時 (重新驗證時) 才是很好的策略。如同先前的討論所述,請使用快取優先策略快取圖片。
側欄
最後,假設側欄內容包含標記和相關項目等次要內容,則沒有必要從網路提取。而重新驗證策略後就適合使用這類畫面。
完成所有說明後,您可能會認為自己只能針對單頁應用程式執行這種每節快取作業。然而,只要採用以 edgeSide include 或 serverside include 為靈感的模式,搭配一些進階 Service Worker 功能,您就能針對任一架構執行這項操作。
親自試試
您可以在下一個程式碼研究室中試用 Service Worker 內含項目:
串流回應
您可以使用 SPA 環境中的應用程式殼層模型建立上一頁,並在快取後快取應用程式殼層,然後在用戶端載入內容。隨著 Streams API 的推出和廣泛的可用性,應用程式殼層和內容都可以在服務工作站中合併,並且串流至瀏覽器,讓您享有應用程式殼層的快取彈性,以及 MPA 的速度。
原因如下:
- 串流能以非同步方式建立,讓不同的串流片段來自其他來源。
- 第一個資料區塊可供使用後,串流要求者便可立即開始處理回應,而無需等待整個項目完成。
- 針對串流最佳化的剖析器 (包括瀏覽器),可以在完成串流前逐步顯示串流內容,加快回應的效能。
多虧了上述三種串流特性,以串流為基礎的架構通常能更快速地獲得成效。
Streams API 相當複雜,因此使用起來相當棘手,幸好,Workbox 模組可協助您為服務工作站設定串流回應。
網域、來源和 PWA 範圍
網路工作站,包括服務工作站、儲存空間,甚至是已安裝的 PWA 視窗,都受到網路上最重要的安全機制之一:相同來源政策的規範。在同一來源中,系統會授予權限,資料則可與不同的用戶端通訊。在同一來源之外,系統不會自動授予權限,資料也會隔離,且無法在不同來源之間存取。
同源政策
如果通訊協定、通訊埠和主機相同,則兩個網址都定義了確切的來源。
舉例來說: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、網頁儲存空間、快取儲存空間)。
- Service Worker 註冊。
- 授予或拒絕的權限 (例如網路推送、地理位置、感應器)。
- 網路推播註冊。
移動到另一個來源時,系統會撤銷原先的所有存取權,因此必須重新授予權限,PWA 也將無法存取儲存在儲存空間中的所有資料。