Yahoo! Developer Network Blog
« Previous | Main | Next »
September 26, 2007
High Performance Web Sites: Rule 14 - Make Ajax Cacheable
People ask whether these performance rules apply to Web 2.0 applications. They definitely do! This rule is the first rule that resulted from working with Web 2.0 applications at Yahoo!.
One of the cited benefits of Ajax is that it provides instantaneous feedback to the user because it requests information asynchronously from the backend web server. However, using Ajax is no guarantee that the user won't be twiddling his thumbs waiting for those asynchronous JavaScript and XML responses to return. In many applications, whether or not the user is kept waiting depends on how Ajax is used. For example, in a web-based email client the user will be kept waiting for the results of an Ajax request to find all the email messages that match their search criteria. It's important to remember that "asynchronous" does not imply "instantaneous".
To improve performance, it's important to optimize these Ajax responses. The most important way to improve the performance of Ajax is to make the responses cacheable, as discussed in Rule 3: Add an Expires Header. Some of the other rules also apply to Ajax:
- Rule 4: Gzip Components
- Rule 9: Reduce DNS Lookups
- Rule 10: Minify JavaScript
- Rule 11: Avoid Redirects
- Rule 13: Configure ETags
However, Rule 3 is the most important for speeding up the user experience. Let's look at an example. A Web 2.0 email client might use Ajax to download the user's address book for autocompletion. If the user hasn't modified her address book since the last time she used the email web app, the previous address book response could be read from cache if that Ajax response was made cacheable with a future Expires header. The browser must be informed when to use a previously cached address book response versus requesting a new one. This could be done by adding a timestamp to the address book Ajax URL indicating the last time the user modified her address book, for example, &t=1190241612. If the address book hasn't been modified since the last download, the timestamp will be the same and the address book will be read from the browser's cache eliminating an extra HTTP roundtrip. If the user has modified her address book, the timestamp ensures the new URL doesn't match the cached response, and the browser will request the updated address book entries.
Even though your Ajax responses are created dynamically, and might only be applicable to a single user, they can still be cached. Doing so will make your Web 2.0 apps faster.
Steve Souders
[Steve Souders is Yahoo!'s Chief Performance Yahoo!. This is one in a series of Best Practices for Speeding Up Your Web Site. This article is based on Steve's book High Performance Web Sites, published by O'Reilly.]
Posted at September 26, 2007 8:51 AM | Permalink
Comments
Thanks Yahoo for the new rule. =)
Posted by: Mark Edward at September 26, 2007 5:38 PM
"This could be done by adding a timestamp to the address book Ajax URL indicating the last time the user modified her address book, for example, &t=1190241612"
Does that work across all browsers? I was under the impression that IE would never cache a HTTPXMLRequest response that has a parameter in it's URL. I haven't tested it, though..
Also, Wikipedia indicates that IE and Firefox use caching header differently (http://en.wikipedia.org/wiki/XMLHttpRequest#Caching). Is this the case?
Posted by: Nick L at September 28, 2007 3:45 AM
If you _don't_ want the XHR to be cached, you can modify the querystring, as seen in this example:
http://stevesouders.com/hpws/xhr-beacon.php
If you _do_ want the XHR to be cached, you can still include a querystring, but the parameters must stay the same, as seen in this example:
http://stevesouders.com/hpws/xhr-cached.php
In that example the XHR URL has a querystring, and yet it is still read from cache in both Firefox and IE. In order for the XHR to be cached, you have to do more than simply keep the URL constant. You also have to provide a future Expires or Cache-Control header, as explained in Rule 3.
It's likely that the person who wrote the Wikipedia article did not provide the necessary headers for the XHR to be cached. Or perhaps it was an older version of Firefox (I'm on Firefox 2.0, but am sure Firefox 1.5 behaves the same). Finally, it's possile they had changed their browser cache settings or were running a utility like Fasterfox that altered the typical behavior of Firefox. Bottomline: Firefox does cache XHR responses if the URL is the same and the headers set the expiration date in the future.
Posted by: Steve Souders at September 28, 2007 7:54 AM
thanx :)
Posted by: Steve at September 28, 2007 9:06 PM
Keep me updated!
Posted by: Mr. at September 29, 2007 2:20 PM
Isn't it a bad idea to make the addressbook cacheable on the browser since it may contain
user's private inforamtion? We may be better off having a server side cache that
authenticates the request with user cookies and serves the response back fast. just a
thought.
Posted by: gopal at November 26, 2007 2:09 PM
Data privacy is critical whenever thinking about caching. Each application must decide how to handle privacy issues. In my opinion, confidential information should be transmitted using SSL. I'll point out that the Web 2.0 versions of Google Mail and Yahoo! Mail do not have a single https request. The ideal situation, in my mind, would be to transmit over SSL and give the user the option about caching. Since I'm the only user on my PC, I would opt-in for caching. Fortunately, caching of https responses is supported in IE.
-Steve
Posted by: Steve Souders at November 26, 2007 4:15 PM
thanks for your rules,they help me much:)
But there is a problem,for a mail user,his client,ie,etc. need to post request to server timely so it can know whether there is a new mail coming. How to reduce these kind of request?Or whether there is someway that server can push some data to the client without using long-connecting?thx:)
Posted by: bwfyy at December 6, 2007 7:20 AM
We here at Siderean have been devotees of YUI since its inception. Most of the library has proven its worth. However, regarding cacheable XHR objects, we've tried your web page on IE6, IE7, as well as FF2.0.0.11. We've also tested on Mac OS X running FF 2.0.0.11. All tests of the web page seemed to have failed - i.e. the dialogue "The XMLHttpRequest was sent" appears. Has something changed in the caching mechanism ?
Posted by: Charles Riley at December 17, 2007 11:58 AM
Not to beleaguer the point, but we have confirmed the dialogue using http packet sniffers.
Posted by: Charles Riley at December 17, 2007 12:02 PM
Hi, Riley. Don't use the dialog box as an indicator of HTTP traffic. Instead, use a packet sniffer, as suggested in the instructions. The dialog box is just telling you that an XHR was executed. Even though the XHR is executed, on subsequent requests it's read from cache, which is the point of that demo page. To make it clearer I changed the message to say "The XMLHttpRequest was executed, but it MIGHT have been read from the browser's cache. Use a packet sniffer to see." When I run the demo (http://stevesouders.com/hpws/xhr-cached.php) on Firefox and IE with a packet sniffer I see that the second XHR is in fact read from cache.
-Steve
Posted by: Steve Souders at December 17, 2007 12:23 PM
Gopal@, You probably want to use "Cache-Control: private" to cache user specific content.
Posted by: Anomalizer at December 24, 2007 5:20 AM
I would like to open up a web site but i kind of luck knowledge of how to open or get one so pliz hlep me out in ma problem if yo to hlep send the data to my e-mail address.Thanks its been good jazzing with you
Posted by: loksey at January 25, 2008 10:23 AM
I was trying to implement this in my personal website http://www.rahulnimawat.com but there a dialog box comes up stating: "the xml parser expired" Please suggest me about this error and how to remove it.
Posted by: Rahul at March 29, 2008 1:04 PM
Post a comment
Comment Policy: We encourage comments and look forward to hearing from you. Please note that Yahoo! may, in our sole discretion, remove comments if they are off topic, inappropriate, or otherwise violate our Terms of Service. Fields marked with asterisk '*' are required.
Subscribe
Recent Blog Articles
view all
YQL Open Table for Google Buzz now live
Tue, 09 Feb 2010
INSERT INTO twitter.status ...
Mon, 08 Feb 2010
Announcing the Yahoo! Brasil Open Hack Day 2010, 20-21 March
Mon, 08 Feb 2010
Marketing hacks, linchpins, and tech women of valor
Sun, 07 Feb 2010
Yahoo! India invites you to join the first India Hadoop Summit
Thu, 04 Feb 2010
Recent Links
Appcelerator Titanium + Yahoo YQL on Vimeo
Mon, 08 Feb 2010
Tue, 02 Feb 2010
PhoneGap | Cross platform mobile framework
Sat, 30 Jan 2010
Web developers can rule the iPad - O'Reilly Radar
Sat, 30 Jan 2010
rc3.org - Is the iPad the harbinger of doom for personal computing?
Thu, 28 Jan 2010
Archives
2010
2009
2008
2007
2006
2005
Recent Readers

