Service Worker 是一項功能強大的工具，可讓網站離線運作，並自行建立專屬快取規則。Service Worker fetch 處理常式會查看所控制網頁中的所有要求，並判斷是否要透過 Service Worker 快取提供回應，或是重新編寫網址，以完全擷取不同的回應 (例如根據本機使用者的偏好設定)。
不過，如果網頁一段時間正好首次載入，且控制 Service Worker 目前並未執行，服務工作站可能會產生效能成本。由於所有擷取作業都必須透過 Service Worker 進行，因此瀏覽器必須等待 Service Worker 啟動並執行，才能知道要載入什麼內容。對使用服務工作處理程序的開發人員透過快取策略提升效能的開發人員來說，這種啟動成本可能很低，但也很重要。
導覽預先載入是解決問題的方法之一，可讓系統同時透過網路發出導覽要求，以便同時啟動 Service Worker 工作，但只會在初始導覽要求中加入服務工作處理程序，並且在重要路徑中納入 Service Worker。自導覽預先載入功能推出後，我們已多次努力為問題空間開發更通用的解決方案，包括部分要求在服務工作站啟動時不會遭到封鎖的方法。
Service Worker Static 轉送 API
從 Chrome 116 開始，可使用實驗性的 Service Worker Static 轉送 API，來測試這類解決方案的第一個步驟。安裝 Service Worker 後，即可使用 Service Worker Static 轉送 API，宣告應如何擷取特定資源路徑。
在 API 的初始版本中，路徑可以宣告為一律從網路提供，而非服務工作站。稍後載入受控制的網址時，瀏覽器可以在服務工作站啟動之前，就開始從這些路徑擷取資源。如此可將 Service Worker 從已知不需要 Service Worker 的路徑中移除。
如要使用 API，Service Worker 會使用一組規則對 install 事件呼叫 event.registerRouter：
self.addEventListener('install', event => {
if (event.registerRouter) {
// Go straight to the network and bypass invoking "fetch" handlers for all
// same-origin URLs that start with '/form/'.
event.registerRouter([{
condition: {
urlPattern: {pathname: '/form/*'},
},
source: 'network',
}]);
}
});
每項規則通常都有兩個屬性：
condition：指定何時套用規則，使用 URL Pattern API 比對資源路徑。屬性可使用URLPattern例項，或與傳入URLPattern建構函式相容的對等純物件 (例如new URLPattern({pathname: '*.jpg'})或僅{pathname: '*.jpg'})。網址模式的彈性，意味著規則能夠比對出最具體且精細的條件，就像路徑中的任何資源一樣。一般來說，對於熱門轉送程式庫的使用者，應會熟悉這類模式。
source：指定如何載入符合condition的資源。目前系統僅支援'network'值 (略過 Service Worker 直接透過網路載入資源)，但我們預計日後會將此值擴展到其他值。
用途
如上所述，API 的初始版本基本上是服務工作站控制中某些路徑的跳轉機制。至於何時適合使用，端看您如何使用 Service Worker 以及使用者瀏覽網站的方式。
舉例來說，如果您的網站使用快取優先策略 (改回網路)，但有些內容的造訪頻率極少，完全沒有或完全沒有價值 (例如封存內容或 RSS 動態消息)。您只能在 Service Worker 中設定限制從網路擷取的路徑，但服務工作站仍需要啟動及執行，才能決定如何處理這些要求。
相較之下，靜態轉送 API 會利用幾個宣告行，完全略過 Service Worker：
self.addEventListener('install', event => {
if (event.registerRouter) {
event.registerRouter([{
condition: {
urlPattern: {pathname: '/feeds/*.xml'},
},
source: 'network',
}, {
condition: {
urlPattern: {pathname: '/archives/*'},
},
source: 'network',
}]);
}
});
隨著 Service Worker Static 轉送 API 的發展，這項計劃的目的是讓這項設定變得更有彈性，並支援更多情境，例如使用宣告式競爭網路擷取服務和 Service Worker 啟動。詳情請參閱規格說明：如何探索可能的 API「最終形式」。
試用 Service Worker Static 轉送 API
Chrome 中的 Service Worker Static Routing API 自來源試用第 116 版起開放使用，可讓開發人員在自家網站上邀請實際使用者測試 API，藉此評估成效。如需來源試用的背景資訊，請參閱「開始使用來源試用」一文。
進行本機測試時，可以使用 chrome://flags/#service-worker-static-router 旗標或透過 --enable-features=ServiceWorkerStaticRouter 等指令執行 Chrome，藉此啟用 Service Worker Static 轉送 API。
意見回饋與未來路線指引
Service Worker Static Routing API 仍在開發中，且仍在開發中。如果對您有幫助，請透過來源試用試用，並針對 API、實作和可用功能提供意見回饋。