THE FUTURE IS HERE: APPLICATION- AWARE CACHING BY ASHOK ANAND

Modern web pages are complex and the number of resources required to download a page continues to increase. To load a web page a browser may need to download HTML, images, stylesheets, scripts, video, fonts and a variety of other resources. As of July 2015 over 30% of web pages request more than 100 resources, and based on cache lifetime statistics 67% of these resources are cached for less than a day.

Eliminating round trips by caching frequently-used resources is one of the most common suggestions for improving web page performance, so why are so few applications applying this technique? Unfortunately browser caches offer no application control and unpredictable performance gains. In order for a quality user experience, an application needs to control what content gets cached, with what priority, and where it is stored. With the availability of HTML5 storages such as WebStorage, FileSystem and IndexedDB, a hierarchical application-managed client-side cache is a possibility.WebStorage CHALLENGES WITH TRADITIONAL BROWSER CACHING Traditional browser caches store content based on URLs, which can lead to sub-optimal performance. Take, for example, the popular web performance optimization concept of domain sharding. Domain sharding tricks a browser into opening additional connections by presenting unique domain names for content. If done incorrectly, the same object can be downloaded across multiple domains, thereby eliminating the benefits of caching content. For example, if the same object is requested once from static1.example.com and on a future visit the content is requested from static3.example.com, the object will be treated as a new object even though there is a perfectly valid copy sitting in cache. This doesn’t just happen with domain sharding. In an analysis of approximately 1 million cached images, JavaScript files, stylesheets and custom fonts, it was discovered that approximately 65,000 objects had the same content but different names. This results in multiple copies of the same object sitting in cache, as the same object existed in multiple directories, resulting in unique cache names.

When an object expires from the browser cache, it requires revalidation; this is traditionally done by an If-None-Match or If- Modified-Since header in the request. If the resource on the server matches, this results in a 304 Not-Modified HTTP status code. Performing a network round trip to find out that the object that is already in the cache is a waste of network resources and bandwidth. On a high-latency link this could add a considerable amount of time to the page load. Certain resources on a page are more important than others. If your web page uses a large hero image, ensuring that it is in the cache and loads with a high priority can make the page feel like it is loading faster. When a browser only looks at metrics such as popularity and age, resources in the critical path of page load can be ignored and evicted from cache. hero image BENEFITS OF APPLICATION-AWARE CACHING When an application is in control of the caching, it is possible to index based on a hash of the resource as opposed to a name, eliminating duplication of cached content. Controlling the cache key also enables the application to send the validation information for resources with the HTML, eliminating costly revalidation requests. When the application controls the cache, not only does performance improve, but the application can make more intelligent decisions regarding what to serve. For example, If an application has heavy blocking JavaScript code in the HEAD section of the HTML, an application-aware caching strategy can determine the optimal storage mechanism to serve up JavaScript faster, enabling the web page to be displayed much earlier. In other cases, if your application uses a series of rotating images on the home page, the application can select an image that is in the cache and download other images in the background to be used on future visits.

INTRODUCING INSTANTLOAD InstantLoad is a client-side hierarchical cache system that utilizes different HTML5 storage types, including localStorage, sessionStorage, IndexedDB and FileSystem API, depending on the requirements of the request. The caching system takes into account the browser and the resources being requested, and can adapt and learn over time to become even more valuable when delivering high-performing web applications. The hierarchy is based on the performance of the different layers, with the highest-performing storage at the top. For example, localStorage and sessionStorage both perform significantly better than traditional browser caches. Keys are mapped to arbitrary objects containing metadata related to priority, expiry, validation and eviction. The diagram below provides a high-level diagram of the various layers:

The browser is instructed to use InstantLoad via Nanovisor.js. The Nanovisor is a small, lightweight JavaScript client that detects the capabilities of the browser and its available storage systems. Based on the storage available and an in-depth understanding of the application, InstantLoad is able to seamlessly and transparently redirect critical elements of the application to the appropriate storage location. The end result is faster loading pages and an improved quality of experience for end users without having to rewrite the application. RESULTS We tested 15 websites from the Alexa top 500 global sites in a controlled environment to see the impact InstantLoad would have. The results in the chart below show improvement across the board for all sites tested. Where improvements are small, the majority of content was being served from the browser cache as opposed to localStorage or sessionStorage, based on the resources not being referenced directly within the HTML but via JavaScript. Alexa top 500

With a few small application changes, resources can be cached using the application-aware InstantLoad cache as opposed to the standard browser cache, providing page load improvements of between 30-60%. Currently, InstantLoad offering is available for loading scripts in the HEAD of the HTML and it leverages localStorage for fast loading. Check out our recently published technical publication from the IEEE International Conference on Multimedia and Expo (ICME 2015): “A Case For Application-Managed Cache For Browser” for a more in-depth discussion. IEEE International Conference on Multimedia and Expo (ICME 2015)A Case For Application-Managed Cache For Browser Visit our Blog to learn more