Designing faster web apps
Modern mobile and desktop users expect their sites to load and run like lightning. Therefore, a good UI or UX designer needs to have a complete understanding of the range of options available to improve the speed of your site and consequently the enjoyment your users get out of using it.
How important is speed?
Any user who has access to high speed internet connections on either desktop or mobile will expect their actions on your website to be completed within milliseconds.
- Google compared loading fewer results on a page in 0.4 seconds to more results in 0.9 seconds. Traffic and ad revenue decreased by 20%.
- Yahoo found that between 5% and 9% of its users would abandon a page if it took 400ms longer to load.
- Microsoft Bing reported a 4.3% drop in revenue when their tests delayed the delivery of a search results page by 2 seconds.
- Mozilla got 60 million more Firefox downloads per year by making their pages 2.2 seconds faster.
So there is no question - improvements in speed not only have a significant effect on the level of your user’s engagement, but any slowdown has a direct and measurable impact on your company’s bottom line.
What do users expect?
Understanding a user’s expectations is also a hugely important part of delivering a service they deem to be fast.
- 57 percent of mobile users will abandon your website if it takes more than 3 seconds to load.
- 70% of tablet users expect a website to load in under 2 seconds.
- 71% of users expect your site to load as quickly on their mobile as it does when they are at home. (Compuware)
- If your software takes longer than 100ms to respond, it can feel sluggish and slow. (Luke Wroblewski)
It's not just speed
While speed is hugely important, your users aren't only concerned with speed in and of itself. Their expectations and prior experiences also play a huge role. Put simply, if a user expects something to take a longer period of time, they will be more patient about waiting for it. We can use a number of approaches to manage user expectations and hide latency issues while making them believe that the experience is moving faster than it actually is.
Using actual speed improvements and immediately communicating with a user about their actions has the best result when looking to improve a customer's perception of whether your site is fast or slow.
Show me the solutions
There are 6 areas you need to have a basic understanding of to improve the likelihood your users will deem your app or website to be 'fast'. The first parts are technical - to make your web app faster by knowing what your server does and how websites load. The second part consists of cosmetic and UI tricks - making it appear faster than it actually is.
Let’s start with making your site faster.
1. Check your server
Use tools like website speed test to give yourself an initial overview of how fast your website is performing.
- Be familiar with CDNs and how they can deliver files from a location on the internet close to your users, speeding up the time it takes to get all the relevant files.
Make sure your site does not have any unnecessary redirects, as this can cause a delay of 200-300ms or more.
Make sure cache headers are set properly to ensure files are not re-downloaded when your user returns to your site.
- Make sure your server isn't overloaded and has good uptime.
2. Check file sizes and optimise file count
Make sure every file that your website needs is well optimised and that no unnecessary files are downloaded.
A webpage typically consists of one HTML file, one or more JS and CSS files, a number of images and possibly some custom fonts (which are often quite large).
Minimise download queuing
Stop your files being delayed by queuing them up before downloading. Most modern browsers allow 6-8 concurrent file downloads. If you want to download more than a certain number of files from a given website domain (e.g. www.fluidui.com), some will be queued until others complete. The exact number of parallel downloads you can make of this type depends on the browser:
Use multiple domains if necessary, to increase the amount of parallel downloads you can make (this can have other speed benefits too).
3. Check download order and reduce reflows
Your webpage loads as follows:
Your website will begin to draw itself as soon as it has enough content downloaded to flow out the page. Files that arrive later (such as additional CSS files or images) may cause the browser to do a reflow, updating part or all of the screen and often causing an undesirable jump (particularly if your user has scrolled down the page a bit).
Get the HTML and the CSS files to the user as a first priority as these define the look and the feel of the site and let it draw.
It may be worth having some inline JS or CSS to start files downloading in the HTML. That way they can load concurrently with the CSS file and don't need to wait until the CSS file is downloaded and parsed before being added to the queue.
Tell the browser how big an image is going to be on screen to eliminate the visible 'popping' reflow when an image of an unknown size finishes loading.
4. Respond to user actions immediately
At this stage, your site is downloading as fast as it can and Google should be giving you a really good PageSpeed score. Getting your web app to your user is only a small part of the overall problem however.
It's time to focus on making sure the quality of the in-app experience is deemed super fast and won't frustrate your users.
The first priority when responding to a user's action is to communicate with the user that their action has been triggered. The second priority is to actually perform the user's requested activity.
There are 7 stages to handling a user's input:
Optimistic actions occur when the UI acts as if the action has succeeded, even if it is yet to be confirmed by the server.
Performing actions optimistically allows your user to continue working in your web app without being interrupted by latency and is hugely useful when delivering real time and low risk of failure actions.
For example, neither Instagram nor Facebook wait for the server to confirm a 'Like' action before updating your UI. Instead they assume it will be successful and immediately apply it on your device. Separately, they attempt to communicate with the server to confirm the action, after which time it is finalised and distributed to other users. This allows you to continue liking and scrolling, without interrupting your flow by forcing you to wait till the action you have performed has been confirmed by the server.
Checking your loading flow
5. Show constant progress to your users
Sometimes, information needs to be sent to the server and a response dealt with before the user can continue on. This is common in forms, or when loading new pages or content that has not yet been stored locally. There are a number of tricks available here, to both set the user's expectations and make the UI look like it's busy making things happen. How we handle this can dramatically impact a user's perception of speed, regardless of how long it takes.
Prompting the user to wait for their action to complete while giving a constant visual sense of progress will improve the perception of speed in your product.
These techniques will improve how responsive the user reports your website to be.
Progress bars and animations
Use loading animation bars and spinners to inform the user that processing is happening.
Under-promise and over-deliver on loading times. Make the loading bar load slower at the start and faster at the end. Under no circumstances allow it to stop or delay, particularly towards the last 10%.
Backward moving progress bars and pulsing bars are shown to give a user a faster sense of progress.
If loading happens in a short period of time (under 300ms), consider just relying on animations and no progress indicator. Showing a loading screen for a brief period, followed by the content, can actually result in users thinking the loading process is slower than they would have thought without the loading animation.
Use placeholder UI
Dummy placeholder content can be used to give a sense of progress while the real content is loading that mimics the look, feel and shape of the content that will be loaded into the area.
Use animations to hide latency
Finally, start showing page transitions immediately after the user action has commenced. There is no need for content to be returned to the server before starting to show a page. A slide in followed by a content fade in for example can create up to 200-300ms of an animation, giving you plenty of time to process a user's request and display it.
6. Preload future pages for your users
Just because a user is now enjoying your content doesn't mean you need to be idle. You can be busy loading the next screen while your user is browsing the content they have just loaded.
In most cases, when a user is on a page, we know what they are going to do next to a very strong degree of certainty.
For example, when a user visits FluidUI.com, we know that roughly 55% of people click on the 'try now' button, 15% of people go to demos and 10% of people go to the features page as their next action. We can start preloading the contents of the most likely next pages while the user is still exploring the current page. For 80% of users, this would mean that the next page they visit will already be loaded before they click on the link. From the user's perspective, the page loads instantly.
You can use the Google Analytics behaviour flow to show where your users enter your site, and what their likely next steps are on each part of your site.
One final tip
Improving performance on a site can take a lot of time and effort and it is critical to focus your efforts on the right problems first.
Your users could be complaining about load time, about in-app responsiveness or because the site is displaying a huge amount of data or has some extremely complicated rendering. They lump all these performance issues into one single user complaint - "your web app is too slow".
In order to fix the right problem, you must first identify which area of performance is the one users are most unhappy with. That means getting out and hearing from those users, then feeding that information back into your development pipeline and resolving those issues for your users. That's the fastest and most important tip to make your web app faster.