Improving Portal Page Load Performance

In Portal Performance Planning, you learned about addressing performance at a high level, moving from stage two to stage three of the four stages of competence. The path to the fourth stage (unconscious competence) begins when your project teams move past the planning stages and begin performing the low-level implementation tasks repeatedly until people are surprised on the rare occasions where they don't occur. This level requires the development teams to have the knowledge and tools to write high-performance code and know how to track down and fix the inevitable "gotchas" and "oopses."

Because there are many, many articles available on addressing performance for web services, databases, and control classes, you will look at the forgotten realm of the presentation layer for ways to wring out those extra few milliseconds that can mean the difference between user-friendly and unusable. I'm often surprised how many people in IT say "but it works" when no one will use an application due to its performance. If a byte loads on the screen and there is no one there to see it, it didn't make an impact.

The goal here will be to point out some obvious fixes that used to be common and have fallen from common practice over time; some not-so-obvious approaches that are often only considered when performance is so dismal that people start digging deep into the manuals (and that using all the time will make life much easier); and a few you've-got-to-be-kidding approaches that will improve performance, though sometimes sacrifice maintainability (a tough call for any development team).

You also will look at some approaches for tracking down those elusive performance killers that always crop up. These bugging bugs occur because habits that would avoid them haven't reach stage four yet, or when code is randomly updated to address changing requirements (or unstable requirements, depending on the perspective your role gives you), when teams are rushed by tight deadlines. (Question: Why is there never enough time to do it right but always enough to do it again? Answer: Look at your project plan for gaps between time allotted for planning, development, and debugging) and the fact that you are human and technology is changing and it just isn't possible to plan for everything (someone once told me perfection is not a destination but a direction that is good to follow.)

The Usual Suspects

To an expert in almost any trade, the classic approaches are often considered to be the best approaches.

Graphics Are Cool ... Not!

Graphics have always been the biggest performance hit and still are. In the "bad old days" of web development it was often the same developers who wrote the scripting language, mark-up code, and converted graphics for the site. Although the specialization of developer roles has contributed greatly to the capability for web sites to do more, the rapid division of responsibilities and differences in the definition of a role from one IT group to another has led to some tasks no longer being done.

Every graphic should be optimized for minimal file size. If this seems like too large of a task for your application, that is a clear indication that graphics are being over used from a performance perspective. If you (or your visual designers) can't be convinced that less is more with images, you can still purchase software that will optimize your images automatically for you (and I would recommend one except it has been years since I have needed such a tool).

Even though graphics are important for branding purposes, careful review should be given to each graphic proposed if it is worth the performance hit. A graphical bullet point may be give a great impression in a presentation, but most portal users would much rather get to their data points quickly rather than be impressed with how pretty they look.

One common example of unnecessary image use is the clear images used by some developers for spacing purposes. This approach is a sign of either laziness or lack of CSS knowledge. I recall one project where days of man-hours were wasted tracking down an issue in printing a simple web page. The developer had used clear spacer images that loaded fairly well in the browser (they were optimized, at least) but when printing, each image was read into the printer buffer individually.

Another frequent misuse of images is for text. Even though it makes perfect sense that a logo or trademark require absolute control over font style, size, and spacing, if a user doesn't have the font your visual designers chose for navigation links it is because they don't care whether that font is used on a page. CSS provides for the ability to provide specific font options, a far better performance choice (unless over-used).

Breaking the Rules When It Works

Rounded corners are another realm where images are over-used. The same effect can be achieved using nested tables. This is a trick I picked up working with a portal product that provided the administrator the ability to change color schemes by entering new color values, but did not provide for choosing a different CSS class (which could have loaded a different color image). To maintain this feature, I re-created the exact curves from the visual designers' graphics using nested tables.

Although there was a time when nested tables caused performance issues, this is no longer true unless the tables are not coded properly. It is still true that using a table for anything other than data is considered by some to be an improper use of the mark-up language, and I will leave it to you if being "perfect" is more important than performance. Even though there is a valid argument for not using tables in this manner to better integrate with special-use browsers, it is probably a better approach to provide an entirely alternate look-and-feel for such browsers because their users won't notice the rounded corners anyway.

You Can Never Be Too Small or Too Fast

One other basic trick I learned while working for a company that was extremely proud of winning the fastest-loading site award for several years running. They always used tabs rather than the three or four spaces for indenting their markup. This is an adjustment that all HTML editors provide and I have seen where it reduces file sizes by up to 80%. Even if your page is entirely text, you will get a much faster load time of the data sent to the browser is 1/5 the size and still contains all of the same human-readable information. It is possible to write build scripts that will change space indents to tabs for existing code, though if you go that route, read the Counter-Intuitive Counter Measures section first to achieve even higher performance returns.

Counter-Intuitive Counter Measures

Okay, so you've reduced your graphics by using CSS. Guess what? Now, your CSS files have become larger. This is one of those things that are often missed in tweaking page performance because the CSS files are cached by the browser. Although this makes for a one-time performance hit, for many web applications first impressions are everything. Even if it is only the first time the user comes to the page that they experience a delay, many users will seek another site rather than wait for that first page to load.