How to create the illusion of faster web pages (while also creating actual happier users)
The internet may change, and web pages may grow and evolve, but user expectations are constant. Throughout several studies, these numbers about response times and human perception have been consistent for more than 45 years:
These numbers are hard-wired. We have zero control over them. They’re consistent regardless of the type of device, application, or connection we’re using at any given moment.
These numbers are why our industry has attached itself to the goal of making pages render in 1 second or less — and to the even more audacious goal that pages render in 100 milliseconds or less.
But when you consider how many things have to happen before anything begins to appear in the browser — from DNS lookup and TCP connection to parsing HTML, downloading stylesheets, and executing JavaScript — 1 second can seem impossible. And forget about 100 milliseconds. In our most recent state of the union for ecommerce performance, we found that start render time for the top 500 retailers was 2.9 seconds. In other words, a typical visitor sits and stares at a blank screen for almost 3 seconds before he or she even begins to see something. Not good.
We can do better.
I talk a lot about page bloat, insidious third-party scripts, the challenges of mobile performance, and all the other things that make hitting these goals seem like an impossible feat. But rather than get discouraged, let me point you toward this great quote from Ilya Grigorik in his book High Performance Browser Networking:
“Time is measured objectively but perceived subjectively, and experiences can be engineered to improve perceived performance.”
Today I’m going to talk about some tricks and techniques you can use to manipulate subjective time to your advantage.
1. Progress indicators
Never underestimate the power of a progress indicator to help improve the user experience on pages that are necessarily slower (e.g. search results page). Progress indicators reassure visitors that the page is actually functional and give a sense of how much longer the visitor will need to wait.
A few tips:
- A progress indicator on a page that loads in less than 5 seconds or less will make that page feel slower than it really is. Jakob Nielsen suggests that percent-done progress bars be reserved for pages/applications that take 10 seconds or longer to load.
- Progress bars that offer the illusion of a left-moving ripple can improve perceived wait time by up to 10%.
- Progress bars that pulse, and that increase pulsation frequency as the bar progresses, are perceived as being faster.
- Similarly, progress bars that speed up are considered more satisfying by users. (Not surprising. This harkens back to the research on colonoscopy pain perception we covered a while back.)
- Use progress indicators sparingly. Too many within a single application can be counter-productive, because it gives users the impression the app is slow overall. Luke Wroblewski shared a good case study about that here.
Here’s a video that shows some of these principles in action:
More good progress bar best practices here.
2. Load something useful first
This principle seems like a no-brainer, but it’s amazing how many times I analyze pages that load primary content last. In our spring performance SOTU, we found that the median Time to Interact (TTI) for the top 100 retailers was 5.4 seconds. This means that it takes 5.4 seconds for a page’s most important content to render. This represents a failure for both the site owner and the site visitor.
A Nielsen-Norman Group eyetracking study found that a user who is served feature content within the first second of page load spent 20% of his or her time within the feature area, whereas a user who is subjected to an eight-second delay of a page’s feature content spent only 1% of his or her time visually engaging with that area of the page.
In other words, rendering your most important content last is a great way to ensure that your visitors get a sub-par user experience.
3. Defer non-essential content
Further to the point above, deferral is an excellent technique for clearing the decks to ensure that your primary content quickly takes center stage. Help your visitors see the page faster by delaying the loading and rendering of any content that is below the initially visible area (sometimes called “below the fold”). Deferring non-essential content won’t change your bottom-line load time, but it can dramatically improve your perceived load time.
Many script libraries aren’t needed until after a page has finished rendering. Downloading and parsing these scripts can safely be deferred until after the onLoad event. For example, scripts that support interactive user behavior, such as “drag and drop,” can’t possibly be called before the user has even seen the page. The same logic applies to script execution. Defer as much as possible until after onload instead of needlessly holding up the initial rendering of the important visible content on the page.
The script to defer could be your own or, often more importantly, scripts from third parties. Poorly optimized scripts for advertisements, social media widgets, or analytics support can block a page from rendering, sometimes adding precious seconds to load times.
4. Progressive image rendering
Progressive image rendering is predicated on the idea that the faster you can get a complete image in the browser, no matter what the resolution, the better the user experience — as opposed to baseline images, which load line by line and take much longer to render a complete image.
Progressive JPEGs aren’t new. They were widely used in the 1990s but fell out of favor due to performance issues caused by slow connection speeds and crudely rendered JPEGs. Back in the day, watching a progressive image load pixel by pixel was a painful experience. Now that connection speeds have improved and progressive JPEGs are more sophisticated, this technique is feasible again and is returning as a performance best practice. Last year, Google engineer Pat Meenan studied the top 2,000 retail sites and found that progressive JPEGs improved median load time by up to 15%.
Despite Pat’s findings, and despite the argument that rendering images progressively should also yield a better perceived UX, progressive JPEGs have an incredibly low adoption rate: around 7-8%. The reason for this could be the dated prejudice I just mentioned, or it could be the fact that Photoshop’s default save option is for baseline images. (If you’re anti-progressive JPEG, I’d love to know why. Please let me know in the comments.)
Note: Kent Alstad and I will be presenting some cool new research about the impact of progressive image rendering on the user experience at Velocity in New York and Barcelona this fall. I hope to see you there!
5. Auto-preloading (AKA predictive browser caching)
Not to be confused with browser preloading, auto-preloading is a powerful performance technique in which all user paths through a website are observed and recorded. Based on this massive amount of aggregated data, the auto-preloading engine can predict where a user is likely to go based on the page they are currently on and the previous pages in their path. The engine loads the resources for those “next” pages in the user’s browser cache, enabling the page to render up to 70% faster.
(Note that this is necessarily a data-intensive, highly dynamic technique that can only be performed by an automated solution. If you’re interested in learning more, read Kent’s excellent post here.)
6. Pretend to work, even when you don’t
Mark Wilson wrote a great post about a handful of tricks Instagram uses to make their pages appear more responsive. My favourite is the one they call “optimistic actions”. To illustrate: even if your connection is down or slow, if you click on the Instagram “like” button but your connection is slow or down, the UI registers the click and highlights the button. It send the actual data back to server whenever the connection is restored. In this way, the site always appears to be working, even when it’s not.
I’m curious to see other applications of this technique in the wild. If anyone can point me toward more examples, please do.
7. Touch event conversion
This tip applies to mobile. If you’re a mobile user, then you’re probably already aware of the delay that occurs between the time you touch your screen and the time it takes for the page to respond. That’s because every time you touch your screen, the device has to translate that touch event into a click event. This translation takes between 300-500 milliseconds per click.
At Radware, we’ve developed a feature called Touch Event Conversion in our FastView solution. It automatically converts click events to touch events, which relieves the mobile browser of the realtime overhead of the click-to-touch translation.
If you want to explore how to do this manually, check out Kyle Peatt’s post on the Mobify blog. He covers some other good mobile performance-enhancing tips there as well.
8. Make perceived value match the wait
If long wait times are necessary, ensure that you’re delivering something with a value that’s commensurate to the wait. A good example of this is travel websites. When you’re searching for the best hotel rates, most of us don’t mind waiting several seconds. We rationalize the wait time because we assume that the engine is searching a massive repository of awesome travel deals in order to give us the very best results.
If you have experience with other perception-enhancing performance practices, I’d love to hear about them. Leave me a note in the comments.
