- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 29 Jul 2014 21:56:12 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: Jake Archibald <jaffathecake@gmail.com>, public-script-coord <public-script-coord@w3.org>
On Tue, Jul 29, 2014 at 12:47 PM, Ian Hickson <ian@hixie.ch> wrote: > On Tue, 29 Jul 2014, Jake Archibald wrote: >> New tabs using that ServiceWorker may be open or may open while you're >> blocking. Baaaaad slowwww baaaad. > > I totally agree that it'd be bad to be slow (though honestly, a sync call > to a local database isn't generally going to be slower than a network > request, so it's not really "slow" by the standards relevant here). While it's generally faster than the network request itself, it's much slower than returning an *instruction* to make a network request, which is what a service worker actually does. > But > what are you going to do to prevent it? Unless you enforce latency > requirements on any ServiceWorker call, you're not going to avoid > slowness. You don't need a sync call for script to be slow. An author > could easily just serialise all requests, or not service them promptly, or > perform heavy long computation, or do any number of other bad things to > get slow results. Service workers must be robust to be being killed at any time, so latency requirements might be used. > And I don't think latency requirements are really going > to help either -- sure, you can enforce that each call into the > ServiceWorker returns fast, but you can't enforce how long it takes to get > the first byte of actual data back (since it might depend on the network), > and that's all that actually matters. Of course, but you also want the first byte of the *next* network request to show up as quickly as possible, and allowing the first request to hang the thread with a sync XHR means that you fail at that. ~TJ
Received on Wednesday, 30 July 2014 04:57:03 UTC