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.