若有任何問題請來信：gss_crm@gss.com.tw
PWA 於 Service Worker註冊後，可以於其生命週期內做初步的網頁功能暫存。尤其是Fetch事件時間點，可以針對所有所發的request來判斷是否要將其資源站存起來。
乍看起來非常方便，只要巡覽到某功能的頁面都可以將相關的資源暫存起來，但是如果系統有很多支的頁面，例如有50支功能，要將所有暫存起來不含失敗也至少要點50次。如果又加上權限的控管，例如本月的權限只能使用10個功能頁面，下個月因故又新增新功能至20個頁面，又要在手動點了10次才能完整將所有功能都暫存起來。
所以需要在安裝或更新的時機來做整個系統的功能暫存是比較好的選擇。而安裝所要做的事項大致如下:
安裝時會有N個步驟要執行，而進行系統功能的暫存會放在最後一個步驟。
這邊假設每個頁面在剛開始時讀取時程式不會做太耗時的工作 (因為資料已經暫存在本機端)，定義最大的耗時為3秒，之後會參考這個值。
能夠於安裝頁面自動將系統的功能都暫存起來，這邊目前是用iframe來讀取每個頁面。而必須於版本更新安裝時，先從伺服器讀取員工的權限能使用的功能清單，然後依照清單數目逐一讀取功能頁面，讓每個頁面都去執行Service Worker的Fetch事件來暫存頁面資源。
首先準備好新增iframe函式:
之後依照程式清單數量，逐一產生iframe並將功能設定至其src處:
目前為止是將功能整批快速的讓各個iframe去讀，但是還CPU沒有那麼多個，會有許多工作需要等待，所以最後再加上一個等待的時間當作保險。而此時間就是之前提到的 3秒 乘上 功能數量。等待的程式如下:
FunctionList是功能清單的集合，FunctionList.length 即為數量。每個給消耗的時間為3秒。 所以添加的保險等待時間為 (FunctionList.length * 3) 秒。
如此執行暫存最大的缺點是，無法確認每個功能最大的消耗秒數為何。另外不確定因素是，每種裝置的CPU效能不見得都很好，其記憶體也不見得都很充足，除非做安裝時都可以放下手邊正在執行的工作，否則每支功能最大的校耗時間保守估計也要提高。
另外一點是，前端頁面設計寫法非常多樣，加上可能會有多個工程師的各種風格，無法確切評估頁面會占用多少記憶體與執行讀取時花費多少CPU，人為因素與需求複雜度不是能夠完整掌握。
如果還有更好的方式會再更新出來。