In the first entry in this series Web 2.0 Performance Optimization - Get an A on YSlow! I included a few screenshots of before/after results from Firebug and YSlow. These aren't the only tools available, but they are among the best at the moment, and are invaluable for diagnosing problems in your web applications, even those you may not be aware of.
How do you use these tools? They're actually fairly easy to use, with straightforward user interfaces that integrate nicely into Mozilla Firefox. There is something called Firebug Lite that works in other browsers, including IE, but this is really just a console and not the same thing at all. There are some tools for IE that I'll discuss, and it looks like Microsoft has copied the Firebug features in the IE8 Developer Tools. These tools are only going to get better, and I believe we're just starting to scratch the surface in this area.
So how can you use them? Let's take a look at Firebug, selecting the Net tab and All subtab and viewing the results for a non-authenticated user on the Welcome page on the optimized wlp.bea.com site. Note that I've cleared all of the private data (cache, cookies, etc.) in order to see what the raw performance of the site would be for a first-time user:
As you might guess, clicking on the various tabs for JS, CSS, and so on will show you the results for only those object types. When there are only 20 or so files total as in the optimized site this isn't really a big deal, but when you look at the results for the non-optimized site the value becomes apparent:
If you are surprised that the non-optimized site took 25.24s to finish loading, I can promise you that we were even more surprised by it. The funny thing (and I don't mean that in the good sense) is that one of the biggest problems turned out to be the Symantec/Norton Client Firewall, which is installed and active on most BEA employee machines. This is not meant as a knock on Symantec or their products, but this firewall has a very annoying feature that causes issues with gzipped files, JavaScript files in particular.
This firewall is acting as a proxy for any internet connections and is decompressing the gzipped files before sending them to the browser. The good news is that the gzipped files are being sent from the server to the client, reducing the network bandwidth. The bad news is that it appears to be scanning the files after decompressing them, adding some overhead. This gets far worse when there are lots of JavaScript files as it appears that the firewall is processing them sequentially, limiting the connections to the server, or both. The even worse news is that there doesn't appear to be a way to disable this "feature" for known and trusted sites, although I remain hopeful that they'll enhance it at some point. The only workaround at the moment is to disable the firewall entirely, not something that everyone will be comfortable with.
Here are the results for the non-optimized site with the firewall disabled:
We still have the same large number of requests, but the size of the download has decreased by more than 3X and the page rendering time is 4X faster. That's not bad, but we're still far from what we'd like. Over the next few blog entries we'll see how we can optimize the site to have 4X fewer files, 1/2 the download size, and render the pages over 4X faster.
Now let's take a look at YSlow, which is thoughtfully integrated into Firebug. Here are the performance results for the original non-optimized site, with the firewall enabled:
Seeing the big fat F was depressing, although after looking around at various well-known Web 2.0 sites I knew that many of them weren't much better, and even the best of them still got a C. As a long time BEA employee and a true believer in performance and scalability, I was not going to rest until I got a C or better, and an A was always the target. Here are the results today for the optimized site:
As I stated in the first entry, using a CDN would easily get us that A. Disabling localization would also do it, but that's not very friendly, and I have some ideas on how to provide localization while reducing the file request count even further. The cool thing is that we're now looking into ways to provide some or all of these optimizations automagically in the server, using the PRODUCTION_MODE flag to toggle them on or off. I can't promise these for the WebLogic Portal Sunshine release currently scheduled for later this year, but we're going to try.
If you've read all of this and are wondering what the effects of disabling the firewall are on the original site, here they are:
In Tommy Boy the late, great Chris Farley shouted out "D+?... Oh, my God... I passed! I passed! Oh, man! " A 60 isn't a D+, and it's nothing really to shout about, but hey, I liked the movie and the quote, and it's somewhat fitting. I won't name or shame them, but there are plenty of interesting and well-known sites out there that are even worse off, and we haven't even started to optimize our site yet.
You may recall that I listed Fiddler in the earlier blog entry, an add-on for IE. It's not really the same thing as Firebug, but it can provide similar information about the files, download sizes, times, etc. In some ways it offers even more information, but quite frankly it doesn't feel as seamless as Firebug. I would suggest having it in your arsenal and using it, but personally I tend to develop on Firefox first using the various tools it offers and porting to other browsers.
In the next entry we'll start looking into how to reduce the number of files, as well as their size. The nice thing is that there is a huge improvement to be made by simply enabling production mode on the server, and as I said earlier in this entry we'll be looking at how to extend this even further in the future.
No comments:
Post a Comment