Since Enterprise Browser 1.5 got released, I was eager to write something about our cool feature – Disk Caching.
We have introduced disk caching functionality for webkit engines which runs on wm/ce devices. This feature enables browser to cache the web resources locally on the device. This improves the page loading time and network bandwidth if user is trying to reload the same page.
 
Disk Caching Vs Memory Caching
 
Though Enterprise Browser supports memory caching, disk caching differs in its persistence behavior. In the case of memory caching, resources are stored in the application memory and will be lost once the instance is closed. Disk caching stores the resources into the physical memory (local file system) and will be available even if you close and relaunch the Enterprise Browser application.
This enables faster loading of the pages if any pages were previously visited in the current or previous instance of the Enterprise Browser application.
As we are dealing with low memory devices it is always a question that how much ‘cache memory’ can be reserved for an application like Enterprise Browser. As we keep visiting pages, there is a good probability that memory cache can recycle its content, once the upper cache limit is reached.
Once memory cache gets recycled, any previously visited pages looks new to the browser and it tries to fetch it from the server. This result in slower page loading and increased use of network band width.
With Disk Cache in place, browser first look for the resource in the memory cache and if not present it does a look in the disk cache and finally to the server if the content is not present.
As we have enough physical memory on the devices, we can overcome the recycling limitation of the memory caching feature.
It is very easy to enable disk caching in the case of Enterprise Browser by setting a runtime configuration named Enterprise Browser store the cached resources under a directory named ‘cache’ which is located at the installed directory.
This can be modified by the user easily by setting the runtime configuration named   
Resource Expiration
 
Ok, we know that the resource gets cached after the first fetch from the server and on further request EB fetch it from the cache. How long should this resource should be treated as fresh. There is a logic behind this.
As you guessed it can be controlled by the server response HEADER. One can configure the freshness of each resource using following response header.
 

Max-age (says how many seconds data should be treated as fresh by browser after caching)
Expires (the date/time after which the resource is considered stale by browser after caching)

 
Browser store the resource into cache along with the expiry information received during its last fetch’s from the server. Whenever a resource is requested, browser looks whether it is available in the cache, if yes it then checks for the freshness using the above mentioned header values.
If the data is fresh, then the resource gets loaded from the local cache otherwise browser issues an If-Modified-Since request to the server for the required resource with time and date as ‘last cached date’.
 
The If-Modified-Since request HTTP header makes the request conditional: the server will send back the requested resource, with a 200 status, only if it has been last modified after the given date. If the request has not been modified since, the response will be a 304 without any body. If server returns a 304, browser loads the resource from the cache else it loads the newly received resource from the server and it caches the same.
 
What happens if someone didn’t configure Max-age or Expires attribute the HTTP header response. Will it cache the resource? It depends?
EB has its own logic to treat a cached resource fresh even if user has not configured a max-age or Expires attribute. In this case, if there is a "Last-Modified" header present, the browser may use a heuristic to calculate a freshness lifetime for the response.
Below is the config.xml that can be used in the absence of above mentioned headers but in the presence of a Last-Modified header.
 

If Last-Modified time is ‘LMT’ for a cached resource and if the resource was cached at time ‘RCT’, the resource is treated fresh by the browser for a percentage of time RCT-LMT (by default EB set this to 10%).
DiskCacheTimeFactor = a percentage of RCT- LMT
 
In other words, at time (T) if the browser needs URL again and so looks in the cache for it and has to use the DiskCacheTimeFactor;
If T falls under calculated DiskCacheTimeFactor time range, then the cached resource is used directly. Otherwise a conditional GET (If-Modified-Since) is used to determine whether or not the previous response may be reused.
 
One can set DiskCacheTimeFactor to zero, if he wishes to fetch resource every time from the server.
 
Test Result
 
I was validating webkit performance improvement in EB1.5 with respect to EB1.4. I created a sample app which reloads itself after 4 seconds. The page has 3 javascript resourses rhoapimodules, angularjs and jquery respectively.
 
I could see around 50-60% improve with EB1.5 in a scenario where page was cached in previous instance.
 

EB1.4 (ms)

EB1.5(ms)

First navigation on a new Instance (no cahe)

7384

5598

navigation to previously cached page on a new instance (disk cache)

NA

2970

Page reloads

2749

2240