Advanced Questions About Service Worker

[novaknole]

Hi @jakearchibald @surma @mbrookes , These are some of my questions that I have been struggling to find any answer on stackoverflow with no luck for a very long time. So I think This is my last chance here since you're very experienced and one of the maintainers for service worker. I know this is not the right place to ask it here, but I think this is because I've tried everything else.

Let's go down.

Question 1) Let's say browser requests a index.js file . There are different steps involved where this file should be brought from. So , let's take a look at scenario where browser first goes to check if the file is present there and if not, where it goes next.

• Memory Cache -> Service Worker -> Disk Cache -> Network

  This is the sequence I think is most valid. Do you agree?

Question 2) Now, I found out the following about Safari on MacOS.

I went to the page for the first time, service worker's install event gets called and things get precached from there (I checked and they are precached). Now, I refreshed the page and looking at network tab, requests all get returned from Service Worker in transfer column. Now, I refresh Again and it looks like some of those files, I'd say 80% gets returned from memory cache (that's what network's transfer size column says in safari. I am wondering why they get returned from memory cache after 2 refreshes? It seems like that now, I get an assumption that i can't full control some requests via service worker. First, I was thinking maybe safari browser's transfer column size shows wrong information, but I tried to test it like this:

I registered fetch listener and put console.log(e.request.url) there. After I refresh my website 2 times where transfer column shows that items get returned from memory cache, it seems like fetch listener doesn't get called for those urls that get brought from memory which makes my point that some of the urls don't get controlled after 2 refreshes and they keep coming back from memory cache. On chrome, this behaviour doesn't happen. What could be the case?

Question 3) I know There're so many discussions about this, but I want to hear your advice on this. Let's make the comparison between caching things via cache api and caching things via indexeddb in service worker. Let's say I have an api endpoint /users which returns json of users. Now, I can achieve the same functionality with caching these data via Cache API and cache.add and not use indexeddb at all. And it will still work offline. but still, people say it's better to use indexeddb for json data. I can't clearly see what advantages indexeddb provides in this scenario. I mean (real advantage) and not just some ideas. So, just want to know your opinion on this.

[jakearchibald]

Closing since this is nothing to do with this library.

[jakearchibald]

So , let's take a look at scenario where browser first goes to check if the file is present there and if not, where it goes next.

• Memory Cache -> Service Worker -> Disk Cache -> Network

This is the sequence I think is most valid. Do you agree?

Roughly. There's a diagram on https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/ which is a little more complete.

I'd say 80% gets returned from memory cache (that's what network's transfer size column says in safari. I am wondering why they get returned from memory cache after 2 refreshes?

The memory cache isn't spec'd, but please file bugs with Safari if you don't think these things should be happening. It's worth verifying that these things are actually coming from the memory cache rather than just being misreported by devtools.

Let's say I have an api endpoint /users which returns json of users. Now, I can achieve the same functionality with caching these data via Cache API and cache.add and not use indexeddb at all. And it will still work offline. but still, people say it's better to use indexeddb for json data. I can't clearly see what advantages indexeddb provides in this scenario.

The cache API stores HTTP responses which can be queried by request. IndexedDB stores structured clonable data and can be indexed and queried multiple ways.

If you need the extra features of IndexedDB, it might be worth breaking out an HTTP JSON response into individual objects and putting them in an IDB object store. If not, it isn't worth it.

[novaknole]

Looks like the second question is really critical. I filed a bug and I will post an answer here when I get it.

[novaknole]

@jakearchibald One thing i might add though, is that if item ends up in memory cache and if memory cache is before service worker in the sequence of which cache browser checks first, then what safari shows is a perfectly valid option. Why does chrome not show the same thing?

If you imagine this scenario:

we request style.css and script.js . Service worker gets installed, it precached these files. Now, we request it again. and they get fetched from service worker. At this stage, browser might have cached it in memory cache. So If I refresh it again, they might be fetched from memory instead of Service Worker. . Why does chrome show that they get fetched from Service Worker all the time? Does this mean that if I use service worker, they don't end up in memory cache at all? Really interesting.

[jakearchibald]

The memory cache is not spec'd

[novaknole]

what do you mean in simple words?

[jakearchibald]

A specification defines how something should work. There's no specification for memory cache. So browsers all behave differently.

[novaknole]

yeah, it makes sense. but my worries is that if request first goes to memory cache before service worker and retreives it from there, it seems like the assumption is I can't control my requests with service worker. Does it make sense?

[jakearchibald]

It depends how the memory cache works

[novaknole]

Any idea from google chrome perspective?

[jakearchibald]

Are you seeing an issue in Chrome?

[novaknole]

Nope, but I'd love to know why it doesn't appear. Looks like maybe chrome gives more priority to service worker than memory cache?

[jakearchibald]

Memory caches are usually before service worker. If Chrome isn't getting something from a memory cache, it's likely because it isn't there. But again, it isn't spec'd, so I'm only guessing.

[novaknole]

So, if your last guess is correct, it proves that we can't control everything over service worker. for example javascript file if it ends up in memory cache. and I think It might end up somehow.