This article assumes that the user is aware of the process by which a webpage renders on a browser, how the resources are fetched, etc. The document also assumes that the user have basic understanding of browser caches and cache headers. This article provides the basic information on using appcache and a demo page to explain its benefits.

AppCache vs Browser Cache

When a page is requested on the browser without appcache, there will be a sequence of network requests sent from the browser to the server. The first request is the actual page (raw html) you wanted to load. Then browser reads the html and process them line by line. Every script tag, css link tag or any other resources on the page are requested sequentially. Each of this requests may be cached in the browser and this forms the browser cache. I said “may be” because the rule for a resource getting cached is: resource headers sent from your server. See example below:

So, it is evident that a browser cannot cache these items unless and otherwise, we visit the page and also depends on headers received for individual resources. But, what if you want to cache the extra few items that needed to display next page? What if, your website need to work offline and sync only when needed or when the user gets online? What if, you have a website which have separate layer for presentation/logic and separate layer for data and like to store all the presentation/logic offline? The answer is simple and straightforward: AppCache.
Now, let’s not get excited and convert all our websites to webapp. HTML5 AppCache is designed for offline webapps – make no mistake. A simple error such as app-caching a dynamic data would result in rendering outdated website. So, it takes time to understand AppCache and make sure you appcache the right set of resources.

How to do it?

Well, its pretty simple. Write a manifest file describing the items to be cached, network behavior, fallback, etc and mention the manifest in the HTML. That’s it.
A sample would be below:

# ======================================
# AppCache Manifest - version 0.1
# ======================================
#JS files
#CSS files
# Resources that require the user to be online.
# static.html will be served if is inaccessible
/ /static.html
# offline.jpg will be served in place of all images in images/large/
images/large/ images/offline.jpg
# offline.html will be served in place of all other .html files
*.html /offline.html

NOTE: The CACHE MANIFEST string should be the first line and is required.
This is the default section for entries. Files listed under this header (or immediately after the CACHE MANIFEST) will be explicitly cached after they’re downloaded for the first time.
Files listed under this section are white-listed resources that require a connection to the server. All requests to these resources bypass the cache, even if the user is offline. Wildcards may be used.
An optional section specifying fallback pages if a resource is inaccessible. The first URI is the resource, the second is the fallback. Both URIs must be relative and from the same origin as the manifest file. Wildcards may be used.
Now add the manifest to the html file.

<html manifest="example.appcache">

Cache Update

The tricky part is updating the cache items. When the content on the server is changed, the browser will not know the change and will continue to use the outdated data on the webpage. The appcache manifest should be fetched everytime by the browser to determine the items that has to be refreshed. Hence, it is VERY IMPORTANT to make sure appcache manifest is never cached by the browser or at least not for a long time. For that, it is important that the headers sent by the webserver for the manifest also includes the expiry time. It is also possible to update the appcache via the javascript like

var appCache = window.applicationCache;
appCache.update(); // Attempt to update the user's cache.
if (appCache.status == window.applicationCache.UPDATEREADY) {
  appCache.swapCache();  // The fetch was successful, swap in the new cache.

It is also possible to clear the cache when the user clears the same in his/her browser. However, that is not a valid workflow for updating the cache.

The Gotchas

The appcache also caches the base page. This means, if you later change the base page to include an additional library or UI, it will not be fetched from server unless there is a manifest file update. In order to bypass this functionality, it is ok to include the appcache in a temporary html and include the temp html as an iframe in the base page (See demo link below). By this way, you still cache the manifest items but the base page will not be cached by the appcache unless specified in the manifest.

Demo link


We saw the basic differences between appcache and browser cache with a basic example to include app caches. The example link also shows how to include the appcache by not affecting the cache of the base page by providing manifest in a temp html and loading the same in a iframe.


This article will discuss on the various image loading techniques in web and¬†functionality¬†of each of them. Mostly, we write img tags and leave it at that and we don’t care what happens from there. But, it’ll really comes back to haunt us later when there are plenty of images on the site and web site drags itself.


Baseline JPEG rendering

DEMO: link here
Baseline JPEGs are the default JPEG files we use. The images are rendered from top to bottom with each layer after another. Please look at the below GIF for understanding the loading process.


Now to the details, the image is fetched from the server and as soon as it gets a line, it draws there. As you can see from a test below, it took 7.6 seconds to complete the image rendering and the spinner was spinning till the end – which means, you are having a bad user experience of just painting few lines of image every second and though the document got ready, the end user is under the impression the document is still loading.


Progressive JPEG rendering

DEMO: link here
Progressive JPEGs are special kind of JPEGs which has to undergo few processes to create progressive JPEG from normal JPEG. The progressive JPEGs render in a different way – interlaced. Meaning, all the rows are rendered with first with minimum detail and as download progresses, the quality of image improves.


As you can see, the entire picture is visible right from the time page is loaded except the data is fetched continuously to enhance the picture.

Both, baseline and progressive will delay the load event.

Creating Progressive Images (Mac OS X)

jpegtran -copy none -optimize hawkeye-original.jpg > hawkeye-opt.jpg
jpegtran -copy none -progressive hawkeye-opt.jpg > hawkeye-progressive.jpg

Progressive takes almost the same computation memory and won’t bring the browser down. However, JPEGs are a compressed format and progressive is much more optimized in it but this cannot be said for other formats. PNG renders better than JPEG in progressive.

Simulate Progressive with JS

DEMO: link here
This is an idea to load the cheapest version of the image first and in a separate thread update with a HD version.





The image attribute should have low quality src and a reference to high quality src for us to load later.

     <img refresh="<?php echo time(); ?>" src="<?php echo time(); ?>" width="100%">

On document ready, create a timeout thread to update the src:

$(document).ready(function() {
     window.setTimeout(function() {
           $('img[refresh]').each(function(idx, element) {
                 var refreshURL = $(element).attr('refresh');
                 $(element).attr('src', refreshURL);
     }, 200);

With this JS simulation, we get a better user experience and document load is fired right after the low quality version is loaded. The only disadvantage is, increased network traffic with small and HD version loading for every image. However, if it is used for only HD images on the page, this is an great approach.


This tutorial will help you learn many things – how to use MongoLab API for CRUD operations, how to get browser info and version and how to use google charts. What we are going to achieve is, to create a real-time page which keeps updating the hits with browser info and also renders the page with the stats.



You should at least know what MongoDB is and the flexibility it offers. You can read it right here. MongoLab is the cloud API provider for MongoDB. It also provides a REST interface for the same. Opening a account is free and so I would advise you to get one in case if you wanted to try MongoLab in your small projects. Do NOT try and use the key I used in my JavaScript. It’s not going to cost me anything because its a free account but again, I would have to manually login and clear those items if you use my ID for your demo apps :).

Storing browser info

The idea is to figure out the browser name and version and if it is already in DB, just increment the hit number else insert a new row.

    Util method to get browserName and browserVersion from navigator. Source:
navigator.sayswho = (function () {
    var N = navigator.appName,
        ua = navigator.userAgent,
    var M = ua.match(/(opera|chrome|safari|firefox|msie)\/?\s*(\.?\d+(\.\d+)*)/i);
    if (M &amp;&amp; (tem = ua.match(/version\/([\.\d]+)/i)) != null) M[2] = tem[1];
    M = M ? [M[1], M[2]] : [N, navigator.appVersion, '-?'];
    return M;
if (navigator.sayswho.length &gt; 1) {
    navigator.cBrowserName = navigator.sayswho[0];
    navigator.cBrowserVersion = navigator.sayswho[1];

Now you do have browser name and version after the above steps. The task is to figure out whether the row is already present in DB or not. Querying the DB is easy with JavaScript but it is a shame that you can’t do that for commercial website because people will use the key to query your DB directly.

$.ajax( { url: "<YOUR_KEY>&q=" + queryStr,
        type: "GET",
        contentType: "application/json",
        async: true,
        timeout: 5000,
        success: function (data) {
        error: function (xhr, status, err) {}

The insert and update code is pretty straightforward.

function updateDB(browser, version, hits) {
    var queryObj = {"browser": browser, "version": version};
    var queryStr = JSON.stringify(queryObj);
    // API Key needs to be changed to yours. This key is, however, a free limited space key and you can get one for yourself.
    // : Sign up and get 500MB free.
    $.ajax( { url: '<YOUR_KEY>&q=' + queryStr,
        data: JSON.stringify( { "$set" : { "hits" : hits } } ),
        type: "PUT",
        contentType: "application/json"
    Insert the new browser info here.
function insertToDB(browser, version) {
    // API Key needs to be changed to yours. This key is, however, a free limited space key and you can get one for yourself.
    // : Sign up and get 500MB free.
    $.ajax( { url: "<YOUR_KEY>",
        data: JSON.stringify( { "browser" : browser, "version" : version, "hits" : 1} ),
        type: "POST",
        contentType: "application/json"

The posting part is now over.

Get browser stats

Let’s query the DB with browser name as sort order.

$.ajax( { url: "<YOUR_KEY>&s="+queryStr,
    type: "GET",
    contentType: "application/json",
    async: true,
    timeout: 5000,
    success: function (data) {
    error: function (xhr, status, err) { }

Google charts is a fantastic API to display charts. It is the easiest way and also the best I’ve seen.

google.load("visualization", "1", {packages:["corechart"]});
// after query
var data = google.visualization.arrayToDataTable(browserData);
var options = {title: 'Browser Stats'};
var chart = new google.visualization.PieChart(document.getElementById('chart_div'));
chart.draw(data, options);

That’s it folks! Take a look at demo here.