這份說明文件先前已涵蓋預先快取內容，但不清楚如何正確執行。這點非常重要，因為無論您是否使用 Workbox，都很容易預先快取過多資料，而且可能會浪費資料和頻寬。請務必謹慎處理預先載入酬載對使用者體驗的影響。
閱讀這份文件時，請留意這些只是一般準則。按照應用程式架構和需求，您採取的做法可能與本文建議有所不同，但這些指南很適合做為預設用途。
行動：預先快取重要的靜態資產
最適合預先快取的項目是關鍵靜態資產，但哪些要素會計為「重要」素材資源呢？從開發人員的角度來看，您可能會想將整個應用程式視為「關鍵」，但使用者的角度才是最重要的。請將「關鍵資產」視為提供使用者體驗所需的迫切資產：
- 全域樣式表。
- 提供全域功能的 JavaScript 檔案。
- 應用程式殼層 HTML (如果適用於您的架構)。
貼心小提醒：以上僅為一般準則，並非硬性建議。預先快取資產時，最好將資源集中在預先快取，而非不要超過。
必要：針對多網頁網站預先快取離線備用
針對一般的多網頁網站，您可能需要採用網路優先或僅限網路的快取策略來處理瀏覽要求。
在這種情況下，建議您確保服務工作處理程序在使用者離線提出導航要求時，預先快取，並以離線備用頁面回應。如要在 Workbox 中執行這項動作，其中一個方法可能是使用具有離線備用網路的純網路策略，並善加利用導覽預先載入功能：
import {PrecacheFallbackPlugin, precacheAndRoute} from 'workbox-precaching';
import {registerRoute, Route} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
import * as navigationPreload from 'workbox-navigation-preload';
navigationPreload.enable();
// Ensure that /offline.html is part of your precache manifest!
precacheAndRoute(self.__WB_MANIFEST);
// The network-only callback should match navigation requests, and
// the handler for the route should use the network-only strategy, but
// fall back to a precached offline page in case the user is offline.
const networkOnlyNavigationRoute = new Route(({request}) => {
return request.mode === 'navigate';
}, new NetworkOnly({
plugins: [
new PrecacheFallbackPlugin({
fallbackURL: '/offline.html'
})
]
}));
registerRoute(networkOnlyNavigationRoute);
這樣可以確保使用者在離線後前往未快取的頁面時，至少會取得一些離線內容。
建議做法：考慮採用推測性預先快取
那是一大「或許」但預先快取有「可能」在特定情況下使用的素材資源。您不妨這樣想：使用者可能會額外下載一些資料，這有助於加速處理這些資產的要求。
請特別注意，如果要這麼做，請「非常」。然而，要浪費資料並不容易，您應該根據資料做出明智決策。此外，請避免以推測性的方式預先快取經常變更的資產，因為每次預先載入的程式碼每次偵測到新的修訂版本時，使用者都會產生額外的資料用量。觀察數據分析中的使用者流程，瞭解使用者通常前往何處。如果您對於以推測為方式預先快取資產有任何疑慮，這可能是「避免」這樣做的好跡象。
不一定：友善載入靜態 HTML
本指南特別適用於靜態網站，這些靜態網站是由靜態網站產生器產生或手動建立，而不是由應用程式後端動態產生或提供。若您的架構符合上述規定，那麼沒有預先快取網站的每個 HTML 檔案可能最為理想。
如要預先快取整個網站的 HTML 檔案，現在系統一律會從快取提供預先快取的標記，直到 Service Worker 更新為止。這樣做可提升效能，但如果網站的 HTML 程式碼經常變更，可能會導致快取大量流失。
但這項規則有幾個例外情況。如果您部署了幾個靜態 HTML 檔案的小型網站，建議您預先快取所有網頁，方便離線使用。如果您的網站規模特別大，請考慮刻意預先快取一些高價值的網頁並離線備用，然後依賴執行階段快取來快取其他網頁。
請勿：友善快取回應式圖片或網站小圖示
這種做法不是一般原則，而是製訂其他的規則。回應式圖片是一種複雜的解決方案，可以解決複雜的問題：許多裝置的使用者各有不同的螢幕尺寸、像素密度和替代格式，如果您友善載入整組回應式圖片，可能是因為使用者只下載了其中一張回應式圖片，
錯誤也面臨類似的情況，網站通常會針對各種情況部署整組網站小圖示。大多數的情況下，系統通常只會要求一個網站小圖示，以類似的方式預先快取整個網站小圖示集。
務必讓使用者感到賓至如歸，不要預先快取回應式圖片和網站小圖示集。改為仰賴執行階段快取。如果你「必須」預先快取圖片，則可預先快取不屬於回應式圖片或網站小圖示構成的廣泛使用圖片。可擴充向量圖形在資料使用方面的風險較低，因此無論特定螢幕的像素密度為何，單一 SVG 會以最佳方式轉譯。
不要：友善載入 polyfill
對 API 而言，改變瀏覽器支援往往是網頁程式開發人員常面臨的挑戰，而 Polyfilling 正是其中之一。如要盡可能降低 polyfill 的效能成本，其中一種方法是檢查功能，並只為需要 polyfill 的瀏覽器載入 polyfill。
由於目前環境的執行階段有條件載入 polyfill，因此預先快取 polyfill 可以一次處理。這對部分使用者來說可獲益，而其他使用者則會耗費頻寬浪費在非必要的 polyfill 中。
不要預先快取 polyfill。請運用執行階段快取，確保只在需要這些程式碼的瀏覽器中取得快取，以免浪費資料。
結論
要預先闢謠需要預先考慮使用者實際需要哪些資產，但您可以確定在優先考慮未來效能與可靠性的方式中，確實做到這一點。
如果不確定是否要預先快取特定資產，最好的方式就是要求 Workbox 排除這些資產，並建立執行階段快取路徑來處理這些資產。無論您選擇哪一種做法，這份說明文件後續都會詳細說明如何進行預先快取，方便日後將這些原則套用到預先快取邏輯。