服務工作者是一項強大的工具，可讓網站在離線狀態下運作，並為自己建立專屬的快取規則。服務工作者 fetch 處理常式會看到所控網頁的每項要求，並可決定是否要從服務工作者快取中提供回應，甚至重寫網址來擷取完全不同的回應，例如根據本機使用者偏好設定。
不過，如果網頁在一段時間內首次載入，而控制 Service Worker 的服務目前並未執行，Service Worker 可能會產生效能成本。由於所有擷取作業都必須透過服務工作者執行，瀏覽器必須等待服務工作者啟動及執行，才能得知要載入哪些內容。對於使用服務工作者來透過快取策略改善效能的開發人員而言，這項啟動成本雖然不高，但卻相當重要。
導覽預先載入是解決這個問題的一種方法，可讓導覽要求透過網路傳送，並與服務工作者啟動作業並行，但這項方法僅限於初始導覽要求，且仍會在關鍵路徑中納入服務工作者。自導覽預先載入功能推出以來，我們已進行多項努力，為問題領域開發更通用的解決方案，包括讓某些要求在服務工作者啟動時不受阻斷。
Service Worker 靜態轉送 API
從 Chrome 116 開始，實驗性的 Service Worker Static Routing API 可用於測試這類解決方案的第一步。安裝服務工作者後，服務工作者可以使用 Service Worker Static Routing API，以宣告方式指出應如何擷取特定資源路徑。
在 API 的初始版本中，您可以宣告路徑一律從網路 (而非 Service Worker) 提供。稍後載入受控網址時，瀏覽器可以在服務 worker 啟動完畢前，開始從這些路徑擷取資源。這麼做會從您知道不需要服務工作者的路徑中移除服務工作者。
如要使用 API，服務工作架構會在 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'值 (略過服務工作者，直接透過網路載入資源)，但我們計畫將這項功能擴展至其他值。
用途
如先前所述，初始版本的 API 基本上是服務工作站控制某些路徑的逃逸管道。這項功能的使用方式取決於您使用服務工作者的方式，以及使用者瀏覽網站的方式。
舉例來說，如果您的網站採用快取優先策略 (改用網路)，但某些內容的瀏覽次數極少，因此快取的價值不大 (例如封存的內容或 RSS 動態消息)，您只能在服務工作者中設定限制從網路擷取這些路徑的功能，但服務工作者仍必須啟動並執行，才能決定如何處理這些要求。
相反地，靜態路徑 API 會透過幾行宣告式程式碼完全略過服務工作者：
self.addEventListener('install', event => {
if (event.registerRouter) {
event.registerRouter([{
condition: {
urlPattern: {pathname: '/feeds/*.xml'},
},
source: 'network',
}, {
condition: {
urlPattern: {pathname: '/archives/*'},
},
source: 'network',
}]);
}
});
隨著服務工作者靜態路由 API 的演進，這項設定將變得更靈活，並支援更多情境，例如以宣告方式競爭網路擷取和服務工作者啟動。詳情請參閱規格說明，瞭解 API 的潛在「最終形式」。
試用 Service Worker 靜態轉送 API
自 Chrome 116 版起，Service Worker Static Routing API 就已開放使用，但必須先進行原始試驗，開發人員才能在自己的網站上測試 API，並透過實際使用者評估成效。如要瞭解原點測試的背景資訊，請參閱「『開始進行原點測試』」。
如要進行本機測試，您可以使用 chrome://flags/#service-worker-static-router 中的標記啟用 Service Worker Static Routing API，也可以透過 --enable-features=ServiceWorkerStaticRouter 中的指令執行 Chrome。
意見回饋和未來方向
我們正積極開發 Service Worker Static Routing API，且仍在調整中。如果您認為這項功能對自己有幫助，請透過原生測試試用，並針對 API、導入方式和可用功能提供意見回饋。