Web 2.0 Performance Optimization - Get an A on YSlow!

Okay, first off I have to be honest and admit that we only managed to get a high B on YSlow, with a score of 86. We weren't able to use a CDN, so that category dragged down the overall score. A CDN would easily get us to an A, and a relatively high one at that.

Some of you read that first paragraph and it made sense, others of you may be wondering at some of the jargon used. In this series of blogs I'll be covering a variety of technologies and techniques, and I'll try to clearly define them. If something isn't making sense, Googling a bit can help, but if you post a comment I'll post a reply trying to clear things up. Here are a few that might be helpful when reading these entries:

• BEA WLP (WebLogic Portal) 10.2- A J2EE (okay "Java EE", sheesh) -based enterprise portal
• DVT (Dynamic Visitor Tools) Sample - A Web 2.0-based front-end for WLP apps
• Dojo 1.0.x - An Ajax toolkit that is used in WLP 10.2 for the DVT sample
• Apache HTTP Server - Popular web server
• gzip (GNU Zip) - compression utility
• PNG (Portable Network Graphics) - Lossless image compression format
• Firebug - Add-on for Firefox that provides diagnostic information
• YSlow - Add-on for Firefox that works with Firebug to provide site optimization information
• Fiddler - Add-on for Internet Explorer that provides diagnostic information
• CDN (Content Delivery Network) - A system for distributing content across a network

There are a number of other tools and utilities that I'll discuss, and I'll try to provide links to them where possible.

When we first went live with the WebLogic Portal 10.2 Playground we asked a number of people to try it out and provide feedback on the performance. Some of the reports were glowing, with users saying that it was very fast, while others reported extremely slow page load times. We began by looking at the server-side configurations, tweaking and tuning the WebLogic and Apache servers, which helped a bit. After a while it became obvious that some machines were being overwhelmed by the number of requests, and the size of the responses weren't helping either. No amount of caching or other server tuning was going to solve all of the issues that we were seeing, so we set off on our quest for speed.

We'll cover the details of this quest in the next few blog entries, but for now let's look at some before and after screenshots. These were captured using Firebug and YSlow for Firefox, with caching enabled but after a recent flush. This is after logging into the site to ensure that the maximum number of JavaScript files, images, etc. are shown. Note that the results have been trimmed a bit, with only the top and bottom shown.

Here are the Firebug results for the original site:

Compare this to the results for the optimized site, with far fewer requests, far less downloaded to the client, and a much faster response time:

YSlow, a great tool from the Yahoo! Developer Network, provides grades for website performance, suggestions on how to speed things up. Here is the original site:

Here are the YSlow results for the optimized site:

As you can see we've managed to improve everything quite a bit, with only the use of a CDN keeping us from getting that A. We would also get a B for the Make fewer HTTP requests if we turned of localization, or if we interned the localized strings, and we could probably get to an A on that if we combined a few of the remaining JavaScript files. At this point we're happy with the progress, especially when the optimized results are compared with the original. To summarize, here are the improvements:

• Number of requests - 135 - 26 = 109 fewer requests
• Size of responses - 1064k - 171k = 893k smaller
• Total response time - 42.15s - 1.86s = 40.29s faster

Once the browser caches are primed the original site will get faster, but in the best cases it is still 3 or more times slower, and it can be much slower in certain circumstances. We can be thankful that the web, the browsers, the servers, and more are reasonably efficient, but there is no magical solution. Or as I like to say, even BEA hasn't figure out how to use quantum physics, wormholes, or magic to get around the laws of nature. What we can do is try to understand the problem and take the steps to create solutions, and thankfully none of it is truly rocket surgery.

Look for follow-ups on this over the next couple of weeks, with plenty of details. If you have any questions or suggestions, I'd love to hear them.