Frontend optimizations
Sunday, June 15th, 2008In Excalibur Phoenix one aspect we are giving major attention to is frontend.
In contrast to Excalibur Reloaded (the previous version) we try not only to provide a user-friendly interface but we also want it to be as fast as possible for the client. The latter is mostly a need that came up as more and more users started using Zino. Furthermore, through the process of optimization we learn new techniques we weren’t keen with, that extend by far our knowledge especially on the way the browsers render a page and the lower level mechanisms that play a major part when there is a greater need for speed (the term is stolen from Google Blog 
). So I want to write a few lines for some optimizations we started implementing in the new version.
1) Lessen HTTP requests
One of the most important aspects is to lessen the HTTP requests that are needed for a page to show properly. Till now, our pages had icons, images, many stylesheets and scripts. Each of those needed a separate HTTP request in order to download since all these files were separated. For example, we used to have the stylesheet for the user profile on a different file from the one for the frontpage. What we do now, is combine all the scripts in one file, all the stylsheets in another and so we use just two separate files for all our styling and javascript. Another thing we did is known with the term “spriting”. We combined all of our background images into one bigger image file. Everytime we need to show an icon, we use this image we created as a source and through the background-position we specify exactly which icon we want to be visible. Those are the most common and effective ways we are currently using in Phoenix
2) Cache content
Another way of reducing HTTP requests and the weight of downloading for the client is to use caching. More specifically caching with far-future headers set. To make things a bit clearer if the browser has cached some of the needed components he has to check whether those are valid according to the Last-Modified header in the response. If the component hasn’t been modified there is no need to download it, so the size of the download decreases. Though a request has been made, that could have been avoided if we used an Expires header. When we set an expires header, we are actually telling the browser to use the components in its cache till a specified date. Until this expiry date the browser uses its cached content without the need to ask for modification of the content. This is more useful with static data such as javascript, stylesheets and icons.
3) Minification
In projects where great amount of javascript is in use, minifying the code makes a lot sense. With the term minification we mean the elimination of spaces, line breaks and comments from the original code. In other words all unnecessary stuff is removed in order to lessen the size of the data the client will download. This technique can also be used for stylesheets but is not so effective. Stylesheets optimization is a bit more complex, as you can get the most of it if you find duplicate rules for elements and remove them. Some developers go a step further with obfuscation but I believe it’s not worth. In obfuscation variable and function names are changed automatically to shorter ones, in order to reduce even more the size. Another reason for using obfuscation is to make the code unreadable to others. Implementing this technique is not as simple as minification and using it should be examined carefully as bugs are likely to appear because of core function name substitution.
4) Gzipping content
One last technique worth mentioning is to use gzip compression. The use of this technique is pretty obvious. Compression reduces download sizes leading to faster downstreaming times for the client. Gzipping is supported by almost all modern browsers so it doesn’t need further browser compatibility thoughts. This technique is more effective when combined with the others described. Minification combined with gzip compression decreases significantly the size of the content. To use it though the web server should be configured properly.
Last but not least few simple things to look after are: avoiding duplicate script inclusion, loading stylesheets at the beginning of the document, scripts at the bottom and sometimes clever content preloading that will be needed later on, while the user is interacting with other parts of the page.
