I don't think it's quite the same. As you point out CSS and JS are cached for a long time, such that the browser doesn't even have to make a request. My unders

I don't think it's quite the same. As you point out CSS and JS are cached for a long time, such that the browser doesn't even have to make a request. 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.