在多來源網站建構漸進式網頁應用程式時，會遇到的挑戰和解決方法。
發布日期：2019 年 8 月 19 日
過去，使用多來源架構有一些優點。對漸進式網頁應用程式來說，這種做法會帶來許多挑戰。尤其是同源政策，會限制共用 Service Worker 和快取、權限等內容，以及在多個來源之間實現獨立體驗。
瞭解多個來源的優缺點，並說明在多來源網站中建構漸進式網頁應用程式的挑戰和解決方法。
多個來源的優缺點
網站採用多來源架構有幾個合理原因，大多與提供獨立的網頁應用程式組合，或建立完全獨立的體驗有關。此外，也應避免某些用途。
優良範例
首先，請查看實用原因：
本地化/語言：使用國家/地區代碼頂層網域，區隔在不同國家/地區提供的網站 (例如
https://www.google.com.ar)，或使用子網域區隔指定不同地區的網站 (例如：https://newyork.craigslist.org) 或提供特定語言的內容 (例如https://en.wikipedia.org)。獨立網頁應用程式：使用不同子網域提供體驗，其目的與主要來源網站有很大差異。舉例來說，在新聞網站中，填字遊戲網頁應用程式可以刻意從
https://crosswords.example.com提供，並安裝及做為獨立 PWA 使用，不必與主網站共用任何資源或功能。
缺點
如果您沒有進行上述任何操作，那麼在建構漸進式網頁應用程式時，使用多來源架構可能會是不利的做法。
儘管如此，許多網站仍繼續採用這種結構，原因不明或只是「沿用舊制」。例如，使用子網域任意分隔網站中應屬於統一體驗的部分。
舉例來說，我們極不建議採用下列模式：
網站區段：在子網域上分隔網站的不同區段。在新聞網站中，首頁通常位於
https://www.example.com，而體育版面位於https://sports.example.com，政治版面位於https://politics.example.com，以此類推。以電子商務網站為例，產品類別可使用https://category.example.com，產品頁面則可使用https://product.example.com。使用者流程：另一種不建議的做法是將網站的不同部分分開，例如將登入或購買流程的頁面放在子網域中。例如，使用
https://login.example.com和https://checkout.example.com。
如果無法遷移至單一來源，以下列出建構漸進式網頁應用程式時可能遇到的問題，以及可行的解決方法 (如有)。
不同來源 PWA 的挑戰和解決方法
在多個來源上建構網站時，提供統一的 PWA 體驗相當困難，主要是因為同源政策會施加多項限制。以下逐一介紹。
Service Worker
Service Worker 指令碼網址的來源必須與呼叫 register() 的網頁來源相同。舉例來說，這表示 https://www.example.com 的網頁無法使用 https://section.example.com 的 Service Worker 網址呼叫 register()。
另一個考量是，Service Worker 只能控制託管於其所屬來源和路徑下的頁面。也就是說，如果 Service Worker 託管於 https://www.example.com，則只能控制該來源的網址 (根據範圍參數中定義的路徑)，但無法控制其他子網域中的任何頁面，例如 https://section.example.com 中的頁面。
在這種情況下，唯一的解決方法是使用多個 Service Worker (每個來源一個)。
快取
Cache 物件、indexedDB 和 localStorage 也僅限單一來源。也就是說，您無法從 https://www.section.example.com 等位置存取屬於 https://www.example.com 的快取。
在這種情況下，您可以採取下列做法，妥善管理快取：
善用瀏覽器快取：建議一律採用傳統瀏覽器快取最佳做法。這項技術還能跨來源重複使用快取資源，這是 Service Worker 快取無法做到的。如要瞭解如何搭配使用 HTTP 快取和 Service Worker，請參閱這篇文章。
讓 Service Worker 安裝作業保持輕量：如果您維護多個 Service Worker，請避免讓使用者每次前往新來源時，都要支付高昂的安裝費用。換句話說，請只預先快取絕對必要的資源。
權限
權限也限定於來源。也就是說，如果使用者將特定權限授予來源 https://section.example.com，該權限不會沿用至其他來源，例如 https://www.example.com。
由於無法跨來源共用權限，唯一的解決方法是在需要特定功能 (例如位置) 的每個子網域上要求權限。如果是網頁推播等功能，您可以保留 Cookie，追蹤使用者是否已在其他子網域接受權限，避免再次要求權限。
安裝
如要安裝 PWA，每個來源都必須有自己的資訊清單，且 start_url 必須相對於自身。也就是說，如果使用者在特定來源 (例如 https://section.example.com) 收到安裝提示，就無法在其他來源 (例如 https://www.example.com) 安裝含有 start_url 的 PWA。
換句話說，如果使用者在子網域收到安裝提示，就只能安裝子頁面的 PWA，無法安裝應用程式主網址的 PWA。
此外，如果每個子網域都符合安裝條件，並提示使用者安裝 PWA，則同一位使用者在瀏覽網站時，可能會收到多個安裝提示。
如要解決這個問題，請確保提示只顯示在主要來源上。使用者造訪符合安裝條件的子網域時：
- 監聽
beforeinstallprompt事件。 - 防止提示出現，呼叫
event.preventDefault()。
這樣一來，您就能確保提示不會顯示在網站的非預期部分，同時繼續在主要來源 (例如首頁) 顯示提示。
獨立模式
在獨立視窗中瀏覽時，如果使用者移出 PWA 資訊清單設定的範圍，瀏覽器的行為會有所不同。實際情況取決於各瀏覽器版本和供應商。舉例來說，在最新版 Chrome 中，當使用者在獨立模式下離開範圍時，系統會開啟 Chrome 自訂分頁。
在大多數情況下，這個問題無法解決，但如果只有一小部分體驗託管於子網域 (例如登入工作流程)，則可採用以下解決方法：
- 新網址
https://login.example.com可以在全螢幕 iframe 中開啟。 - 在 iframe 中完成工作 (例如登入程序) 後，您可以使用 postMessage()，將 iframe 中的任何結果資訊傳回上層網頁。
- 最後，主頁面收到訊息後，即可取消註冊事件監聽器，並從 DOM 中移除 iframe。
結論
同源政策對多來源網站設下許多限制，導致這類網站難以提供一致的 PWA 體驗。因此，為提供使用者最佳體驗，強烈建議不要將網站分成不同來源。
如果現有網站已採用這種方式建構，要讓多來源 PWA 正常運作可能會很困難，但我們已探索一些可行的解決方法。每種方法各有利弊，請根據您的判斷，決定要在網站上採用哪種方法。
評估長期策略或重新設計網站時，除非有重要原因需要保留多來源架構，否則建議遷移至單一來源。
感謝以下人員提供技術審查和建議：Penny Mclachlan、Paul Covell、Dominick Ng、Alberto Medina、Pete LePage、Joe Medley、Cheney Tsai、Martin Schierle 和 Andre Bandarra。