Re: [w3c/ServiceWorker] allow service worker produced resources to be marked as "cachable" (#962)

I'm also pretty sure Chromium has similar caches for JS (parsed/compiled)
which were disabled for SW. Not sure if still disabled, but I saw an issue
about it some day.

On Aug 25, 2016 10:17 PM, "Ben Kelly" <notifications@github.com> wrote:

The main cache people think about in the browser is the http cache. Service
worker sits on top of the http cache and all SW invoked fetch() calls go
through it. This is well and good.

There are, however, additional caches within a browser. For example, both
images and stylesheets have some form of memory caching spec'd within a
document. These sit above the network and service worker layers.

It might be nice to provide a way for a service worker to indicate a
particular Response won't change as long as the SW is in control. For
example, a pre-cached asset. This would allow the browser to keep these
assets in higher level memory caches. They could then be re-used without
paying the cost of firing a FetchEvent or pulling the resource out of Cache
API. These assets would have to be invalidated from the memory caches if
the service worker became redundant (e.g. updates, unregister, etc).

You can see how effective these caches can be in #756 (comment)
<https://github.com/w3c/ServiceWorker/issues/756#issuecomment-242217294>.
The benchmark loads from image cache anywhere from 35ms to 150ms. This is
in comparison to the 300+ms required using a caching service worker.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/w3c/ServiceWorker/issues/962>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABIlkU-p11ha4ILhVd8bRdDC6AKgJa5nks5qjepTgaJpZM4JtaJI>
.


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