
« Yahoo! Search SDK Revs A Bit | Main | Checking In from Adobe MAX »
September 26, 2007
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:
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
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
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.
Copyright © 2008 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Copyright Policy - Job Openings