The development team behind the new eBuddy web messenger has been working for some time now to make this client our future flagship product. While we are working on this client we are usually focused on certain themes or sets of (new) features, like conferencing or the support of a new network. Since it’s a new client, features like this are usually quite visible for you, the end-user and you can follow the progress we are making if you log in regularly. However, this doesn’t mean we spend all our time on the creation and development of these new features. Recently we’ve been focused on improving the performance of our client.

Performance has always been an important theme in software development and in every project it means something different. In our case we decided we wanted to dive into three different areas: the contacts tree, the chat tabs and the chat editor. For each of these areas we wanted to greatly improve the responsiveness so users spend less time waiting and more time chatting.

In this blog post I’ll dive a little deeper in what our approach was for each of the problems to give you a little insight in the work behind what we feel is the best chat client on the web. Please let us know how you feel about our efforts.

Editor

Arguably, the most important area was the chat editor where you can type the messages you send. Since chatting is what this application is all about we felt users should experience as little delay as possible while doing it. Before we started working on the performance of this component we identified two main problems. Firstly, while typing a new message, users could experience delays where the letters were lagging behind, appearing seconds later than they were typed. Secondly, when the new message is ready and the user pressed enter or clicked the send button, it sometimes took more than a second to appear in the message area above the chat.

The solution to the second problem was fairly easy. It was basically just a matter of showing the new message before anything else is done. The first was a harder nut to crack. While a user is typing a new message there’s a constant flow of update messages coming in about, for instance, the status of contacts. These messages are taking up a little time each to be processed in the background which is what causes the delay. In the end we decided to postpone the processing of these messages until the user is finished typing.

Tree

Optimizing the contacts tree came with its own set of challenges. It is certainly the most dynamic part of our chat application, constantly updating the status, display name and personal messages of the contacts. Here we identified the following problem: even though logging in with an average account (about 150 contacts) didn’t take very long, it still took a significant amount of time before we were ready with building the contacts tree and we could show it. This caused a problem with the perception of the performance: users thought logging in took a very long time when in fact it didn’t. We needed to find a way to show the tree sooner.

This was perhaps the hardest to optimize and I have to take off my hat to my fellow-developer Mike for that. Not only did he manage to really speed up the rendering of the tree, he managed to implement new sorting options as well. The tree can now be sorted in three different ways: by groups, by name and by account. For each of these options showing offline contacts is optional.

Tabs

We felt the chat tabs definitely needed some work as well. Once a user had several chats open, switching between them took a noticable time. Additionally, creating a new tab by starting a chat with someone sometimes took more than two seconds. Certainly a lot of room for improvement! To speed all this up we had a hybrid approach of doing things in a different order and optimizing the avatar pictures so we can show the tab contents sooner.

Tools

To be able to improve software performance you have to be able to measure it. Sometimes this means sitting next to your computer with a stopwatch, other times it means adding measurement points to the code and sometimes you rely on third-party tools like Firebug, which can accurately measure and profile code performance on the Firefox browser. It is very unfortunate that such a profiler doesn’t exist for Microsoft’s Internet Explorer, the most popular browser.

To bridge this gap Mike has developed a really interesting bit of JavaScript code that hooks into the client and profiles how often certain bits of code are used and how long that takes. For developers this is hugely interesting information and this tool is amazing enough to deserve its own blog post. Keep posted for this in the future.

Results

Without wanting to pat myself and my co-workers on the back too much, I really feel we’ve made a huge leap forwards in terms of performance and stability. The end result of this development phase is even better than I expected and we all really hope it translates into a better experience for our users. As always, please let us know how you feel about our products. We are continually working to improve them based our own experiences and, much more important, on user feedback.

This entry was posted on Tuesday, November 20th, 2007 at 2:42 pm and is filed under Web Beta, Development, Instant Messaging, Web2.0. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.