What to cache?

What to cache?


If your CSS files use @import or include some external pictures, you need to explicitly add them one by one to the manifest file. The same applies to your JavaScript files: if they include other files, and you want them to be added to the cache, you must add them one by one to the manifest file. This can be tricky, so fortunately there are several tools to help you generate a manifest file. More on these in the next unit of this course section.


Normally yes, you can. Imagine a Web site that uses jQuery or any other common JS/CSS addons: you will need to have all the required files in the cache, otherwise the site will not run properly offline.

So, all external resources referenced through http:// URLs will be cached without restrictions.

However, the specification, , says that for Web sites accessible only through https:// secure connections, the same origin policy should apply. Only resources from the same domain, when referenced by https://, should be cached.

In fact, some browsers, such as Google Chrome, do not adhere to this part of the specification and also cache resources referenced by https://. It has been arguedthat the single origin policy for https is too restrictive in the real world for app caching to be of genuine value


Useful tools for generating or validating a manifest file


manifestR is a bookmarklet, meaning that you are able to drag it to your bookmarks bar. Then, when you visit a page, you will click on the manifestR button, and it will create an HTML5 appcache manifest file for that page. See the live coding at section 6.3.2 to see it in action!


Confess.js is a small script library that uses PhantomJS 1.2 (or later) to analyze Web pages. Currently it can perform the following tasks:

    • Generation of an appcache manifest for a Web app
    • Simple performance analysis of a Web page and its resources
    • List of CSS properties used on the page


Manifesto is an HTML5 Offline Application Cache verification bookmarklet. Go to their Web site, drag an icon to the toolbar of your browser, and when you visit an HTML page that has a manifest file, click the manifesto bookmarklet. This will generate a report. The Web site proposes several links to try it out with valid and invalid manifest files.

The http://manifest-validator.com/  Web site accepts URLs of manifest files, or pasted content. It will validate the file. It also proposes a Chrome extension and a TextMate addon.


Updating the cache


When a resource is in the cache, it will ALWAYS be retrieved from the cache, even if you are online, and even if a more recent version is available on your Web server.


Best practice: update the manifest file on your server!

Updating the manifest file server side will update the files cached by browsers: the easiest way to make the browser update the cache is to update the manifest file itself.

A best practice is to add a comment with the last modification date of your Web site in the manifest file. If you update any file on your site, also update this comment. Your manifest last modified date will be changed, and the browser will check all files in the CACHE section of the manifest for modification, and update the cached version if necessary.

Clear the cache on the client side?

Clearing the cache using the browser dev. tools/options will also regenerate the cache at the next connection. It’s not common to manually clear the cache. Usually Web developers do this when debugging.

Cache size limitations


For traditional Web sites of normal size, there is no problem. Just create a manifest file as we’ve shown you (in the “make your Web site run offline” unit), and your Web site should work offline!

On today’s (2015) desktop browsers, the available cache size is generally sufficient per domain, and there is no need to worry.

If a user visits your Web site and if this Web site asks to be cached, and if there is no more free space available, the browser will find some (in general by asking the user permission to increase the cache size limit for the current domain – see screenshots-, or by clearing least recently used data). On mobile devices, the cache size limits are lower but reasonable.

With some atypical applications that need to cache large amounts of data (images, videos), there may indeed be inadequate space in the cache. In this case, the browser prints an error message in the console. It’s also possible to use a JavaScript API to detect this situation and show the user an error or a warning message in the page “Sorry, this Web site will not be available offline as we could not cache it due to size limitations…”. This advanced part will not be covered in this course.

Anyway, if you wish to find out more about size limits and what the various HTML5 persistence mean, please read the rest of this page. As such, there will be no exercises related to the optional content material below!


There is a size limit, but it varies depending on many parameters!

There are size limitations, but they vary from one browser to another. And they also vary depending on whether your browser is running on a mobile or desktop device. Finally they may vary depending on the size of the hard disk or the size of the memory of the device the browser is running on!

For example, with Chrome there is no maximum size limit for cached data (it is computed depending on the configuration and on the current amount of data already persisted).  But if you use the LocalStorage persistence for storing data, (see next section of this course), then, for this special kind of data,  Chrome applies a 10Mbytes per domain limit. And this is completely different on FireFox, on Safari, etc. The W3C specification recommends at least 5Mbytes per domain with support for at least 20 domains.

We recommend reading this article from HTML5 rocks (January 2014). The author wrote a Web application that tries to fill all available space and “guess how the different persistent storage spaces” are managed by different browsers. He tried with all major browsers on mobile devices and on desktop.

On the right: a screenshot of some of the resulting measures (extract from the above article).

Also, for greater detail, see this paper about “Managing HTML5 offline storage”.

A quota management JavaScript API exists!

In order to make Web applications aware of the free space available for persisting their data, a Quota Management API is being developed. Note that this API specification is under active discussion and is subject to change in the future. It’s still experimental.

Try this example on JS Bin that shows the available disk space for all HTML5 persistence means (cache, localStorage, IndexedDB, etc.). Try it with Google Chrome: as of June 2015, it is the only browser that implements the Quota API.

Source code extract:

  1. function showFreeSpace() {
  2.   //the type can be either TEMPORARY or PERSISTENT
  3.   webkitStorageInfo.queryUsageAndQuota(webkitStorageInfo.TEMPORARY,
  4.             onSuccessonError);
  5. }
  7. function onSuccess(usedSpace, remainingSpace) {
  8.     var displaySpace = document.querySelector(“#space”);
  9.     displaySpace.innerHTML = “Used space = “ + usedSpace + “, remaining space = “
  10.                             + remainingSpace;
  11. }
  13. function onError(error) {
  14.     console.log(‘Error’, error);
  15. }


note about “non traditional Web applications”

Finally, the amount of free storage space is managed differently if your Web application is not a “traditional HTML page” loaded in a browser, i.e. using a http:// or https://URL. It may be a browser extension, a browser application (coming from a store such as Chrome store, Windows store, FireFox OS store, etc), it may run on a Playstation 4 or on a Xbox One.

In these cases, HTML5 applications can get more privileges such as reading/writing to your hard disk and benefit from a large disk space. Imagine that they are similar to applications you install on your smartphone: you accept that they use XXX megabytes, use your GPS without asking for permission, etc. This course will not cover this type of application, but only focuses on traditional Web pages and applications.

Checking that the browser is online/offline

The new HTML5 persistence APIs are very often used with the  navigator.onLine property, part of the DOM API. This feature is available on all browsers. The navigator.onLine property returns true or false depending on whether or not the application has network connectivity.

Beware that a browser may be “online”, but if your applications talk to a remote server, which does not answer, or if your DNS server is down, being online does not mean that your application fully works. Gmail, for example, detects when the remote service is down and displays a message “trying to connect in 30s…”.

Important: if the browser is offline, this means that your application should work in “degraded, offline mode”. If it’s online, it should work, but there is no guarantee that your remote server is up and running, that the DNS server is operational, etc.

Check connectivity: online example on JS Bin

  1. <!DOCTYPE html>
  2. <html lang=“en”>
  3. <head>
  4.   <meta charset=utf-8>
  5.   <title>HTML5 Demo: Online connectivity monitoring</title>
  6. </head>
  7. <body>
  8.    <header>
  9.      <h1>Online connectivity monitoring</h1>
  10.      <style>
  11.      #status {
  12.         color: #FFFFFF;
  13.         padding: 5px;
  14.      }
  15.      .online {
  16.          background: green;
  17.      }
  18.      .offline {
  19.          background: red;
  20.      }
  21.      </style>
  22.    </header>
  23.    <article>
  24.      <p>Current network status (try to disconnect wifi or unplug
  25.         your ethernet cable):
  26.         <span id=“status”>checking…</span>
  27.      </p>
  28.      <ol id=“state”></ol>
  29.    </article>
  31.     var statusElem = document.getElementById(‘status’),
  32.     var state = document.getElementById(‘state’);
  33.     function online(event) {
  34.      statusElem.className = navigator.onLine ? ‘online’ :‘offline’;
  35.      statusElem.innerHTML = navigator.onLine ? ‘online’ :‘offline’;
  36.      state.innerHTML +=
  37. New event: ‘ + event.type +
  38. ;

  39.     }
  40.     window.addEventListener(‘online’, online);
  41.     window.addEventListener(‘offline’, online);
  42.     // call the online function so that it refreshes display when
  43.     // the page is first loaded
  44.     online({ type: ‘ready’ });
  45. </html>


Usually, one checks if the application is running in online or offline mode (in the latter case, data may be retrieved from the client side using one of the various methods presented in this week’s course). Instead of displaying messages (lines 41-42 in the code source shown above), you should use an implementation like this:

  1. window.addEventListener(‘online’, function(e) {
  2. // Re-sync data with server.
  3. }, false);
  4. window.addEventListener(‘offline’, function(e) {
  5. // Queue up events for server, store them on the browser side
  6. }, false);



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s