This really depends on the library you are using and getting the
server and XHR cache to work in sync w/ content-negotiated responses.
There is a bunch of stuff if you Google "XHR caching". However I
usually put this step in the "tuning" category when you are testing,
there are a few testers out there (Selenium I think?) which will
automate and give you a report. The unit tests for these libraries
usually have some details on what it's doing.
- Jon
On Jan 12, 2007, at 9:58 AM, Kenneth Downs wrote:
We've all seen the amazing results you can get when you start using
Ajax, they all come down to one thing: speed.
Question is, how is such a speed-up accomplished? The standard
answer is that a complete trip to the server is averted, but this
is not true, in fact a complete cycle does occur:
1) Request to server
2) Possible db access on server
3) rendering of HTML on server
4) delivery to browser
5) re-rendering of portions of screen
Supposedly the js and css libraries are cached so we have not saved
the effort of retrieving them, this means the only thing we have
saved is the effort of re-rendering the screen from scratch. To
put another way, we have not saved a whole lot of bytes of traffic,
or CPU cycles on the server. The only thing that seems to be
missing is the render-from-scratch on the browser.
Is this correct? And if so, why is it so dramatically expensive to
render a page from scratch, that Ajax could make such a dramatic
improvement to the situation?
<ken.vcf>
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
