270 Part II: Developing an Ajax Library^
Of course, this would make maintenance of the site quite difficult, so it is clear that
some automatic renaming process from the application or using a tool like w3compiler
(www.w3compiler.com) might be in order.
If you continue to feel the need for speed, consider the other half of the equation: besides
reducing what is delivered, try to avoid delivering often. When thinking about reducing
requests the obvious solution is caching, which we will discuss next, but there is the possibility
of bundling as well, where many requests are condensed into a few. You’ll see the dramatic
impact of that approach shortly.Caching
The second part of the performance mantra is never to send the same data again unless
absolutely required—this is the goal of caching. There are many types of caches on the
Internet, but in the case of Ajax, the user’s local browser cache is the primary focus. Keeping
received data in the user’s local cache helps immensely by avoiding going back to network
to fetch it again. Unfortunately, the benefit from client caches may not be as important as
you might think. A study in early 2007 by Yahoo (http://yuiblog.com/blog/2007/01/04/
performance-research-part-2/) shows that potentially up to more than half of their visitors
appear to have an empty cache experience when visiting the popular site. Most likely
privacy paranoid users are dumping their cache in some attempt to not have people know
where they have been or what they have done.NNOT EOTE The excessive cache clearing behavior user’s exhibit is unlikely to change, but if you fall into
this camp you might want to note that your browsing habits may be collected, studied, or even
sold by your ISP by logging DNS lookups or just raw router traffic. Furthermore, alternate
tracking mechanisms beyond cookies, such as Flash-based offline storage using shared objects, are
typically not cleared by a simple cache dump.Even if users aren’t killing their caches, there is plenty of misunderstanding about caching
from the Web developer’s point of view. Regardless of what end users do, indicating that
something is cacheable is important so that the user doesn’t have to download it again unless
needed, but how exactly do you go about doing that? There seem to be a multitude of
different headers to set, and setting them seems to be an adventure in server configuration
at times. A great online resource is Mark Nottingham Caching Tutorials (www.mnot.net/
cache_docs/). If you read the tutorials and run the various tests or view the results, you will
find, as we did, that the state of strict caching support in browsers is at best mixed and at
worst pathetic. Add in XHRs and caching and the situation doesn’t get much better. We focus
solely on those issues here otherwise you’d have another 50 pages to read.Busting Browser Caches
As mentioned a number of times in the book, Ajax and caching don’t really get along that
well. Currently Internet Explorer caches Ajax-fetched URLs by default, so if this isn’t
handled properly, subsequent requests may appear not to work. Interestingly, this may not
be inappropriate because a GET request should be cacheable if it is the same URL. Using a
POST isn’t an issue as the browser won’t cache the request. Regardless of your take on the
misuse of GET requests within the Ajax community, the usual response to the situation has