Improving Portal Page Load Performance, Page 3
Shh! I'm Bug Hunting
I only know three ways to track down those little annoying performance killers that are too rude to make themselves obvious. Please send along any other methods you know of.
Sawing Logs to Keep Pages Awake
The first is every developer's friend: logging. Almost every web server has an option that can be enabled to log the file size and response time of page components. To state the obvious, you really don't want to do this in production, and probably don't want to do it in the test environment except when trying to track down some errant script that is malformed or an image that was missed during your optimization process.
Old-Fashioned Eyeball Grease
Sometimes, it is a combination of components that cause the slow down. In that case, there is naught but the old-fashioned and tedious process of removing all the components from a page and adding them back one at a time and measuring the difference. Brutally boring and effective every time.
Yahoo!, I Found It
If you dread the old-fashioned way as much as I do (and I've done it often enough to truly dread it), there is the wonderful new-fangled approach provide by Yahoo! called YSlow. YSlow works with the Firefox Firebug plug-in, another great tool for finding annoying scripting errors. Unlike many free tools, YSlow is well documented and can be downloaded at http://developer.yahoo.com/yslow/. YSlow will not only show you file size and load time for every little thing, it also will give you a grade for each performance aspect of your page.
In the days of 14,400bps, page load time was the holy grail of web site development. Many of the techniques covered here are simply review for those who built sites before Internet access was ubiquitous and high-speed connections were only available at the office. Portals fill bandwidth faster than it expands commercially, and the more advanced solutions you looked at were born of the understanding that playing on the bleeding edge requires a thick skin or lots of bandages. The faster the connections and the higher the bandwidth, the less patient users become. Fast-loading pages will always be a requirement. The capability to provide them without working Dot Com hours at post-sub-prime wages is an art and science that should be maintained for the sake of those who use your applications and your own sanity. Plus, it's cool to be fast.
About the Author
Scott Nelson is a Senior Principal Consultant with well over 10 years of experience designing, developing, and maintaining web-based applications for manufacturing, pharmaceutical, financial services, non-profit organizations, and real estate agencies for use by employees, customers, vendors, franchisees, executive management, and others who use a browser. He also blogs all of the funny emails forwarded to him at Frequently Unasked Questions.