Many of you may have thought “Isn’t this what Service Workers are for?” after reading the headline. Yes, this proposal could be about Service Workers, but maybe not. On the Chrome team we’ve identified a set of problems that could be solved by Service Workers, but we feel that there are some downsides to that approach.
Anyways let me expand, here are some of the problems we would like to solve efficiently:
No easy way to control when to fetch and when to process the responses. I often see people confused by the timing of sub-resources fetches and responses handling: “um, why is this image fetched before that stylesheet?” or “gush, why is this script executed before we do X?”. There are some known techniques (e.g. preload and then change rel=) to achieve some ordering, but they don’t always work as intended and even if they work it’s extremely hard to make sure the ordering when third-party libraries and frameworks are involved.
No easy way to rewrite multiple requests in a performant way. A/B testing frameworks are apparently using hacks (e.g. open a textarea tag early-on) to rewrite everything in the document body, but this collides with UA’s preload scanner, which leads to suboptimal performance.
No easy way to bypass service workers for particular requests. We’ve heard some demand for a way to skip service workers for requests that are always meant to go to the network, e.g. video streams. It was once discussed in Service Workers F2F and one of the resolution was to add
service worker modeto Fetch request, but it’s still not possible to apply the mode for resource requests that come from HTML elements or third-party libraries. For those another option could be static routes, while its discussion is still up in the air.
As I wrote in the intro, any of the above be addressed by Service Workers, but there are some downsides or gaps:
- Service Workers can’t be used on the first page load. There’s an issue https://github.com/w3c/ServiceWorker/issues/1282 but it’s not actively discussed.
- Service Workers’ registration model and complex lifetime may not always be worth the trouble if the website owner just want to fiddle with a few sub resources.
- Service Workers are “far” from the document(s), which makes it hard to coordinate the request/response ordering w.r.t. the page’s document state.
- Service Workers can’t observe responses that are returned from caches that sit above Service Workers, e.g. Memory Cache or preload cache.
- While Service Workers have fine control over the network, it doesn’t allow for fine control over the browser’s other most constrained resource: the main thread. Tasks will run unchecked and probably at the wrong time.
These made us wonder if it’s worth having a different, possibly simpler API from Service Workers. E.g. it can just be an inline script (e.g.
<script type=”loading”>...</script>) in the page and just works for all the subresource loading after that. One could also imagine that certain HTML element provide hooks to provide the same level of control.
Thoughts? I and @KenjiBaheux are keen to hear your opinion!