Related Article(s): Usability testing with children How to improve your site search (...or ‘looking for jamie oliver’) 8 guidelines for usability testing The seven deadly sins of web design Good Landing Page Design Tips Designing for accessibility Accessibility... The Basics. Keeping your graphics safe online

Home Design & Layout Web Code Optimization. Google does it. Yahoo! does it. Why don't you do it?

Print

Email

Web Code Optimization. Google does it. Yahoo! does it. Why don't you do it?

Google and Yahoo! know that speeding pages to their users is crucial. Both companies have invested millions of dollars in the server capacity and software enhancements that it takes to quickly serve search results to millions of users everyday. However, the optimizations that these companies perform do not stop at infrastructure investments. They optimize the delivery of their data right down to the data itself.

Have you looked at the page source of a Google query? They implement some smart coding practices that, when applied consistently, add up to significant page size savings. They use concise JavaScript code. Their function and variable names are always terse. Their CSS IDs are one or two characters long and the color values commonly use three digit hex values rather than six digit values whenever possible. They don't send a lot of white space in their source code either.

Companies concerned with quickly serving millons of pages know that the cumulative effect of these optimizations can result in significant savings. These optimizations aren't much to look at when you view the source of the pages in your browser. This is because the code is designed for speedy delivery to your browser's rendering engine, not for the human eye's perusal through the View Source option in your browser.

In the case of Google and Yahoo!, these smart coding practices were most likely designed into the development of their applications. Unfortunately, many Web authors and developers are forced with the task of applying smart optimization practices to an already complete Web site. There are ways that you can easily perform the same types of optimizations on your existing Web site code. Using a good Web site optimization tool is the best way and it can lead to substantial savings on any Web site. Here's an example of how much can be saved on a typical Web page using a Web site optimization tool like w3compiler to apply some of these techniques.

In this case, we'll look at Intel's home page at www.intel.com:

That's a 51% savings on Intel's homepage alone using the w3compiler. How does the page get from A to B? It's just an aggressive application of the principles used by sites like Google and Yahoo!.

Here are some of the ways w3compiler achieves this level of savings (and speed/security for your Web app):

Remove White Space
This is the most obvious optimization when you view the source of the optimized page. This is also the reason why many Web page optimizers in the past have gotten a bad rap. Although white space provides no benefit to a Web site user at all, removing it in an unsafe manner can result in broken pages. Many shareware white space removers are guilty of this. An optimization tool must be truly aware of the intricacies of complex Web site code to safely remove white space without breaking code or causing display errors.

Some complain that it also produces page source code that is hard to read. This is really not a valid criticism though. Do your users need to have a nicely formatted view of your Web page source code? Will they be doing some editing for you? Since the optimizations recommended here are purely for deployment, it makes much more sense to maintain a copy of the source files without any optimizations nicely formatted for editing and to generate an optimized version for deployment that is geared towards delivery. That's exactly what a tool like the one we used here does. That makes applying optimizations like these easy for completed Web sites.


Substitute Entity and Color Values, Remove Meta Tags
Good Web page authors know that there are multiple ways to designate entity values and color values in your HTML and CSS files. Some hand coding optimization articles suggest using the shortest option for your entity and color values. How often have you as a Web developer been able to research each value you add to determine the shortest? It's labor intensive and usually not worth doing in a once-off fashion. Oftentimes HTML authoring software adds these values without requiring you to know the underlying hex values anyway. Once your Web site is complete, however, it makes sense to optimize all of these values to the shortest value. These are free bytes available for saving.

Similarly, like the HTML, CSS and JavaScript comment code that w3compiler removes, it can also remove inconsequential META tag information. Aside from the once widely used META "keywords" tag, most META tag information is just glorified commenting. Information like the META "generated" tag is useless at best and always unnecessarily revealing. Why would you announce to the world that your page was created in FrontPage? With the w3compiler it is easy to configure which META tags you deem necessary to send with each page and to strip out all others.

Remap built-in JavaScript Objects
JavaScript object names are ofter unnecessarily long in a set of deployment Web pages. By design, these names are descriptive. This is what helps to make JavaScript an easy language to read and write. However, there is no need for a browser to receive multiple calls to a long object name. If the object name appears with any frequency, the smart thing to do is to store a reference to the object in a tersely named variable.

For example, if you call the document object more than once, it can be beneficial to store the object name in a single letter designated variable name. In our example the document object gets stored in a variable named m. This makes any reference to the document object significantly shorter.

original file


optimized file with remapped objects


This is a technique that, when done correctly, can add up to significant savings, especially in external JavaScript files. To do it correctly, however, a site-wide view of the entire Web site must be maintained to insure consistency throughout your inline JavaScript and your external JavaScript files. The w3compiler that was used in this example not only manages the remapping but it keeps a log of all remapped JavaScript objects, making this practice easy and safe across an entire Web site.


Minimize Long Function and Variable Names
As references to the built-in JavaScript Object references can be remapped, it only makes sense to do something similar for user defined variables and function names. Just like the built-in object names, JavaScript function and variable names are oftentimes descriptive to make them easier to read and code. It also makes them unnecessarily long. Since the browser does not care whether your variable is named gn_ChannelMenu or hj, converting those long names to single or double letter designations for deployment can add up to substantial savings.

The developers of our example page use a JavaScript function named h_writeHighlights(). Optimizing this page with the w3compiler results in a deployment page where this function and all calls to it become ht().


original file


optimized file with renamed functions and variables


The same caveat that applies to the JavaScript Object Remapping applies for function and variable renaming. To do this safely, a comprehensive, site-wide map of variable names must be maintained. Doing this manually would require a painstaking process that would make optimizing your Web pages more prohibitive as your Web site grew in complexity--and complex sites are the ones that gain to benefit the most. The w3compiler makes this easy by tracking all instances of functions and their calls across a Web site.

Condense JavaScript
Additional savings can also be realized through some good old-fashioned code condensing. As anyone familiar with C++ compilers knows, the code you write always gets "optimized" in your compiler. This means that writing something like x=x+1 is perfectly acceptable, but the compiler is going to change it to x++. This is because both lines accomplish the same thing; one just uses a couple fewer characters.

In the embedded JavaScript on this page, for example, the var declarations are unnecessary. Since these declarations are outside of the function itself, they can be replaced with assignments alone. (The function names were shortened in the step above.)

original file


optimized file with JavaScript condensing


Remap File Names
Since the w3compiler maintains a site-wide view of your application, this allows the tool to take full advantage of remapping image, script and formatting files for you deployment site too. Just like a browser doesn't care whether your source code has white space or whether you choose a long descriptive name for your JavaScript variable, it doesn't care what the paths to your page images and external script files look like either.

When developing a Web page, you would likely create an image link as follows:

<img src="/sites/nav/pix/solutions_off.gif">

You use a directory located at /sites/nav/pix/ to store your image named solutions_off.gif because it makes your life easier. However, the browser likes the following path just the same:

<img src="/0/d.gif">

With the w3compiler's site-wide view of your Web site, you can use paths and file names like this without the administrative headache of trying to maintain them in your development environment. w3compiler creates the directories, changes the file names and optimizes the image paths for deployment. It maintains strict control over the image renaming and path remapping, while the files you edit and the site structure in your development environment remain the same.

original file


optimized file with file name and path remapping


If this seems like a long way to go for a little bit of savings, consider how many images some Web pages reference and how long those path names are. This is an area of Web page optimization that is rarely explored. Mostly because of the administrative nightmare of trying to maintain a set of editable development files and a deployment set of files. With a tool like w3compiler to do this for you, you are free to gear your development set of files towards editing -- then let w3compiler aggressively perform these optimizations on your deployment files.

These are some examples of the types of savings that can be achieved on an example of a page on a real-world Web site. With the right Web site optimization tool, your Web pages can easily and safely have all of these applied. These are some of the optimizations that the smartest applications on the Web are already using. Now, with the right tools, you can too.