Performance is an important measurement for every web application out there. Nobody want’s to use an application that is slow to respond or feels sluggish. But what exactly does this mean? In the eyes of the user performance is a tricky thing, and not as easy to measure as one might suspect. In this article I want to introduce some basic concepts on how to make any web application feel faster and more responsive.
Bear in mind that these concept should be used in addition to classic page optimization.
Instant Feedback Is King
This is nearly self explaining but I’ll mention it anyway, you should always give the user instant feedback. At the very least show the user an overlay including the well known loading spinner to indicate that the application is doing something. And of course don’t display the common ‘Loading…’ text but something more meaningful about what the application is currently doing. If the action will be running for more than 2 – 3 seconds it’s also a good idea to include an estimate of the time the user will have to wait. Or, even better, include a status bar for long running actions if possible. BrowserStage here does a pretty good job at telling me exactly what is going on:
Never Make The User Wait
Most users do not like waiting on anything. Even Google includes the users wait time into the ranking of it’s search results. So any web application should try not to make the user wait more than absolutely necessary. Luckily most of the times it’s possible to update the UI even though the server as not performed the actual action. A good example would be deleting items in a list or mark articles as read in a feed reader. Just update the UI and send the command to the server, the user can move on without having to wait until the action is actually completed. Only if there is any problem or error the user should get notified. A great example for this would be Facebook. There you can like things and write comments without ever seeing a loading message. Only the errors are reported back to the user if necessary.
Don’t Ask To Many Questions
Let’s face it: most web applications ask to many questions. In fact this may be true for any software product out there. For example let’s say the user want’s to delete something inside the application. Our first impulse is to a create confirm dialog in which the user needs to click ‘Yes, I really want to delete that‘. The problem with this approach is that is interrupts the users workflow! Sure, if the users has selected this option by accident the confirm dialog will save him but most of the time the users (should) know what he is doing. So instead of displaying a confirm message before the action takes place why not just run with it and show the user an easy way out in case he did do it by accident. GMail does this quite nicely:
Predict The Users Next Action
This last point can be a tricky thing but it can be worth the effort if done right. In many applications the user is following the same workflow over and over again while he or she is using the application. So why not take advantage of this and preload the next step based on this knowledge? Let’s say we have a list of daily reports. We can say that in most cases the user will pick the latest report to inspect. So the application preloads this in the background and if the user does in fact select this entry it is displayed almost instantly.
As you can see it’s not that hard to make a web application feel even faster than it is. Of course sometimes you have long running actions or actions that cannot be undone and you have to implement some methods to protect the user. But especially when it matters most, onboarding new users, the above methods can improve the perceived performance dramatically!
Photo by dodge challenger1