Meeting minutes
start the meeting
sisidovski: (presents the slides) https://
sisidovski: FYI the "Cost of ServiceWorker Bootstrap" slides are after some microoptimizations we worked on over the last year
keita: (takes over slide presenting from "Many components in static routing API")
keita: "Proposal for Resource Timing API" slide: origin trial coming soon
sisidovski: "Feedback is welcomed" slide---context on "how to handle unsupported router features" is a network timing condition.
<jbroman> I thought it referred to the Network Information API, which is not supported in all engines?
^ yes that
sisidovski: "Interoperability" context: it's in the SW spec but we'd love to hear about other browser vendors' plans
sisidovski: let's do Q&A now for static routing, then go on to other service worker features
youenn: Apple expressed support last year. We're closer to implementing now. At this point we'd like to know how the WPTs are, what live websites we can test and do measurements on.
youenn: the current scope in the spec is good. We like cache, fetch, and network; not sure about race. If you have measurements showing that it's widely used and widely useful, that would be good for us to know and might impact our plans.
sisidovski: we have WPTs that should cover most behaviors, fully in the web-platform-tests/wpt directory.
<sisidovski> Static Routing API demo: https://
<sisidovski> chromestatus link using Static Routing API https://
Domenic: youtube.com is a good one
<jbroman> but https://
sisidovski: no current stats on race, only a few sites use it, but we can work on getting more data
wanderview: from my experience youtube loves cross-browser support so would be excited to work with WebKit
<Keita> WPT tests: Most of the static router WPTs are moved out of /tentative. e.g.) https://
Erik: at the lower levels of the network connections we race, but the principle that makes this OK is that we only do multiple things in parallel in the exceptional case, not the common case. Is there anything we should do in this context so that if people chose the race rule, are we expecting that once this gets to the worker it does one network request instead of two? Is there a way to bias this e.g. give the worker a 5 ms
headstart? Some way of ensuring that 80% of the time we're not doing twice as much work? Bringing up the network has power, CPU cost
wanderview: in the past at Mozilla they introduced racing between HTTP cache and network (outside of service worker). This gave benefits. In general the long tail devices can benefit from this. Safari devices might not have as much of a benefit.
Erik: we do spend a good amount of effort on the oldest devices
Erik: some of the efficiency concerns depend on what the service worker will do after the race
Randell Jesup: we see network winning on SSDs too, not just old devices.
youenn: sometimes we race service worker and network when the service worker is not running in Safari today. A race between JavaScript and networking. Hopefully the UA is free to not race if it thinks it's a bad deal.
Erik: probably not generally a huge concern, we just should think about it and allow some leeway for UAs to do the right thing, or be sure that following the spec exactly is not a big problem
youenn: for subresource cases races are often fine
sisidovski: (moves on to "New ideas" slides)
explainers-by-googlers/
sisidovski: "ServiceWorker Synthetic Response" slide: API shape not settled yet but the basic idea of providing some stuff ahead of time via static routing API is like this.
wanderview: have you thought about what happens if the network response does something contradicting, e.g. redirecting to a different origin?
sisidovski: we want to err on the safe side, so we'd discard the committed renderer process, basically restart the navigation.
jbroman: there are a long list of headers to handle, e.g. Location, Content-Disposition, Content-Type. Content-Security-Policy. Network interruptions.
youenn: if the idea is to give a hint for process swap, I think it's fine to give a hint to the UA. If the idea is to go further and start doing rendering and so on, I'm less sure about that. It's also interesting to measure how much benefit this gives.
Domenic: can you give more detail on what Chrome does before commit?
sisidovski: process allocation, "local frame context initialization"... 40 ms median time on Android.
wanderview: your AppShell slide reminds me of early days of ServiceWorker where Facebook would stream the head of the document from cache, and stream the rest of the body from network. They said it was a significant win at the time. Moving something like this into the browser could be a big win. Reduce complexity.
Domenic: any thoughts about service worker auto preload?
youenn: seems good. We're doing something similar. The heuristic is different but the principle is the same. Our current heuristic is whether service worker is running or not running, targeting navigations not subresources. We're interested in hearing measurement results and websites where tweaking the heuristic would help.
RRSAgent: generate minutes