[w3c/ServiceWorker] Questions regarding inevitable nature of performance gains and losses of ServiceWorker (Issue #1667)

Hi! Apologies in advance for the super lengthy post.

I've been doing some intensive research and experiments how I can make the most out of Service Workers and stumbled upon a couple of performance related questions, and felt the necessity to get some expert inputs. What I'm about to explain here may look like they're not necessarily be relevant to the spec but rather an implementation details, although it still seemed to me that the issues are heavily related to the very nature of Service Worker, thus I've decided to post it here. If they still seem irrelevant after all,  perhaps if anyone can point me to somewhere more appropriate that would be extremely helpful. 

## Q1

Based on what I can confirm, I see that installing a Service Worker that does pretty much nothing would still have some extra end-to-end overhead. (I was using [SW Benchmark](https://jakearchibald.github.io/service-worker-benchmark/) by @jakearchibald , but could confirm this in my SW as well.) Of course, there's some extra JavaScript code that gets executed, thus the extra overhead is understandable. Although, the actual latency I'm seeing seems a bit too much for an "empty" or "pass-through" handlers, like 30-40ms, and wanted to know if Service Worker was specced or built taking this fact for granted.

More specifically, I can understand that leveraging cache can significantly improve a site's performance when the device is connected to a network with mid-to-low bandwidth/speed, which is absolutely great. But, when the network speed is fast enough (like 100+M/bps) this "pass-through" overhead can not only diminish the performance gain but potentially make it worse than not having any Service Worker code and/or returning data from cache. So, my question is: Was the intension of inventing Service Worker and its capability to serve content from cache to mainly improve performance under mid-to-poor network environments?

Related topics: 

- https://github.com/w3c/ServiceWorker/issues/1584#issuecomment-1006063126
  - I'm assuming that the motivation behind what @noahlemen did was close to what I'm addressing here.
- https://stackoverflow.com/questions/50938919/why-network-first-strategy-is-slower-than-no-service-worker
  - I understand the question is about Workbox, but to me it seemed like more of fundamental/architectural issue with Service Workers in general, thus the reference.

## Q2

The Cache API (and it's back-end storage: Cache Storage) resides within the Service Worker spec, and it appears to be the de facto storage when using Service Worker for cache purposes storing different resources/responses. Although, I have observed that the storage I/O is pretty significant as large as 10-50ms, and this I/O overhead could greatly offset the performance gain of having the cached data. 

This leads me to think that I could just keep everything in-memory of Service Worker and forget about the storage. I am aware that this would have significant impact on the capabilities of what the Service Worker can achieve, for instance losing cached data in the following session. Yet, considering the inevitable overhead of the Cache Storage I/O I'm more leaning towards the idea that there should be something like a on-memory storage API to fully leverage the caches. I personally see in-session user experience is more important than what's carried over across multiple sessions, and wanted to seek advice from experts if there's any room for this to be discussed as part of the spec, or rather a browser specific feature.

If there had been some kind of an architectural and/or spec related decision like "caches should/must be persisted to disk (= Cache Storage)" I'd love to know, if not I'm curious to know your thoughts on this. Or if anyone can point out to me the downsides of the idea to keep things in-memory, that would also be great.

## Q3

Based on my thoughts described in Q2, I was curious what would happen when the Service Worker thread uses excessive amount of memory by running the following code:

```js
arr = []; while(1) { arr.push("foo"); }
```

I see that with Chrome not only the Service Worker thread crashes, but also the parent/client renderer process (the tab) crashes. This must be specific to Chromium's architecture and process model, but I believe this is far from how it should be. I mean, based on my little knowledge, I personally think it's much better to let the Service Worker process/thread crash just by itself without causing the original tab to crash, UX wise and security wise. (I am no security expert, so correct me if I'm wrong.) 

My question here is: Is there any room for the spec to define something around what should happen when a Service Worker exhausts its memory, or perhaps a more general scenario of when it stops or crashes? If this is something that I should report to https://bugs.chromium.org/ then I'm happy to do so.

---

That's all I got to say for now. Kudos to everyone for expanding the capabilities of the web and making this exciting feature happen!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1667
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1667@github.com>