- From: Vladan Djeric <notifications@github.com>
- Date: Wed, 04 Oct 2017 21:31:49 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/1195/334356037@github.com>
Hey all, I'm Vlad, I work on Facebook's WebSpeed team with Benoit. The fundamental motivation for this request for new APIs is that a do-nothing Fetch handler is pretty slow today. It's slow because: * Responding to a Fetch request can require launching a ServiceWorker. And launching a ServiceWorker often takes 200ms+ on my MacBookPro. I double-checked the numbers using @jakearchibald 's ServiceWorker benchmark above and it's consistent with numbers from our ServiceWorker. In Chrome, some of that time goes toward spawning a new process, a new thread, setting up the execution environment etc. And all this happens before any ServiceWorker JavaScript gets to execute. * Even if the needed ServiceWorker is already running, no-op Fetch events still take tens of milliseconds from Fetch request to Fetch response on my machine. I haven't looked closely enough at why this is, but I would assume IPC overhead, overhead of switching contexts, etc. The numbers from the field are even worse. So when a ServiceWorker's Fetch handler is no longer needed, we end up with non-negligible overheads on every Fetch request without getting any benefit in return. Additionally, I am assuming that just optimizing the browser's implementation can't significantly reduce these overheads (e.g. make them consistently < 10ms) because spawning processes and threads and JS execution contexts just seems like a non-trivial amount of work for a CPU so it would be hard to make it consistently fast. Benoit wrote a pretty exhaustive list of situations when a ServiceWorker's Fetch handler would no longer be needed, but I think the main use-case (for us) is when main-thread Fetch requests can no longer be responded to from the ServiceWorker's cache because the cache contents are out of date, e.g. JS code files were added to the SW cache on Oct 1st, but it's currently Oct 4th and we don't want the ServiceWorker serving cached code files from anytime before October 2nd because of severe bugs in the old cached client code or because of incompatibilities between the old cached client code and newer server code. So the requirement really is to make "pass-through" Fetches very cheap somehow. -- 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/1195#issuecomment-334356037
Received on Thursday, 5 October 2017 04:32:29 UTC