Ajax Performance Analysis

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."

Comments

A capacity planner's niggle

[davecb]

It's actually useful to break the response time out into three parts:

1. 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.

2. 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:Yahoo's Problems Are Not Your Problems

[Bogtha]

Hmm, I'm not so sure about some of that. For instance:

Yahoo recommends turning ETags off because they cause problems on server farms due to the way they are generated with machine-specific markers. So unless you run a server farm, you should ignore this guidance. It'll only make your site perform worse because the client will have a more difficult time determining if its cache is stale or fresh. It is possible for the client to use the existing last-modified date fields to determine whether the cache is stale, but last-modified is a weak validator, whereas Entity Tag (ETag) is a strong validator. Why trade strength for weakness?

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.

All you're really saving here is the cost of the client pinging the server for a new version and getting a 304 not modified header back in the common case that the resource hasn't changed. That's not much overhead.. unless you're Yahoo.

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.

Client-side execution

[truthsearch]

I recently did a performance analysis of a complex site I've worked on for over a year. My primary tool was Firebug. While the size of the HTML + CSS + JS per page is pretty large, it turns out compressing them and setting header cache only saw a small performance improvement. The execution of JS like Scriptaculous actually accounts for more than 50% of the time it takes to render the pages. Since we only use Scriptaculous for drag-and-drop we're considering alternatives, like mootools or custom code. Loading as much JS as possible from the bottom of the page instead of the head can help, but isn't always an option. Focusing on CSS and JS performance has now made a huge improvement in perceived site performance.

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.

NoScript

[slashgrim]

All websites should have an option to run without fancy Javascript (and still be fully functional!). It makes no sense that a web site should bog down my 400Mhz PDA.

Re:There's a place for innerHTML.

[larry bagina]

theFont.appendChild(document.createTextNode('Hello World'));

If it is supposed to be text, createTextNode will properly handle &, <, etc, whereas innerHTML won't.

Take Firebug with a grain of salt

[TLLOTS]

While I love Firebug and use it daily for web development, you shouldn't trust its net tab too much. I've found in numerous instances it has grossly understated load times, for example loading a very PHP heavy page which Firebug claimed was loading in 13ms, however serverside performance testing showed that the load time was actually over 1 second. I've actually found Safari's new Web Inspector tools to be much more accurate in this regard so I'd recommend using them for performance testing if you suspect Firebug isn't telling you everything.