

No need to wait for ServiceWorker – speed up your site today - igrigorik
https://plus.google.com/+IlyaGrigorik/posts/WPZsWr4QGqR

======
wycats
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
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
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
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.

------
jaffathecake
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
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
Also, you can append a last modified query parameter to automagically clear
the cache for static assets.

