App Cache and HTML5 History

Whilst developing our latest app (https://github.com/PaulKinlan/ioreader) for a Google IO, we ran into several large is limitations with AppCache and HTML5 History that I wanted to share (and at somepoint hopefully solve).

Putting the current discussion of the issues with AppCache aside for a couple of minutes, there is no provision in HTML5 History to include pages "pushStated" into the current App Cache Group

Consider this flow: We have a multi paged app with pages A and B when rendered from the server sharing the same AppCache and thus in the same group.

User visits page A, it uses an app cache, so everything is cached.
User navigates from A to B, page B is added to the app cache group.
User goes offline
User refreshes A it is served from the Cache, User refreshes B, it is served from the Cache.

Update the AppCache, A and B are re-downloaded and cached [see: Death by App Cache].

Now if we inject HTML5 History for the same flow:

User visits page A, it uses an app cache, so everything is cached.
User navigates from A to B (via pushState) ..... currently B is not added to the App Cache group.
User goes offline
User refreshes A it is served from the Cache, User refreshes B, fail, because not in the Cache.

I believe that as URL's change if the master page is App Cached, the new URL's should be added to the App Cache group. You are still in the same application, the state is just dynamically changed but in essence you are on a page that should be available offline. The act of changing the URL client-side normally enforces you to generate the correct content on the server if the page was simple fetched.

Death by App Cache: The problem that we also faced was as master entries are added to an App Cache group, when an update to the App Cache occurs, all those pages in the App Cache are refreshed, with more dynamic applications this could mean that 10's or 100's of pages are quickly downloaded by the App Cache software and thus can quickly cause a mini DDOS.

I am interested to hear your thoughts.

View Source | Make a correction | Correction history

I lead the Chrome Developer Relations team at Google.

We want people to have the best experience possible on the web without having to install a native app or produce content in a walled garden.

Our team tries to make it easier for developers to build on the web by supporting every Chrome release, creating great content to support developers on web.dev, contributing to MDN, helping to improve browser compatibility, and some of the best developer tools like Lighthouse, Workbox, Squoosh to name just a few.

Mastodon Book a consultation