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.
Compacting: Simple Solutions
One approach that will benefit almost any web application is to use compact CSS techniques. Look at any CSS file for a large site and you will see many groups of entries similar to this example:
.textType1{
font-family: Verdana, Geneva, Arial, Helvetica, sans-serif;
font-size: 10px;
font-weight: normal;
color: #000000;
padding-bottom: 0;
padding-left: 4px;
padding-right: 0;
padding-top: 0;
}
.textType2{
font-family: Verdana, Geneva, Arial, Helvetica, sans-serif;
font-size: 10px;
font-weight: normal;
color: #000000;
padding-bottom: 0;
padding-left: 2px;
padding-right: 0;
padding-top: 0;
}
This common style is very easy to read and manage. It is also much larger than is necessary to achieve the desired visual rendering. Compact CSS for the same set of classes would look like this:
.textType1, .textType2{
font-family: Verdana, Geneva, Arial, Helvetica, sans-serif;
font-size: 10px;
color: #000;
padding: 0 0 0 4px;
}
.textType2{ padding-left: 2px;}
The compact example uses 231 or 58% characters, less. Most sites would have groups of five or six such definitions, resulting in even greater reductions.
Compact CSS does make it a bit more work when the CSS needs to be modified, so a judgment call should be made whether your source should be maintained in this way. However, you can run your CSS through a compacting application to generate highly compact CSS. There are commercial applications out there, but they aren’t that hard to build from scratch.
But Wait, There’s More
Similarly, compact HTML greatly improves page load time. Earlier, you looked at the savings achieved by using spaces instead of tabs. Think about how much your file sizes can be reduced by eliminating the tabs and carriage returns? Even though it is absolutely true that such HTML would be very difficult to maintain, it is very simple to create a parser that packs and unpacks HTML for editing versus deploying, or simply run the parser during deployment builds. The average file size reduction is 70%!
Looks Aren’t Everything, but They Help
Another page-load time saver is the use of Ajax, although it is a bit of a cheat. By loading larger page sections or sections that are lower priority asynchronously, the initial page load time can be greatly reduced. This approach needs to be designed with usability in mind. While the page would load really fast with all portlets being called asynchronously, the reason the user is there is to access the information in the portlets, not to read the disclaimer in the footer. I mentioned earlier this is a cheat, because the total page load time is actually increased using Ajax. The “speed” achieved by making parts of the page asynchronous is an illusion. The difference between a popular magician and a bore is whether they can keep your attention while distracting you from the illusion.
Another savings in file size is to use only XML with your Ajax when it is the best performing option. If the size of your final mark up and data combined is smaller than the XML document used to transport the data to be written into the markup on the client side, have your Ajax function get HTML instead of a larger file that then needs to be parsed. While the “x” in Ajax is for “XML”, it is because it is easier to pronounce than AJAXAH (Asynchronous JavaScript And XML and HTML).
Most of you have been taught (or chided by your IDEs) to put JavaScript between the head tags of the page or use a .js file. A JS file is fine, so long as it doesn’t contain all the functions for the entire site when only a small percentage are used on a per-page basis. Just as inflated CSS files hurt that first impression, .js files are treated the same way by the browser. If a script is needed only on a single page (and doesn’t need to be obfuscated) it is fine to have it inline, and place it at the bottom of the page, where it loads last. This way, the page will load without evaluating the script before painting the screen. The only caveat is to remember that the script needs to be loaded before the function call that uses it.
Portal-Specific Performance
Okay, these will work with non-portals applications, too. In fact, they are almost always done on non-portal sites, which is why the heading says “Portal-Specific,” so that folks who slept through this class in Web Design 101 will pay attention.
Global Warning
Although portals always consist of multiple pages with multiple styles, many portal implementations have all of the JS and CSS imports defined at a global level. This is incredibly wasteful from a performance perspective. I’ve seen project teams spend weeks working on how to improve the performance of how their infrastructure loaded a few JS files that were slowing the page load down because a security component was checking certain calls. Both of these files were used by single portlets yet were loaded on every call. Simply scoping them to the portlet that required them would have isolated the load time issue. One was for the login portlet (a necessary security annoyance … the script, not the portlet) and the other was for a rarely used profile portlet.
Inline: It’s Not Just for Skaters Anymore
The same goes for CSS. If certain portlets require very complex CSS, break those classes out into a separate CSS file and only load the CSS files necessary to a page. Also, even though using CSS over inline styles is a good rule of thumb, it should not be considered to be a capital offense to inline a style that is not used elsewhere and does not need to be shifted at run time. For example, if you have a global set of styles for table rendering and have a single portlet that needs a slightly wider margin or less padding, putting it inline will actually make maintenance easier and take less code than a new set of classes or extending the existing classes.
Similarly, if a single portlet has a very short JavaScript method to execute (like window.open() with no definition parameters), putting it inline is far more efficient than writing a function that must be loaded every time whether it is used or not.
Of course, if you have the same style repeated over and over inline, it should be moved to a CSS file, and if your inline script starts to grow it should move to a function, and to a JS file if it is needed in more places than one.
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.
Conclusion
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.
