3 UX Tips To Make Your Site Feel Faster
Waiting feels long. Waiting for 1 minute for a web page to load feels a lot longer than a 1-minute snooze after your alarm clock has gone off.
Speed and performance are essential parts of the user experience of a digital product. If users perceive a site to be slow or to run sluggishly, they have a negative experience. Even a small delay in page load can result in a loss of conversions, higher abandonment rates and a negative perception of the site. Speed matters.
The problem
Here at seek.com.au, we were trying to improve the speed of SEEK Talent Search, which is a product that allows hirers to search across our database of over 4.5 million profiles to find and connect with candidates and offer them potential employment opportunities. This search product is continually growing in size and complexity, with features like resume parsing and profile enrichment, and a database growing to the tune of 160,000 new profiles every month.
This growth however, came at a price. Things were becoming slow. We began hearing complaints about site speed from our users. They weren’t happy. We were hearing their frustrations from our customer service teams, our sales teams, through user research and from internal users of the site.
Their pain ranged from ‘this feels a bit slow, has my search worked? Is this still loading?’ to the more extreme ‘is anything ever going to happen? Will this spinner of death ever end?!’
The approach
Our goal was to improve both the actual and perceived speed of the site. While our search engineers worked in the background to improve the actual speed by optimising servers and reducing API query speeds, our UX designers and UI developers tackled the perceived speed on the front end. We wanted to ensure that we improved our users’ perception of the performance, because that’s who we’re building for.
We needed to make the site ‘feel’ faster. We approached improving the perceived performance of the site through UX in 3 different ways, keeping in mind the long-standing HCI research on response time limits from Jakob Nielsen, which are determined by human perceptual abilities.
1. Staggered loading
Instead of displaying a loading spinner until all elements of the page had loaded (which was taking up to 5 seconds), we implemented staggered loading of content on site load. This meant we progressively displayed visual elements of the site sooner for users to focus on while loading was processing in the background — the blurb on what you could do on this page, and the search boxes you could use to do so. This provided distraction and prompted them with a task to cognitively prepare for, so loading didn’t feel so long to them.
Speed Index (the average time at which visible parts of the page are displayed in the browser window) is the universally accepted measure of site performance. Under 1 second is the aim, 2 seconds is the point at which user experience is negatively impacted, as users’ attention starts to wander and the perception of dealing with the current task is broken.
By reducing the time taken to provide meaningful visual content to users from 5 to 0.5 seconds, we improved the perceived performance of our site.
2. Loading dummy content
As users interact with a site, they expect immediate responses to their actions. Clicking a button or running a search should have an immediate response.
“0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.” Jakob Nielsen
When a user runs a search on our site, ideally we should show the search results immediately. However, if it’s going to take some time to retrieve these results, we need to give the user immediate feedback that their search has worked, and is progressing. Otherwise, if there is no immediate response, we effectively ‘leave them hanging,’ wondering if the click worked, if the action is happening at all, or if they need to click again.
As retrieving matching profiles for a search in Talent Search can take over a second, we instantly display placeholder dummy content to the user while waiting for the real profile content to load. This sets user expectation of where the content will appear, and distracts them with something else to look at (more of that cognitive distraction). Animating this content also provided reassuring feedback to users indicating that content is continuing to load in the background.
By providing this visual response that the search has worked in under 0.1 seconds, we improved another aspect of the site’s perceived performance for our users.
3. Asynchronous and optimistic actions
When a user clicks on a button to complete an action, we can generally understand their intent. They want this action to happen!
As often happens on complex sites, all sorts of technical tasks must be completed in the background in order for this task to be completed, which can cause delays. However, the user does not need to know, or care about this. They just want it to work. This is a system issue, not a user issue, so we shouldn’t push the problem back onto the user.
Instead of waiting for all tasks to complete before we responded to the user, we redesigned the interaction to give the user immediate positive feedback in the UI that their action has worked. So before we even know if the action has worked, we tell the user that it has. For example, when a user shortlists a candidate profile in Talent Search, rather than waiting for the supporting background tasks to complete, we immediately light up the star icon in the UI, indicating the profile has successfully been shortlisted. Then we keep trying to do it in the background until it really has worked. This is an asynchronous and optimistic action, that assumes a positive outcome.
In rare cases, the action cannot be completed even after we try numerous times to fix it. In this case, we display an error to the user that their action has not been completed. However, this edge case should not hinder the experience for the majority of users whose actions are completed successfully.
By giving immediate responses to our users’ actions, rather than forcing them to wait for all background tasks to complete, we further improved the perceived performance of Talent Search.
Future performance
Following our performance improvements in Talent Search, we have now set a performance baseline and can monitor this carefully to ensure that new features, filters and profiles do not negatively affect this level.
Visualising our progress as a team is also key to keeping a user-centred approach to site performance. We are using WebPageTest to display the daily performance metrics to the team. This visibility creates greater awareness and a shared responsibility amongst the team around performance improvements. Moving forward, we have a shared understanding that collaboration between designers and developers is essential throughout the design process to identify any future potential performance concerns in proposed concepts and wireframes.
Conclusion
Users don’t like waiting. By making some changes to how your site loads, responds and handles actions, you can help make users perceive that loading times are shorter than they really are, leading them to have a more positive experience on your site.
