Ajax Performance Analysis 36
IBM Developerworks' latest was submitted to us by an anonymous reader who writes "Using Firebug and YSlow, you can thoroughly analyze your Web applications to make educated changes to improve performance. This article reviews the latest tools and techniques for managing the performance of Ajax applications along the life cycle of your application, from inception through production."
Yahoo's Problems Are Not Your Problems (Score:3, Informative)
A good review and counter-argument is available at the "codinghorror" blog where Jeff Atwood points out the codinghorror blog [codinghorror.com]Yahoo's Problems Are Not Your Problems
--dave
Re: (Score:2)
Bother, I meant Yahoo's Problems Are Not Your Problems [codinghorror.com]
Re:Yahoo's Problems Are Not Your Problems (Score:4, Informative)
Hmm, I'm not so sure about some of that. For instance:
Because "strength" isn't anything particularly important here. The difference between strong and weak validators is that a strong validator is supposed to change even if only minor alterations take place (e.g. spelling mistakes), while a weak validator can remain the same if minor changes take place.
In practice, I've never seen anybody make a distinction like this for websites/web applications. If anybody did bother, then weak validators would be more efficient, as they would have a better cache hit ratio. For all intents and purposes, there is no difference between a strong and a weak validator. But what you are doing is computing and transmitting useless ETag headers with every single request you serve, so it is beneficial to turn them off, even if you don't have a server farm. Last-Modified is good enough for practically everybody. If Last-Modified isn't good enough for your purposes, then you don't need to be told to switch ETags back on, you know what you are doing.
Well how much overhead it is really depends on what it is you are doing. If it's expensive to figure out if the resource has changed, you don't want to incur that expense a lot, for example naïve dynamic stylesheet implementations can noticeably slow down a site. And remember, even if you have a fast server, it doesn't mean your users have a fast connection, and going back and asking the server if things have changed for a dozen resources on the page when you know for a fact you don't change them for months at a time is ridiculous.
His basic point, that you shouldn't take Yahoo's advice as gospel is good, but you shouldn't automatically assume that efficiency is only something that benefits giants.
Re: (Score:1)
You're right about ETags. ETags are useful when you have cached, dynamically-generated content, and can't use Last-Modified. Well, you could use it, but handling faking that is more complicated than just running the end result through crc32().
Anything else and ETags are just just dumb. OTOH, they're not actually slowing anything down for the end user.
OTOH, YSlow's still stupid here, because it makes some crazy comment about server farms. Look, Yahoo, I don't know who you think is using this software, but
Re: (Score:2)
Actually, 99.999% of websites probably do not run on a dedicated server but on a shared host - most of them using some sort of cluster solution. Which is precisely why ETags won't work unless you turn off the server defaults so you can generate your own using server-independent data.
Stop dissing
A capacity planner's niggle (Score:4, Interesting)
It's actually useful to break the response time out into three parts:
1) Round-trip time, the latency from the network
2) Transfer time, the time from receiving the first byte of the page to the time the last byte arrives. This varies greatly with page size, and is the time you use to do KB/S calculations as well.
3) Latency proper, the time between sending the request and receiving the first byte of the page. This is the time that grows during an overload, and the one that capacity planners use to do queuing models to see how much the server will slow down by under an overload.
--dave (a capcity planner) c-b
Re: (Score:1)
Re: (Score:1)
(I am a TTDPatch developer)
Writting code in assembly does not equal significant speed or efficiency increase unless you *really* know what you are doing, and are prepared to put a lot of effort into very implementation/processor specific/obscure optimisations (it probably does mean a reduction in code size though, but hardly anyone cares about that these days
Just using a bette
Re: (Score:2)
AJAX makes a lot of little calls back to the server and it is critical that they are processed very quickly to give the site a responsive appearance, there is
innerHTML??? (Score:2)
The author appears to endorse the use of innerHTML as opposed to DOM manipulation.
I suppose it has its place in a performance analysis, but mention might be made that it's just not worth the trading off standards compliance and futureproofing. When I see innerHTML being manipulated I assume the designer didn't know what he was doing.
There's a place for innerHTML. (Score:2)
<html>
<body>
</body>
<script language="javascript">
theDiv = document.createElement("DIV");
theFont = document.createElement("FONT");
theFont.style.fontFamily = "verdana";
theFont.style.fontSize = "24";
theFont.style.fontWeight = "700";
theFont.innerHTML = "Hello World!"
theDiv.appendChild(theFont);
document.body.appendChild(theDiv);
</script>
</html>
Re: (Score:3, Informative)
theFont.appendChild(document.createTextNode('Hello World'));
If it is supposed to be text, createTextNode will properly handle &, <, etc, whereas innerHTML won't.
Re: (Score:1)
The purpose of the article was improving performance and response times. This means trading in practices which one should be doing to optimize for what works best. While DOM manipulation may be the standards compliance way of going it is dramatically slower than innerHTML [quirksmode.org]. It is only recently that Safari and Opera have been able to increase the speed of DOM manipulation [hedges.name], but sadly IE and Firefox (the two more used browsers) show better results for innerHTML. In my own testing Firefox 3 was closer to the Ope
Client-side execution (Score:4, Insightful)
During the initial development we never considered that simply loading one JS library (even when it's not used for inserting HTML) could slow down page rendering that much. On JS or CSS heavy sites, client-side loading, rendering, and runtime execution can easily account for 50% to 90% of the time it takes to see a final page. So while I've usually focused entirely on server side performance, I now know to pay more attention to the speed of client side rendering. Lesson learned.
Firebug essential; YSlow useless (Score:3, Informative)
YSlow is worthless for me. Where I work, I do web development on the intranet. I do not configure the servers, and don't really even have the ability to do so. On the other end, any stuff I might do on the internet will most likely be hosted by some hosting company. Many of the things that YSlow flags are server config items, not *code* items. Sure, that has its place, but if you are a web developer (not a SA) then YSlow gives you a bunch of useless info, then a low grade if your servers are configured a certain way. Ironically, it comes from Yahoo, the masters of the bloated web page. Come to think of it, I should probably get around to uninstalling it instead of just leaving it disabled.
NoScript (Score:3, Insightful)
Re: (Score:1)
Re: (Score:1, Interesting)
Re: (Score:2)
Odd: my 750 MHz box flies on the new system, using a pretty old Mozilla, version 1.7
--dave
thanks! (Score:1)
Depends ... (Score:3, Funny)
All I know is, my floors have a nice shine.
Re: (Score:2)
Ajax, JS and sites like Digg.com (Score:2, Informative)
Take Firebug with a grain of salt (Score:4, Interesting)
JSON v XML, XSLT vs dom rendering (Score:1)
It's probably unrealistic to want a web page to present a christmas-tre
Re: (Score:2)