Use of AJAX To Conserve Bandwidth and Processing
Ever noticed in Gmail, Twitter or Facebook how the last portion of the URL (the so-called “hash”) changes with each navigation, while the actual URL remains the same?
This unique AJAX technique, employed by some of the top current Web 2.0 apps, has many benefits besides usability: it actually saves the bandwidth of the site by an astounding amount, and defers the latency of the new page’s loading to the responsibility of the client-side web browser’s script compilation instead of downloading a new, full page each change in navigation.
The Basis of the Technique
If you want to see this in action, simply click on your replies within Twitter’s web client, do anything in Gmail/Google Wave, or click a profile/photo in Facebook – watch the URL, particularly the last part (everything past the ‘#’ character, called the “hash” by many.)
Basically, it works like this: whenever you perform an action that requires a change in navigation, e.g. clicking a link to go to a profile or to view an email, a JavaScript “onclick” event handler for that link calls a shared “AJAX load this page” function that begins to load the data required to change the page.
Also, it updates the URL’s post-hash characters to make the “new page” bookmark-friendly in case a user wants to go directly to that page as if it were static HTML instead of a dynamic client-side scripting-dependent page instance.
Likewise, each time a page within Gmail (or whatever app) is loaded, it checks for hash characters and will load the data into the page, transparently to the user. Because of this, most of the time the characters after the hash is simply the latter part of a URL to be inserted into the AJAX function to load the page, e.g. the characters necessary to download a page called “http://www.gmail.com/”+hashtag etc.
Benefits of this System: bandwidth
Most professionals use this simple AJAX technique to simplify the navigation of their site and to track user activity, but there is an often-overlooked advantage to using this model: bandwidth conservation and faster loading speed via deferred processing.
Here’s a rudimentary example: when your web app doesn’t use AJAX-loading and instead relies on unique page loads each and every time the user navigates to a new page, here is what is sent to the client’s web browser each time, following server-side processing:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head profile="http://gmpg.org/xfn/11">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Title Here</title><script src="../../script.js" type="text/javascript"></script>
<!– keep in mind that each time this full page is loaded, server-side scripting is executed for tasks like query-string/post-data processing and file inclusion – therefore heavy processing amounts and file system I/O is required –>
<link rel="stylesheet" src="/style.css" type="text/css" />
<meta name="description" content="every little character counts!" />
</head><body onload="load()">
<!– site-wide navigation bars, formatting dividers, and other common page elements go here, followed by the actual page-specific content that could have alternatively been loaded directly via AJAX –>
</body></html>
Keep in mind that the example provided only a small subset of what most sites, especially web applications, usually entail within a typical page: most of the time, heavy server-side processing and many scripts/stylesheets are included in every page load along with the sizable chunk of site-wide formatting elements (i.e. div’s etc.)
Even if the browser caches these files and page snippets, the inclusion statement still represents an unnecessary amount of bandwidth when multiplied by the number of concurrent users.
However, if a page uses AJAX-loading to load new content into the existing page, all of the above example code would only be loaded once, including site-wide elements such as navigation menus and general formatting sections.
Instead, the AJAX would only request “page-specific” content such as a particular email’s content (in the case of Gmail) and insert it within the existing page, which only had to load once.
This way, once the common site elements are loaded into the browser, only the changing content needs to… well… change. This can lead to tremendous savings on bandwidth, which is important when many users are hitting the site at once.
(props for still reading this longer-than-normal article – hang in there!)
Another benefit: Processing speed
When most browsers process a script, they first download the plaintext .js file from the server upon seeing it’s inclusion statement within the HTML. Then, they compile it directly to native code (or some similar action) and store the compiled JavaScript into the browser’s cache for future execution.
So, when the initial page is loaded, the included AJAX script for loading future content is compiled and cached, making it’s future execution very fast. This lowers the latency involved on the client-side when downloading future content to be loaded into the running page, and since bandwidth consumption is kept to that of the content’s usage only, the process is extremely fast compared to loading a full page each time.
Further Enhancements
If the server and web browser are configured properly, then the Apache mod_gzip/mod_deflate could further boost the speed of this process. This puts more of the loading process in the realm of processing and conserves bandwidth more, and qualifies as an enhancement since bandwidth is more of a scarce resource than processing power.
In other words, you’re more likely to see a quad-core on a DSL or shared cable connection than a Pentium III hooked into a T3 line, so lower bandwidth in favor of processing time in most situations while employing sniffing practices to ensure mobile accessibility.
Speaking of accessibility, notice that on most AJAX-employing Web apps that although there is a JavaScript event handler associated with a link, they don’t forget to keep the link intact: there is no ‘href=”#”‘ in Gmail or Facebook – a quick look at the status bar while hovering over a link will reveal basic accessibility fundamentals in practice.
This, combined with appropriate JavaScript feature degradation (without resorting to NOSCRIPT tags) will ensure accessibility while using this advanced technique: if the client doesn’t support AJAX loading or JavaScript at all, then fall back on regular site loading using full page requests.
Since only a negligible amount of users fall into that category anyway (including Googlebot and other crawlers), the loss of performance due to a few client requiring full page loads is relatively small.
Final Notes
So, as seen in the examples above, the use of AJAX content loading within web apps, as employed by Gmail and Facebook, has numerous advantages to the site and its usability while remaining transparent to the users.
Best of all, if done correctly, it can be unobtrusive and therefore non-impacting to a site’s SEO or accessibility.
Almost everything discussed here neglects the role and possible optimization in the server-side scripting involved in all this, but each web app is unique and therefore can be optimized to best suit the situation as far as server-side optimizations go: just keep the main page’s inclusion rate low so the initial page loads fast, and keep the “dirty work” required by the server-side AJAX handler to a minimum.
Also look into distributing the load between several scripts to handle different types of AJAX requests, reducing query-string parameters and the conditionals involved in their processing, and even look into distributed computing (mod_proxy and it’s family) for self-hosted web apps with large scalability requirements.
In addition, the AJAX-handlers can be easily made into a rudimentary API for a web app you may want to make available for an iPhone/Blackberry app, or if you wish to open it up for any client as Twitter and FMyLife.com have done.
One thing is certain, however: whatever the aim of your web app may be, with very few exceptions, you will almost certainly benefit from this JavaScript AJAX programming technique upon its deployment within your site or app.
I hope this will convince more app authors to move to this system of page loading. Until next time… 
There are no comments yet, add one below.
