Can uncached requests bypass service workers

Question

Recently, I adopted service worker to speed up initial HTML load by using a cache first strategy:

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

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

It worked well and cool as expected.

But then when I observed my site performance with Chrome dev tool, I found something very annoying: All my requests to my restful api server are prepended by a small but obvious service worker overhead.

I see that all my restful requests goes first to my service worker. And because these requests are not meant to be cached, the fetch event handler just ignores the event (no call to event.respondWith). Normal request is then emitted by the browser it self.

What's annoying me is that this empty round trip to the service worker takes about 15-40ms (goes up to 80-200ms on my Android phone). This is quite ridiculous to me, I tried to save some 15-40ms by eliminating the 304 response for cached results, but introduced 15-40ms delay when requesting dynamic data.

I tried to just call event.respondWith(event.request) for requests that I don't like to cache, but I can still observe some overhead compared to having the service worker removed.

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))
    }
})

I searched the web and didn't see similar concerns about this performance pitfall (which makes me wonder IS SERVICE WORKERS REALLY USED IN REAL WORLD).

Aside from my story, my question is: Can I just bypass the service worker when requesting a restful api (which I'm just sure it shouldn't be cached), while still preserving benefits for cacheable resources.

Answer 1

(You might find this recent talk at the Chrome Developer Summit interesting, as it covers the same ground in more detail.)

You're correct in that there's an overhead involved with putting the service worker in between your web app and the network, and that this overhead can be larger on slower devices/slower storage.

Ideally, a service worker will speed up your web app's overall performance if you're able to respond to "important" requests from the cache. The fact that you can respond to navigation requests cache-first, for instance, means that repeat visitors should see content on their screens much more quickly than they would otherwise.

But you know your web app's network traffic patterns the best, and if the majority of the requests that your web app makes are for remote API calls that aren't cacheable, the added service worker overhead might outweigh the benefits you get from caching local assets. Not every web app falls into that category, and yes, there are plenty of "real world", performance-positive deployments of service workers. One site collecting noteable examples is https://www.pwastats.com/

As for your specific question about bypassing the service worker for URLs that you know will have to go to the network anyway, there is not currently a solution available. The service worker standards group is brainstorming a bit about solutions involving, potentially, a way of passing in "route" information when registering a service worker, leading to the service worker not intercepting a request if it doesn't match a route. You can read more about it, and participate if you feel like you have something to add: https://github.com/w3c/ServiceWorker/issues/1026