Everything about Web and Network Monitoring

Perception is king, when it comes to website performance

1clockThis article provides performance tips that improve perceived time more than actual time. Two or three are founded on the principle of setting appropriate expectations.Measuring the time that passes while the system performs some task gives us a good indication of performance, but there’s more to the story. There are four types of time we need to consider.
Actual time is what the clock says. That’s the time we usually measure and monitor.
Expected time is the user’s expectation. It’s how much time he thinks the task will take before he actually does it.
Perceived time is how long the user thinks the task took after it completes. It is usually greater than actual time.
Remembered time is what the user remembers when he’s talking to his buddies later. It often exceeds perceived time just like the fish keeps growing every time the fisherman tells the tale.
Service time is the inverse of what I call the thrill factor. It measures how much we have disappointed the user. [If negative, it measures how much we have thrilled the user, hence the term “thrill factor.”] The bigger the magnitude of this number, the more the thrill or disappointment. This is an important statistic for us, but it is hard to measure because perceived time and expected time are hard to measure.Most performance tips deal with actual time, but the above definitions show us two other areas for improvement. Since the user’s satisfaction is based on service time, we can improve it by:

  1. reducing perceived time, or
  2. increasing expected time.

Long Tasks

No matter how hard we try to deliver lightning-fast performance, there will always be those tasks that take too long. We may have run out of ways to further reduce actual time, but there are still ways to reduce perceived time.


The best way to handle this situation is to spin the task off into the background. This lets the user get on with what he’s doing almost immediately, before the task completes. Of course, the user will want to know when the task is finished, so we must provide some kind of notification system – perhaps an e-mail, perhaps a progress indicator on every page he visits, perhaps a web page that shows the status of all his background processes.


If creating a background task won’t work for one reason or another, we’ll have to perform the task while the user is waiting. Let the user know in advance what the system is going to do and how long it will take. This not only gives him a good reason for waiting, but it also sets his expectations to an appropriate level.


Do not say things like “please wait” or “stand by” because that draws attention to the fact that there is a delay. Simply state what is happening (e.g., “saving your work”).


Give the user a reasonably accurate prediction of how long the task will take. He has other things he can do, some taking a few seconds (e.g., check e-mail) and some taking a few minutes (e.g., grab a coffee). If he knows how long the system will take, he can select an appropriate alternate task to fill the gap. Occupied time (time that is filled with an activity) is perceived to be shorter than unoccupied time (time spent drumming one’s fingers or staring at an hourglass).


Inaccurate estimates disappoint the user. If the estimate is too short, he finds the system still occupied when he returns. If the estimate is too long, he returns late and loses the opportunity to get on with what he’s really trying to accomplish.


A progress indicator gives the user assurance and control. As he sees it move, he is assured that his task is progressing. Like the up-front time estimate, he can control how he uses the remaining time. As he finishes each alternate task, he can check the progress indicator to see if there is enough time left for yet another alternate task.


Providing an option to cancel is also helpful. If the user changes his mind and decides that it is not worth waiting, he can cancel the task and get on with other things instead of waiting for it to complete.

Perceived time is longer when the user sees no progress toward his end goal.


Progressive Rendering

For a short time after requesting a new web page, a user can see the previous page, an empty white screen, or parts of the new page as they become available. Which is perceived to be fastest? Which is perceived to be slowest?


The current consensus is that the “white screen of death,” so called because this is where some web pages hang, is perceived to be the slowest, and watching the new page load is perceived to be the fastest. The user needs reassurance that something is happening or he gets antsy and starts clicking on the refresh button, which starts the whole slow process all over again.


Users need to see something in the blink of an eye. This assures them that the request is being processed. They need to see something that appears to be a fully loaded web page shortly after that. This lets them know that they can get on with what they want to do. They need to have the functionality they’re looking for available to them a little bit later, just in time when they start typing or clicking. They don’t really care when the rest of the stuff loads as long as it doesn’t interfere with what they’re trying to do.


Web pages should download and render the immediately visible components first. This doesn’t include anything “below the fold” or in drop-down lists or other containers. Once the immediately visible components are in place and onLoad has fired, then download and render the components the user is expected to use first. Create web pages in this order:

  1. what the user will see first
  2. onLoad should fire here
  3. what the user will use first
  4. what the user may use later
  5. everything else on the current page
  6. components on the next page the user will probably visit

Keep in mind that external style sheets block rendering. Since we want that first graphic visible in the blink of an eye, use inline style sheets only and keep them simple. Style sheets should be defined in the <head> section.


Minimize Clutter

Too much information all at the same time is perceived to be slower, perhaps because it must be skimmed in its entirety before the user can decide what to do next. If too much of that information is irrelevant to his immediate task, he will blame the website for wasting his time.


Unnecessary sounds, disorderly arrangement of elements, decorations, too many options, and too many visuals all contribute to clutter. Animation is the worst offender because it constantly draws the user’s eyes away from what they’re supposed to be doing.


Icons are small, widely-understood visual representations of an underlying concept. If they are not widely understood, they are not icons; they are merely clutter. There is a tendency to create visual representations for every little thing on the web page. While repeat visitors will eventually learn some, perhaps most, of the meanings, newbies will feel lost and will perceive the page to be slower than it really is.


Keeping the user “in the flow,” also called “in the zone” or “in the groove,” increases satisfaction. Anything that distracts him from his flow reduces satisfaction. Cluttering the screen is one sure way of interrupting flow.


Tell Them What You’re Doing & Tell Them What You’ve Done

Tell users what you are going to do, then do it, then tell them what you’ve done. When you tell them what you’ve done, make sure to mention what benefit it gives them. Example: (1) “I will file your application now.” (2) File the application. (3) “Your application has been filed. You are now eligible for the scholarship competition.”

If the user waited more than a few seconds, draw attention to what he has accomplished rather than the fact that he had to wait. Example: Don’t say, “We apologize for the delay.” Instead say, “We made sure you are getting the lowest price possible.”


Make It Fun

Perceived time is longer when the task is unpleasant or boring. Use humour, but avoid what your audience thinks is politically incorrect. Also consider your audience when deciding how much humour to use. Personally, I’d like to see a streetsweeper come out and sweep away the old page while I’m waiting for the new one to load. Other audiences may have a different idea of fun. Know your audience!


Get to End-of-Job

Perceived time is longer when the task is unsuccessful, so make sure the user accomplishes what he set out to do. System failures, 404’s, out-of-stock items, and finding out at the last minute that the system doesn’t do what you want it to do all frustrate, even infuriate, users. Make sure the users are able to get to end-of-job every time.



Being fast is good, but there is one drawback. If most of the web pages are fast, they set high expectations that are not met by the slower pages. In effect, the ultra-fast pages draw the user’s attention to the slowness of the other pages.

The first step, of course, is to speed up those slow pages. Once that is done, though, slowing down the sub-second pages may be an option, too. I know of no research dealing with this, so please consider it a thought rather than a recommendation.


Optimize the Empty Cache Experience

Most developers have discovered that caching makes a huge difference for website performance. However, don’t stop there. Caching does nothing to help first-time visitors because their caches aren’t primed yet. If you want your first-time visitors to become second-time visitors, make sure they, too, get a good user experience.

Add to this the psychological factor that unfamiliar tasks seem slower than familiar tasks. The first-time visitor is not familiar with the website, so we’ve got one strike against us before we even get started. Ignoring the first-time visitor’s experience puts a damper on the website’s growth.


Advertising Load Times

Some people have taken to putting the load time on every page. It helps ensure that perceived time and remembered time don’t become inflated.

If you do this, only do it for the fast pages. You don’t want to advertise load time on slow pages.



User satisfaction can be improved by reducing perceived time or by lowering the user’s expectations (i.e., raising expected time). The former is more important than the latter because if we set expectations too low, the user won’t even try our website. They’ll go to another website where the expected time is shorter.


Modifying perceived time is possible with the tips presented above. Remember:

  • Occupied time is perceived to be faster than unoccupied time.
  • Pleasant tasks are perceived to be faster than unpleasant tasks.
  • Seeing progress toward one’s end goal is perceived to be faster than merely waiting.
  • Wait time is perceived to be faster when one knows what is happening and why.
  • Familiar tasks are perceived to be faster than unfamiliar tasks.
  • Don’t point out delays; point out benefits.
  • Uncluttered pages are perceived to be faster than cluttered pages.
  • Render first what the user sees first. Then render what he wants to use. Then comes everything else.

And a gem to embroider onto your sampler: Never promise what you can’t deliver. …Never!

Improve your website performance by staying on top of issues 24/7. Sign-up for Monitor.Us for FREE now!

Post Tagged with

About Warren Gaebel

Warren wrote his first computer program in 1970 (yes, it was Fortran).  He earned his Bachelor of Arts degree from the University of Waterloo and his Bachelor of Computer Science degree at the University of Windsor.  After a few years at IBM, he worked on a Master of Mathematics (Computer Science) degree at the University of Waterloo.  He decided to stay home to take care of his newborn son rather than complete that degree.  That decision cost him his career, but he would gladly make the same decision again. Warren is now retired, but he finds it hard to do nothing, so he writes web performance articles for the Monitor.Us blog.  Life is good!