The first load should be moderately slow (still, only about two seconds), and any subsequent load of one of the posts should be near-instantaneous.
This is also a particularly big deal in countries where wifi and LTE are less prevalent, or where users regularly switch to airplane mode to conserve data. According to Tal Oppenheimer's talk [0] at the recent Chrome Dev Summit, an hour of minimum-wage work in India would pay for about fifteen web pages' worth of data cap. In that regard, being aggressive in how and what you cache makes a lot of sense.
For example load http://pouchdb.com/, first page load may be a little slow but the rest will be very fast aside from the api page which has some slow JS (if the rest of the pages didnt load instantaneously we would probably never notice how JS slows that page). Turn your internet connection off while you browse, its all fine.
The above is using AppCache, but a big part of ServiceWorkers is learning from the AppCache mistakes and having a more flexible / powerful framework for them.
HTTP Caching does not have explicit guarantees about the availability of things in its cache, ServiceWorkers and AppCache do.
I'm tired of web 2.0 ajax sites where you scroll through content, click a link, then you try to go back, and you have to scroll through the same things you didn't care about again. Or in Facebook newsfeed's case even reorders things.
It honestly feels like "Ooh look at this shiny new tech. Let's use it! Why? Because we need to improve 'usability'! proceed to throw other usability concerns into the trashcan"
There's no reason such an app can't be implemented as a plain-old-webapp pinned to your iOS springboard or whatever else. You open it, you get RSS items. You try to refresh, it says "no internet, sorry", and the refresh is cancelled. Every other part of the functionality continues to work just fine.
There's actually something that does exactly this: visiting the Gmail website on iOS will build a local database of your mail, and let you continue to interact with it, search through it, write emails and "send" them (they stay in your outbox) when you don't have internet connectivity.
With Service Workers you can cache the static parts of your templates (e.g the UI chrome) and render them immediately via JS rather than waiting for the initial document load. You then grab the rest of the dynamic content via an AJAX call. This leads to improved perceived performance, since you can immediately begin painting rather than showing a blank screen waiting for the document load.
Even with great HTTP caching, skipping the initial document load will always be faster (assuming that the document is dynamic, and thus can't be cached via HTTP caching). For plain static pages, of course, the existing web works super well, since that's what it was designed for.
My understanding of this "application shell" is that even the HTML response is given a cacheable / far-future expiration header.
Is that even possible? It would be cool, if so. If you type "foo.com" in your address bar, could your browser say "ah, I've already got this response cached, here you go, here's your HTML, CSS, and JS"? That would literally be an instantaneous load with no network round trip at all. Then the JS could kick in and fill in the shell with whatever the actual dynamic content is.
That's different from a normal webpage which just caches the assets, since it still has to make a full request to get the HTML. Especially on phones, even if the response is small in size, the latency of the request/response cycle can be somewhat long (almost a second).
Edit: After further playing around with app-shell.appspot.com and your site, I see where you're coming from. Both of them respond to a refresh in <10ms (my browser takes the content from the cache). app-shell loads from the web worker, your page loads from the browser's cache (why? It has a no-cache header).
However, I guess the difference is the app-shell one is able to load dynamic content into its shell, even with the instantaneous from-cache load of the outer shell. I think the perceived performance will be about the same (since the browser paints the shell immediately), but it is able to be dynamic.