Boost Ajax performance using local storage

The migration of popular computing applications to the Web has changed the way we view the web browser. Some of our most frequently used applications now exist within a tab of Firefox or Internet Explorer, constantly polling a remote server on our behalf and presenting the results in a rich interface powered by the latest features of JavaScript and/or the Flash Player plugin. These “live” web applications have pushed the browser to its limits (and sometimes beyond), consuming increasing amounts of memory and network bandwidth as our browser terminal remains connected to the data cloud. Storing data and preferences directly on the user’s machine is one way to speed up a web application and even offer some offline capabilities, connecting to data stored on a local hard drive instead of relying on a remote server. In this post I’ll walk through some of the ways web application developers take advantage of local storage to speed up applications, persist user preferences, and enable features for “occasionally connected” users.

Storing web application data within a local cache opens up new possibilities for a future class of web applications by storing and loading user data directly on a user’s hard drive. The future of asynchronous JavaScript and XML (Ajax) will extend its reach beyond client-server interactions and into local XML storage addressed from any web page and interpreted by the client web browser. A web application can rely on local storage options when disconnected from the Internet, saving changes locally and synchronizing results whenever an active Internet connection is available.

Imagine a personal finance site storing your stock portfolio and historical prices locally, creating quick access to charting and planning tools powered by pre-loaded data. Your favorite blogging tool might already use local storage to automatically save drafts of your blog posts, checking for spelling and grammar mistakes based on locally stored individual preferences. A personalized homepage might store your selected widgets and their content locally, quickly loading your information dashboard with or without an available Internet connection.

Local storage of client preferences and data is nothing new but, like DHTML, is being rediscovered as web applications squeeze as much as they can out of currently deployed browsers and popular plugins. Just like other web technologies such as JavaScript and CSS, support for local data files addressable from a web page varies by browser. JavaScript libraries such as Dojo Storage abstract each storage method into a single JavaScript call with appropriate storage based on available resources (thanks Brad Neuberg!), but it’s useful to take a look at the low-level options and their respective limitations.

Web browser local storage options
BrowserStorageMax Size
AnyCookies4 KB
Flash Player 6 and aboveFlash local Shared Object100 KB
Internet Explorer 5 and aboveuserData1 MB
Firefox 2 and aboveDOM Storage5 MB

A HTTP cookie persists user data in a single browser across multiple browsing sessions, allowing a website to track items placed in a shopping cart, recognize a logged-on user, save a site preference, and more.

Cookies are limited to 4 KB of storage per domain and are a good way to persist user data for convenience or tracking. Modern web browsers contain cookie and privacy management features to wipe away stored cookies and their stored data and therefore have limited utility for continued persistence. Cookies are sent along with every request on a given domain, adding extra weight to every message exchanged between an end-user’s browser and your site, even if the cookie data is only occasionally utilized.

Browser cookies are the most common form of persisting data across multiple website visits but their limited size, common deletion, and added weight limit the usefulness of this time-tested storage method.

Flash local Shared Object

Adobe Flash logo Websites can take advantage of Abode’s ubiquitous Flash Player to store data as a local shared object or Flash cookie. Flash storage objects are available in Flash Player 6 or above, reaching 96% of web users in mature markets as of September 2006.

Flash Player can store up to 100 KB per domain without any user interaction. Storage limits can be increased by prompting the user for a larger allocation. Stored data is accessible across the user’s Flash Player instances, loading stored data into Internet Explorer, Firefox, and even Flash apps such as Apollo.

Adobe Flash storage

It’s possible to view, delete, and change Flash cookies stored on your computer through the Flash settings manager, but most storage will occur seamlessly behind the scenes without involving the user.

Flash local shared objects provide a reasonable amount of storage across multiple browsers and applications. The Flash Player plugin requires some additional allocated system resources at runtime for a single function, but you can limit its use to only those pages on your domain requiring a local storage component.

Internet Explorer userData

Internet Explorer 7 logo Internet Explorer 5 and above supports data persistence using a userData behavior. Per-document and per-domain storage restrictions vary based on a site’s security zone.

userData storage limits by security zone
Security ZonePage storageDomain storage
Intranet512 KB10 MB
Internet128 KB1 MB
Restricted64 KB640 KB

An enterprise application has access to up to 10 MB of storage for each internal domain and Internet applications can take advantage of up to 1 MB of storage per domain, or 128 KB on every page view. These XML files reside in the user’s settings folder and will not be removed when the user clears out cookies, temporary files, or autocomplete settings in Internet Explorer.

Internet Explorer exposes a relatively large local storage component for web applications to query when needed. It’s especially useful in corporate environments, creating up to 10 MB of fast-access data for each user.

Firefox DOM Storage

Firefox logo Firefox 2 supports local storage based on the WHATWG DOM storage method, simply referenced as DOM Storage in the Mozilla context.

Current versions of Firefox 2 allow unlimited storage through the DOM Storage feature but future Firefox releases (post-2.0.0.1) will restrict usage to 5 MB per-domain. A website can access not only data within its own subdomain or domain, but within a given top-level domain (.gov, .com, etc.) or any requesting page, creating some interesting opportunities for shared data namespaces.

DOM Storage can queue an alert events when a browser connects or disconnects from the network, prompting a data sync once a user’s local changes are able to talk to a remote server.

The standardization process behind WHATWG DOM Storage for web applications holds promise for future implementations of browser-based storage from other working group members such as WebKit/Safari and even Google. These storage methods are very new and I expect many implementation details will become solidified in the Firefox 3 development process.

Conclusion

Client-side storage addressable from any web page has the potential to change the way we build web pages and the division of labor between client and server. Just as CSS and JavaScript created new ways to style and interact with a page, the client-side storage capabilities of modern browsers will create a new concept of a web application runtime. It’s yet another step in the progression of web applications trying to create the best possible experience using the latest widely deployed web browsers and browser plugins.

Web applications using these latest technologies can deploy an upgrade on-the-fly, initializing a new set of libraries and web page templates after examining a user’s browser and bandwidth for compatibility. Web applications such as Google Calendar might store your appointments locally, exposing this data to Google Maps or other mapping applications to plan the route to your next appointment without submitting a new server requests for the same data. Your webmail will be downloaded locally, quickly loaded even if you are on a plane.

I’m excited to see more applications start to use client-side storage available in modern browsers such as Internet Explorer, Firefox, and the Flash plugin. I’ll happily give up the space of a MP3 file in exchange for a better experience in my favorite web application. I think we’ll hear a lot more about client-side storage for web applications in the coming year.

  • Posted
  • Updated at
  • Comments [9]

9 comments

Commentary on "Boost Ajax performance using local storage":

  1. Kevin Burton on wrote:

    Hey. You missed a major local storage component: HTTP caching. Basically you take a JavaScript file and add a few HTTP headers.

    Cache-Control: public
    Pragma: public
    Expires: Tue, 30 Jan 2007 06:52:07 GMT

    Then you can fetch it and eval it from cache…

    Tailrank does this……. each generated page is cached for 10 minutes.

    … you also get upstream caching as well. You can use SSL if you don’t want upstream proxies to cache the data and only want it cached in the local browser.

    Check these guys out for more info:

    Caching Tutorial for Web Authors and Webmasters by Mark NottinghamServing JavaScript Fast by Cal Henderson

  2. Abdul Qabiz on wrote:

    Niall,

    Very nice post, thanks for it.

    I think, client-side storage is really important, as you said. We would see more and more Occasionally Connected clients in this year…

    I have feeling, Gmail might be thinking to use it…And it would be really great…

    Browsers need to be little more smart…DOJO offers some kit, I am yet to see but I feel we would see more such libraries and applications…

    -abdul

  3. FreightNose on wrote:

    Imagine a personal finance site storing your stock portfolio and historical prices locally

    A website can access not only data within its own subdomain or domain, but within a given top-level domain (.gov, .com, etc.) or any requesting page, creating some interesting opportunities for shared data namespaces.

    So how do I prevent other web sites from stealing my financial information?

    • Niall Kennedy on wrote:

      FreightNose,

      Local storage in my portfolio example is a convenience feature, a live version of a “save as CSV” or similar web to desktop translations we might experience today.

      Your information is bound to one of many zones, expanding on existing bounding models:

      sub.domain.tld*.domain.tld*.tld*.*

      Your portfolio data at MyFinanceSite.com could be stored locally and access restricted to requests from the originally storing domain. In the case of corporate intranets or a .gov you might want to share more information between sites, such as a congressional district or issues important to you and your family.

  4. William Walseth on wrote:

    We’ve had great success using IE’s userData in our applications. It significantly speeds up data entry operations, by persisting temporary data locally, rather than on the server.

    In very rare cases, users are surprised that they can’t see the temp data any longer when changing their Windows logon

  5. Saadullah Saeed on wrote:

    Hey great article, was very useful.Can anyone tell me if any browser other then IE and Firefox provide us with a local storage feature? Like if opera, safari or netscape etc. have this? I tried searching it up but didn’t find anything useful.

  6. owen on wrote:

    interesting and concise article. as soon as the browsers get together and come up with a single way to store local data its going to be hard to implement. But it leaves room for some interesting “webdesk” applications.

  7. Pierre Carbonnelle on wrote:

    JavaScript does not allow the protection of the intellectual property in its application : anybody can see the code by clicking “View source”. Developing JavaScript applications with local storage is nice, and I have done it, but this issue may limit its adoption for real applications such as in Finance.