#appcache

Every time you make a change to one of the resources in your offline web application, you’ll need to change the cache manifest file itself. This can be as simple as changing a single character. The easiest way I’ve found to accomplish this is to include a comment line with a revision number. Change the revision number in the comment, then the web server will return the newly changed cache manifest file, your browser will notice that the contents of the file have changed, and it will kick off the process to re-download all the resources listed in the manifest.

When AppCache arrived on the scene it gave us a couple of patterns to make content work offline. If those were the patterns you needed, congratulations, you won the AppCache lottery (the jackpot remains unclaimed), but the rest of us were left huddled in a corner rocking back & forth.

With ServiceWorker (intro) we gave up trying to solve offline, and gave developers the moving parts to go solve it themselves. It gives you control over caching and how requests are handled. That means you get to create your own patterns. Let's take a look at a few possible patterns in isolation, but in practice you'll likely use many of them in tandem depending on URL & context.

All code examples work today in Chrome 40 beta with the cache polyfill, unless otherwise noted. This stuff will land into the stable version January/February 2015 barring any emergencies, so it won't be long until millions of real users can benefit from this stuff.

For a working demo of some of these patterns, see Trained-to-thrill, and this video showing the performance impact.

Contents

The cache machine - when to store resources

On install - as a dependency

On install - not as a dependency

On activate

On user interaction

On network response

Stale-while-revalidate

On push message

On background-sync

Cache persistence

Serving suggestions - responding to requests

Cache only

Network only

Cache, falling back to network

Cache & network race

Network falling back to cache

Cache then network

Generic fallback

ServiceWorker-side templating

In this keynote presentation from HTML5DevConf, Steve Souders, Google's Head Performance Engineer, clarifies the problem of caching, and explores various solutions to make your web app lightning fast.

40-60% of users visit your site with an empty cache at least once each day. 58% of resources don't have caching headers, even though 38% of them go unchanged for weeks. The browser cache is small. We're told localStorage is bad for performance. Is it? Does it depend on how it's used? Application cache is full of gotchas. Join Steve as he clears the confusion with real data.

Take away:

Always be specific. Specify Cache-Control max-age OR no-cache. Because if you don't you're relying on the browser!

App Cache - must change Manifest file in order to see changes. It typically takes 2 reloads to see the changes

Jake Archibald: AppCache: Douchebag

Jake is funny as hell. "Browsers are Dicks" but Appcache would have the most dicks!!!

Slides on Speaker Deck and his AppCache demo on GitHub. Tons of pitfalls/gotchas to deal with - it's complicated when online vs offline.

The Application Cache is one of the cool bits of HTML5, allowing sites to work without a network connection brings us much closer to native app-like behaviour. However, from HTML5 roundup articles and talks you may be left with the impression that it's a magic-bullet fix, unfortunately it isn't, the Application Cache is a douchebag.

I don't mean it's incompetent or difficult... it's just a douchebag. The Application Cache has skills we need, but if you asked him to paint your bathroom he'd somehow manage to flood your kitchen and break your TV in the process, and he wouldn't care.