5 ms·

No need to wait for ServiceWorker – speed up your site today

21 points by igrigorik 12y ago

jaffathecake 12y ago
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.
- igrigorik 12y ago
  And I replied on G+, but also in short: do a background version ping, force a revalidation if version has changed. Gnarly, yes, but works. :-)
  - Partyfists 12y ago
    Also, you can append a last modified query parameter to automagically clear the cache for static assets.
wycats 12y ago
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.
- igrigorik 12y ago
  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.
  - wycats 12y ago
    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.
    - igrigorik 12y ago
      Once again, I'm not arguing against SW. 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.

21 points by igrigorik 12y ago

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.

igrigorik 12y ago
And I replied on G+, but also in short: do a background version ping, force a revalidation if version has changed. Gnarly, yes, but works. :-)
- Partyfists 12y ago
  Also, you can append a last modified query parameter to automagically clear the cache for static assets.

wycats 12y ago

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.

igrigorik 12y ago
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.
- wycats 12y ago
  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.
  - igrigorik 12y ago
    Once again, I'm not arguing against SW. 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.