未缓存的请求能否绕过服务人员

Question

最近，我采用了 Service Worker，通过缓存优先策略来加速初始 HTML 加载：

function cacheFirst () { /* ... */ }

self.addEventListener('fetch', (event) => {
    const { request } = event
    if (request.mode === 'navigate' && request.method === 'GET') {
        event.respondWith(cacheFirst(event))
    }
})

正如预期的那样运行良好且很酷。

但是，当我使用 Chrome 开发工具观察我的网站性能时，我发现一些非常烦人的事情：我对我的 restful api 服务器的所有请求都由一个小而明显的 service worker 开销。

我看到我所有的安静请求都首先发送给我的服务人员。并且因为这些请求不打算被缓存，fetch 事件处理程序只是忽略该事件（不调用event.respondWith）。然后由浏览器自己发出正常请求。

让我恼火的是，到服务人员的这个空往返大约需要 15-40 毫秒（在我的 Android 手机上高达 80-200 毫秒）。这对我来说很荒谬，我试图通过消除缓存结果的 304 响应来节省大约 15-40ms，但在请求动态数据时引入了 15-40ms 的延迟。

我尝试只为我不喜欢缓存的请求调用 event.respondWith(event.request)，但与移除服务工作者相比，我仍然可以观察到一些开销。

function cacheFirst () { /* ... */ }

self.addEventListener('fetch', (event) => {
    const { request } = event
    if (request.mode === 'navigate' && request.method === 'GET') {
        event.respondWith(cacheFirst(event))
    } else {
        event.respondWith(fetch(request))
    }
})

我搜索了网络，并没有看到类似的关于这种性能缺陷的担忧（这让我想知道服务人员真的在现实世界中使用过）。

除了我的故事之外，我的问题是：我可以在请求 RESTful api 时绕过 service worker（我只是确定它不应该被缓存），同时仍然保留好处用于可缓存的资源。

Answer 1

（您可能会发现 Chrome 开发者峰会上的 this recent talk 很有趣，因为它更详细地涵盖了相同的领域。）

您说得对，将 service worker 置于您的网络应用和网络之间会产生开销，而且在速度较慢的设备/速度较慢的存储上，这种开销可能会更大。

理想情况下，如果您能够响应缓存中的“重要”请求，Service Worker 将加速您的网络应用的整体性能。例如，您可以缓存优先响应导航请求，这意味着重复访问者应该比其他方式更快地看到他们屏幕上的内容。

但是您最了解您的网络应用的网络流量模式，并且如果您的网络应用发出的大多数请求都是针对不可缓存的远程 API 调用，那么增加的服务工作人员开销可能会超过您从中获得的收益缓存本地资产。并不是每个 Web 应用都属于这一类，是的，有很多“现实世界”的服务工作者部署性能积极。一个收集值得注意的例子的网站是https://www.pwastats.com/

至于您关于绕过服务工作者获取您知道无论如何都必须访问网络的 URL 的具体问题，目前没有可用的解决方案。 Service Worker 标准组正在就解决方​​案进行一些头脑风暴，其中可能涉及一种在注册 Service Worker 时传递“路由”信息的方式，如果请求与路由不匹配，则导致 Service Worker 不会拦截请求。你可以阅读更多关于它的信息，如果你觉得你有什么要补充的，可以参与：https://github.com/w3c/ServiceWorker/issues/1026