I've made a longer comment on G+, but in short: if you max-age your page for a decent length of time, you lock users into that version of the page. Shipping any kind of update means waiting for that max-age to expire.
Unfortunately, HTTP caches have opaque, browser-provided semantics that work sometimes and mysteriously don't work in other cases.
They can't be used to ensure that you have a complete atomic set of application assets, are often purged in ad-hoc ways by browsers, and in general aren't a good hint to browsers about exactly what the semantics of the caches are.
ServiceWorker gives applications control over many of these considerations in a programmable way. If you've ever tried to work with AppCache or control time-to-boot in the context of possibly-warm HTTP caches, you know that this is a godsend.
Which isn't to say that people shouldn't make the best use of HTTP caches, nor that HTTP caches aren't currently underutilized. It's just to say that the control offered by ServiceWorker will make it far easier to control the nitty-gritty of caching behavior, which matters a lot.
To be clear, my squabble is not an argument against SW in any way. SW affords a lot more control to the developer and makes this pattern significantly simpler to implement and deploy.
I'm simply pointing out that you can get most (if not all) of the claimed perf benefits using existing API's. Yes, it won't look as pretty, but if you want to deliver a better experience to existing + older browsers.. this is something to consider.
As a person who has spent weeks of my life trying to persuade AppCache + HTTP caches to do what I want (and who subsequently became a champion for the low-level primitives that became SW), I just don't agree with this.
It seems true in principle, until you try to actually get precisely the semantics you want, and then things go downhill fast. People should definitely try to find ways to use the HTTP cache more aggressively, but in practice, it's a giant slog with very little cross-browser consistency and total failures on mobile devices.
We should be thinking about how to deliver the best of both worlds: a great experience for older (non-SW) browsers, and an even better experience for those that do. The underlying patterns are effectively the same, SW just makes many things much simpler, and there is no reason to block on SW to start on this path.
7 comments
[ 3.3 ms ] story [ 12.0 ms ] threadThey can't be used to ensure that you have a complete atomic set of application assets, are often purged in ad-hoc ways by browsers, and in general aren't a good hint to browsers about exactly what the semantics of the caches are.
ServiceWorker gives applications control over many of these considerations in a programmable way. If you've ever tried to work with AppCache or control time-to-boot in the context of possibly-warm HTTP caches, you know that this is a godsend.
Which isn't to say that people shouldn't make the best use of HTTP caches, nor that HTTP caches aren't currently underutilized. It's just to say that the control offered by ServiceWorker will make it far easier to control the nitty-gritty of caching behavior, which matters a lot.
I'm simply pointing out that you can get most (if not all) of the claimed perf benefits using existing API's. Yes, it won't look as pretty, but if you want to deliver a better experience to existing + older browsers.. this is something to consider.
It seems true in principle, until you try to actually get precisely the semantics you want, and then things go downhill fast. People should definitely try to find ways to use the HTTP cache more aggressively, but in practice, it's a giant slog with very little cross-browser consistency and total failures on mobile devices.
We should be thinking about how to deliver the best of both worlds: a great experience for older (non-SW) browsers, and an even better experience for those that do. The underlying patterns are effectively the same, SW just makes many things much simpler, and there is no reason to block on SW to start on this path.