服务工作线程是一款强大的工具，可让网站在离线状态下运行并为自己创建专用缓存规则。服务工作器 fetch 处理脚本会看到其控制的网页发出的每个请求，并可以决定是否要从服务工作器缓存中向其提供响应，甚至可以重写网址以完全提取不同的响应（例如，根据本地用户偏好设置）。
不过，如果页面在很长一段时间内首次加载，并且控制该页面的 Service Worker 目前未运行，则 Service Worker 可能会付出性能代价。由于所有提取都需要通过 Service Worker 进行，因此浏览器必须等待 Service Worker 启动并运行，才能知道要加载的内容。此启动开销可能很小，但对于使用服务工件通过缓存策略提升性能的开发者而言，却很重要。
导航预加载是一种解决此问题的方法，它允许在服务工作线程启动的同时通过网络发出导航请求，但仅限于初始导航请求，并且仍会在关键路径中包含服务工作线程。自导航预加载功能发布以来，我们一直在努力为该问题空间开发更通用的解决方案，包括让某些请求在服务工件启动时完全不会被阻塞的方法。
Service Worker 静态转送 API
从 Chrome 116 开始，实验性 Service Worker 静态路由 API 可用于测试此类解决方案的第一步。安装服务工件后，它可以使用 Service Worker Static Routing API 以声明方式说明应如何提取特定资源路径。
在该 API 的初始版本中，您可以声明路径始终从网络（而非 Service Worker）提供。稍后加载受控网址时，浏览器可以在 Service 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：指定使用 网址 Pattern API 匹配资源路径时应用规则。该属性可以接受URLPattern实例，也可以接受与传入URLPattern构造函数兼容的等效普通对象（例如new URLPattern({pathname: '*.jpg'})或仅{pathname: '*.jpg'}）。网址格式的灵活性意味着，规则可以匹配简单的路径下任何资源，也可以匹配非常具体且详细的条件。常用路由库的用户通常会熟悉这些模式。
source：指定如何加载与condition匹配的资源。目前，仅支持'network'值（绕过服务工件直接通过网络加载资源），但计划未来将其扩展到其他值。
使用场景
如前所述，该 API 的初始版本本质上是针对某些路径的服务工作器控制的逃生舱。在哪些情况下使用此功能才有意义，取决于您使用服务工件的具体方式以及用户浏览您网站的方式。
例如，如果您的网站使用缓存优先策略（回退到网络），但某些内容的访问量非常少，因此将其缓存几乎没有任何价值（例如归档内容或 RSS Feed）。您只能在服务工作器中设置将这些路径限制为仅从网络提取，但服务工作器仍必须启动并运行，才能决定如何处理这些请求。
与之相反，静态路由 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 静态路由 API 的不断发展，我们计划让此配置变得更加灵活，并支持更多场景，例如以声明方式对网络提取和 Service Worker 启动进行竞态。如需了解详情，请参阅规范说明中对 API 可能的“最终形式”的探讨。
试用 Service Worker 静态转送 API
从 Chrome 116 开始，Service Worker Static Routing API 在源代码试用后面提供，这让开发者可以通过真实用户在其网站上测试该 API 以衡量效果。如需了解与源代码试用相关的背景信息，请参阅“开始使用源代码试用”。
对于本地测试，您可以通过 chrome://flags/#service-worker-static-router 中的标志启用 Service Worker Static Routing API，也可以通过命令运行 Chrome（如 --enable-features=ServiceWorkerStaticRouter）来启用该 API。
反馈和未来方向
Service Worker Static Routing API 正在积极开发中，仍处于构建阶段。如果您认为该功能对您有用，请通过源代码试用来试用该功能，并就 API、实现和可用功能提供反馈。