Re: [w3c/ServiceWorker] consider allowing multiple worker thread instances for a single registration (#756)

Some other random observations from the measurements:

1. Comparing the caching-worker to the data URL worker can show us the impact of Cache API.  The data URL worker is about 50ms faster in FF51, 50ms faster in Chrome 52, and 70ms faster in Chrome Canary 54.  So using Cache API to load these 300 small images takes ~50ms to 70ms.  (Of course, spinning up the data URL service worker script itself will take longer.  We're just moving where the disk read happens.)
2. Opening a new tab with no service worker and a hot http cache is roughly equivalent to the caching-worker case.  For http cache FF takes 459ms, chrome 52 takes 356ms, and chrome canary 54 takes 328ms.  Chrome is only about 20ms or 30ms slower with a running service worker.  FF is faster with a service worker because we avoid a ton of main thread jank in our network stack that we hit with the http cache loads.
3. Opening a new tab with no service worker in the same process that has loaded the page before in firefox is REALLY fast.  Its bi-modal at either ~35ms or ~150ms.  I believe this is the image cache at work.  If we still have decoded data we hit the 35ms number.  If we have to decode again we hit the 150ms.  I think.

The last observation here might actually suggest a new spec addition.  If we allowed a service worker to indicate that the returned Response will not change, then the browser could store it in memory caches for images, stylesheets, etc.  These could then provide big perf wins for loads that occur in the same process (reload, navigation, etc).

The fact that http cache is not much faster suggests to me that static routing may not be much of a perf win.  This does not measure the service worker thread startup costs of course.

-- 
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/756#issuecomment-242276713