Sunday, April 27, 2008

Improving website's responsiveness - some learnings

For the past few days, we have been working on improving the performance of some of the new features in our product/web application. Some of them have really worked for us. Thought of sharing them:
  1. Look for the optimum amount of data to be shown to the user: This is not a technical tip but has to do more with sensitivity to the usage of your site/application. There is a need to get only so much data which the user can see with convenience. For example in our application, we were showing around 25 rows on search results and the vertical scroll bar became pretty big. The side-menu occupied very small part of the browser real-estate. We then changed it to 10 rows and found the page to be more balanced. And that also reduced the amount of data we send across to the browser which increased responsiveness quite a bit. So do look to resize your pages as needed. Don't keep them too big.
  2. Gzipping/Compressing your response: If you are sending a huge amount of data in your response consider gzipping the content. This reduces the time taken to push the content across to the browser and for internet sites this could do a lot of good to the responsiveness. When doing this keep two things in mind. One: You would be able to use this only if the target browser can handle gzipped content (most browsers do that now a days). Two: Gzipping needs horse (read CPU) power and you better have what is required.
  3. Sourcing images/static content using hostname aliases: This is more of working around the limitation of the browser. The browser typically cannot make more than two parallel requests for such components with the same hostname. Hence if you create aliases to your host, that will increase the number of parallel requests the browser can make to get these components. Simple! Not so fast. Keep in mind that, this increases the number of DNS lookups and that adds to the overhead. So strike a balance. We plan to have 4 aliases in our application.
  4. Bundling and Minifying JS and CSS files: You know that for included JS and CSS files, the browser makes separate requests. Again two things here: Bundling these files into one file reduces the number of requests - a good thing. But keep in mind that you should not lose out on the caching of the browser of these files. So if a set of JS (or CSS) files are common to many pages, bundle them separately and include it in your pages instead of putting them into the page specific bundles. The second thing is to minify or compress these files. The reason is same as compressing the response. JSMin is quite famous for JavaScript compression. YUI has a compressor which is based on Rhino and it has support both JS and CSS compression. We are planning to use this as we found better compression with this.
  5. Use latest js libraries: If you are using JavaScript libraries, check out whether you are using the latest version. In most cases the latest version would be more performant (there could be exceptions), so would be good idea to move to the latest version. We are using jQuery and are planning to migrate from 1.2.1 to 1.2.3 version.
  6. Remove unnecessary inline js and css: It is always a good idea to externalize the inline js and css into linked js and css files. The js and css files are cached by the browser. This reduces the amount of markup sent across in the response each time.
  7. Use css instead of images for your page styling (like curves): Earlier whenever we wanted different kinds of styling like curves and dots, we used images. Now these can be done by css and rightly so. Using images for these effects will increase the number of requests for painting the page and hence reduce responsiveness. Many js libraries provide plug-ins for these nowadays.
  8. Using http 'if-modified' in AJAX calls: AJAX is a great technology (that is cliche and probably everybody knows it, but still could not resist it). It has helped all of us to make very responsive applications (ok I am sorry). We can further improve this if we introduce the 'if-modified' http header in these calls. This ensures that if the data is already present in the client side (may be a JavaScript variable), the same is not sent across again unless it has changed. This is just extending the behavior of browsers to images, js files etc to ajax calls. Most JS libraries make this pretty easy.
  9. Optmize JavaScript: In today's web applications, processing using JavaScript is pretty high. This is the same with our application as well. It is a good idea to optimize JavaScript towards this. Using a good js library like jquery solves most of the problems. At the same time, optimization must be kept in mind for other javascript code in our application. And that too across browsers
The above are the techniques we have tried/ are trying in our application. These have helped us in making our application much more responsive. Apart from these techniques, I found the below tools very handy:
  • Firebug: This is one great tool that can be used with Firefox. I can't imagine JavaScript debugging without this. It is very powerful with css and html as well. It is almost a developer's dream come true. It is shame that it does not exist for IE (where it would have been even more useful).
  • Fidder/Charles: Both are http debugging proxies. Allows you to analyze request and responses including time, content.
There are a lot more features in these tools and they are worth investigating.

On the whole, we all wish to make our applications very responsive and with least amount of sweat. And these techniques and tools can surely help us.

No comments: