Originally published at: http://www.sitepoint.com/common-pitfalls-avoid-using-html5-application-cache/
Application Cache, also known as AppCache, has been a pretty hot topic with web developers these days. AppCache enables you to allow your website visitors to browse your website when they are offline. You can even store parts of your website, such as images, stylesheets, or web-fonts in the cache on a user’s computer. This can help your website load faster and hence reduces load on your server.
To use AppCache, you make a manifest file with a file extension of “appcache”, for example: manifest.appcache. In this file you can list all the files you want to be cached. To enable it on your site, you have to include the reference to this manifest file on your webpage on the html element, like this:
<html lang="en" manifest="manifest.appcache">
Here’s a sample manifest file:
CACHE MANIFEST # 23-01-2015 v0.1 /style.css /logo.gif /script.js NETWORK: * FALLBACK: /server/ /fallback.html
Along with the benefits of AppCache, there are some common pitfalls that you should avoid in order to prevent ruining the user experience and breaking your application.
Never list the Manifest File in the Manifest File
If you include the manifest file itself in the application cache manifest, it gets in a kind of loop, making it nearly impossible to inform your website that a new cache file is available and it should download and use the new manifest file instead of the old one. Therefore, always be careful not to make the following mistake:
CACHE MANIFEST # 23-01-2015 v0.1 manifest.appcache page2.css
Non-Cached Resources Do Not Load On a Cached Page
This is a very common mistake when working with AppCache for the first time. This is where the NETWORK flag in the manifest file comes to the rescue. The NETWORK section of a manifest file specifies resources for which a web app requires online access.
URLs specified under the NETWORK flag are basically “whitelisted”, that is the files specified under this flag are always loaded from the server when an internet connection is available. For example, the following snippet of code makes sure that requests to load resources contained in the /api/ subtree always load from the network and not the cache.