Menu Search
Jump to the content X X
Smashing Conf San Francisco

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf San Francisco, dedicated to smart front-end techniques and design patterns.

Why Performance Matters, Part 2: Perception Management

Time can be analyzed from two different points: objective and psychological. When we talk about time that can be measured with a stopwatch, we’re talking about objective time, or clock time. Objective time, though, is usually different from how users perceive time while waiting for or interacting with a website or app.

Further readings on Smashing: Link

In part 17, we talked about objective time and some techniques for managing it. We reviewed the ideas behind several widely adopted industry standards, such as page-loading time and system response time. We also got a guideline for setting a performance budget8, and we came to understand how to deal with time when we have to improve the performance of a website9 or match that of a competitor’s10. However, objective time is defined by technical means whereas every such mean has its limits like financial, technical limits or implementation time that become insuperable at some point.

Every technical mean has its limits.11

Every technical solution has its limits. (View large version12)

In addition to technical limits, the absolute values of objective time, even though an indispensable part of what we call “performance,” have one issue: The values do not constitute a “performant” website on their own. To prove the point, below are the absolute time values for a couple of websites. (To keep the intrigue, their names are hidden for now.)

Absolute time values for these two sites don’t impress at all.13
The absolute time values for these two websites aren’t impressive at all. See the results for yourself for the first14 and second website15. (View large version16)

A loading time of 12.436 seconds? Visual completion in 12.2 seconds? The numbers don’t look impressive at all, do they? Considering these numbers alone, we might conclude that the performance of these websites is in desperate need of improvement. But would you believe that these very websites brought almost $89 and $19 billion in revenue in 2014, respectively? How can that be?

Don’t worry. Just type amazon.com or ebay.com in your browser’s address bar (yes, these time values were measured for these very websites) and watch them being rendered much faster than you would have otherwise guessed from looking at the figures above. We will review how to achieve this a bit later.

Performance is not about mathematics17
Performance is not about mathematics. (View large version18)

Performance is never about milliseconds, kilobytes or number of requests; it is not about mathematics. Performance is all about perception and psychology.

In this part, we will get a different perspective on performance:

  • What is psychological time?
  • How do users perceive time?
  • How can we manage and influence this perception?

Psychological Time: Perception Management

Imagination is the only weapon in the war against reality.

— Cheshire Cat in Lewis Carroll’s “Alice’s Adventures in Wonderland”

The way our brain perceives time might be and usually is different from the time that we measure with a stopwatch. The perception and value of time fluctuate according to many factors, including level of anxiety, age, time of day and even cultural background. The time perceived by our brain is called psychological time.

To understand how we perceive time, we need to review some of its essential properties.

In 1927, German philosopher Martin Heidegger19 wrote in his book Being and Time20 that, “Time persists merely as a consequence of the events taking place in [space].” According to Heidegger, time is finite, has a start and end and consists of myriad of events with their own starts and ends, which constitute what we call “time”. Let’s picture a simple event:

Simple event as our brain sees it
Mentally, people differentiate events that have a clear start and end. (View large version21)

We will call the beginning of an event the start event marker or, simply, start marker. The moment when the event is finished will be, accordingly, the end event marker, or end marker.

In addition to the finite nature of time, almost any event can be expressed by two different phases: active and passive. The active phase, or active wait, is characterized by the user’s mental activity. This could be some physical activity or a pure thinking process, like solving a puzzle or finding a way on a map. The period in which the user has no choice or control over the waiting time, such as standing in line or waiting for a loved one who is late for the date, is called a passive phase, or passive wait. People tend to estimate passive waiting as a longer period of time than active, even if the time intervals are objectively equal. A study by Jacob Hornik22, followed by extensive research23 by Richard Larson24, whose nickname at MIT is Dr. Queue, shows that, on average, people in passive wait mode overestimate their waiting time by about 36%.

People in passive and active wait mode perceive the same time interval differently25
People in passive and active wait mode perceive the same time interval differently. (View large version26)

So, the two main principles of time that will guide us further in the article are these:

  • Every event has start and end event markers.
  • Almost every event has active and passive phases.

It will come as no surprise to hear that, in general, we don’t like to wait, except in some edge cases. But when we talk about waiting too long, what we really mean is just the passive phase of the wait; in most cases, the active phase is not considered a wait at all, due to the mental activity exerted. Hence, to manage psychological time and make the brain perceive an event as lasting for less time than it really does, we should reduce the passive phase of the event as much as possible, usually by increasing the active phase of the event. There are multiple techniques to achieve this, but most boil down to two simple practices: preemptive start and early completion. Let’s review both of these.

Preemptive Start

The technique of the preemptive start is the process of opening your event with the active phase and holding it for as long as possible before switching the user to a passive wait. All of this is done without affecting the duration of the original event. As mentioned, most people do not consider the active wait to be waiting at all; hence, to the user’s brain, a preemptive start means virtually shifting the start event marker closer to the end (to when the active phase is over), which will help the user perceive the event as being shorter.

The active phase in the beginning could be of a different nature and can be achieved by some trickery. For now, we will call it magic; your users don’t need to know about. Let’s visualize this process and get to some examples.

In the preemptive start, we begin with the active phase, holding the user in it for as long as possible before switching to the shorter passive phase at the end27
In the preemptive start, we begin with the active phase, holding the user in it for as long as possible before switching to the shorter passive phase at the end. (View large version28)

In 2009, the management team at an airport in Houston, Texas, faced an unusual type of complaint29. Passengers were not satisfied with the long waits to claim their baggage upon arrival. In response, executives at the airport increased the number of baggage handlers. This decreased the waiting time to eight minutes, which is a very good result compared to other airports in the US30. Surprisingly, this did not drop the number of complaints.

The executives researched the problem and figured out that, indeed, the first bags took about eight minutes to show up on the baggage carousel. However, passengers took only one minute to reach the carousel. So, on average, passengers would wait seven minutes before the first bags appeared. Speaking in psychological terms, the active phase was only one minute, while the passive wait was seven minutes.

Using their knowledge of perception management, executives came up with a nontrivial solution. They moved arrival gates further away from the main terminal and routed bags to the furthest carousel. This increased walking time for passengers to six minutes, leaving only two minutes for the passive wait. In spite of the longer walk, complaints dropped to nearly zero.

Airport baggage carousel31
Airport baggage carousel. (View large version32)

Baggage handling at the Houston airport (as pretty much at any airport) can be viewed as an example of the preemptive start technique. From a psychological point of view, starting the handling process as early as possible, while passengers are experiencing the active phase of the wait, “moves” the start event marker for passengers from the real start (when they leave the aircraft and baggage handling begins) to a new point on the timeline. This is what we call the preemptive start: starting work before the user realizes it.

To deal with complaints, the Houston team was left with the only option of increasing the active phase of the wait (making passengers walk for longer), while reducing the passive wait (standing by the carousel). And it worked without changing the objective time of the baggage handling.

To deal with complaints, Houston airport executives increased the active phase of the wait, while decreasing the passive wait33
To deal with complaints, Houston airport executives increased the active phase of the wait, while decreasing the passive wait. (View large version34)

Another example of this technique can be found in mobile Safari on iOS. As you type a URL, the browser suggests pages for you, drawing from pages you have been to or top results from a search engine. There is a special link in that list called “Top Hit.” Not many people realize that, as Safari suggests this top hit, it starts preloading the page in the background, so that it can be delivered as quickly as possible once you select it. You can enable and disable this preloading behavior by going to “Settings” → “Safari” → “Preload Top Hits.”

The same is true when you open a link in a new tab: mobile Safari animates the tab turning as it preloads the page in the background, so that the page can be delivered almost instantly.

Screenshots of mobile Safari in iOS35
Mobile Safari preloads web pages when you search or open a tab. (View large version36)

We can use the same technique on the web — in a search function, for example. Let’s assume that a search field appears on all pages, but the search results page itself requires some heavy duty functionality (sorting, filtering, maybe some additional modules from a server). Instead of loading this functionality for all pages, where it might not be needed, we could load it only for the search results page; however, this might slow down the loading of the results page unnecessarily.

Instead, we could start preloading the required functionality once the user starts typing in the search field; this anticipates that the results will be the next page that the user sees. This way, the functionality will probably be delivered to the browser by the time the user arrives on the search results. You can also use this technique to start prefetching resources on a landing page for the shopping cart page, or in the first checkout step prefetch scripts that will be used in the second checkout step, so the transition between these pages will be almost immediate.

To optimize performance in the browser, a group of industry experts37, led by Google’s web performance engineer Ilya Grigorik38, are working on a W3C specification named “Resource Hints39.” The specification will eventually cover technical solutions for browsers to natively support the preemptive start technique. As Ilya writes40 in his book High-Performance Browser Networking41, we will be able to “embed additional hints into the document itself to tip off the browser about additional optimizations it can perform on our behalf.”

These hints are already supported in some browsers
These hints are already supported in some browsers42.

All of these hints should be placed in the document’s <head> element to enable preloading of resources as soon as possible. Let’s briefly review the hints:

  • dns-prefetch
    This is useful for pre-resolving domain names that are found lower down on the page. It can also be used to pre-resolve domain names behind redirects.
    For example: <link rel="dns-prefetch" href="//name-to-resolve.com">
  • preconnect
    This hint is used not only to pre-resolve a domain name, but to initiate a full connection handshake. The optional crossorigin attribute is used to configure the CORS requests43; check the comment by Ilya Grigorik44 for a better explanation.
    For example: <link rel="preconnect" href="//cdn.example.com" crossorigin>
  • prefetch
    This hint has the lowest priority and is used to prefetch assets or resources required for future navigation. The optional as attribute is used to optimize the fetching process for the specified type of content.
    For example: <link rel="prefetch" href="/library.js" as=”script”>
  • prerender
    This enables background pre-rendering of an entire page, with all of its assets. This might be useful for when a user is navigating a website, to instantly return a page once they need it. However, because yet another page has to be loaded, use it with caution.
    For example: <link rel="prerender" href="//example.com/next-page.html">

For more details and to see the eventual optional arguments for these hints, read the working draft of the specification45. To better understand the thinking behind these hints and for more examples of their usage and support, make sure to check out Ilya Grigorik’s slides “Preconnect, Prefetch, Prerender46” or the article “Prefetching, Preloading, Prebrowsing47” by Robin Rendle48 on CSS-Tricks.

Furthermore, the “Preload49” specification joins the family of resource hints in the W3C “Editor’s Draft.” It defines the preload hint, which is almost the same as the prefetch hint mentioned earlier:

<link rel="preload" href="/styles/other.css" as="style">

However, there is one essential difference between the two: Whereas prefetch has the lowest possible priority and is intended for resources that the user will need as they navigate, preload is meant for critical resources that should be fetched with the highest possible priority. Also, note that preload supersedes the subresource hint50 that you might encounter in other articles.

Returning to the preemptive start technique, we could summarize this as follows: We open the event with the active phase and keep the user in this phase for as long as possible before switching to the boring passive phase of the event.

Early Completion

Similar to how we can move the start marker in the preemptive start technique, early completion moves the end marker closer to the start, giving the user the feeling that the process is ending quickly. In this case, we would open the event with the passive phase but switch the user to the active phase as quickly as we can.

With the early completion technique, we begin with the short passive wait and switch to the active phase early on51
With the early completion technique, we begin with the short passive wait and switch to the active phase early on. (View large version52)

The most familiar use of this technique on the web would be on video-streaming services. When you click the play button on a video, you aren’t waiting for the whole video to download. Playback starts when the first minimally required chunk of video is available. Thus, the end marker is moved closer to the start, and the user is provided with an active wait (watching the downloaded chunk), while the rest of the video downloads in the background. Easy and effective.

Video-streaming services like YouTube are a good example of the early completion technique53
Video-streaming services like YouTube are a good example of the early completion technique. (View large version54)

We can apply the same technique when dealing with page-loading time. In the interval between when a page is requested and gets rendered in the browser, the user is waiting, with no control over the process and no option other than to close the tab. This tells us we are dealing with a passive wait — and people hate the passive wait. So, we should alter it somehow.

One acceptable solution would be to start rendering the page once essential pieces, such as the DOM, are ready to be shown. We don’t need to wait for every asset to download if it won’t affect rendering. We don’t even need all of the HTML elements; we can inject those that are not immediately visible, such as the footer, later with JavaScript. Now we can recall our Amazon and eBay examples. Let’s look at the rendering process of Amazon using a film strip:

Amazon moves the user into an active wait quickly enough55
Amazon moves the user into an active wait quickly enough. (View large version56)

Here, we can see that, in spite of being visually complete in a minimum of 7 seconds, the Amazon page moves the user into an active wait in as soon as 1.1 seconds by starting the rendering process for the top (i.e. visible) part of the website once essential assets for that part have downloaded.

The suggestion to prioritize visible content that we see in Google’s PageSpeed Insights57 and similar optimization tools has to do exactly with this early completion. Give users something as soon as possible; make them think that the page is loading faster than it actually is by splitting the load into a short passive wait at the beginning and then an active wait once the initial information has been loaded and rendered. In anticipation of this, it is very useful to control such parameters as “Start render“ in tools like WebPageTest58, which give an idea of how fast a website is to the user’s perception.

When using the early completion technique, occupy the user with something as soon as possible59
When using the early completion technique, occupy the user with something as soon as possible. This will switch the wait into the active phase. (View large version60)

Perception management that employs active and passive phases is very effective and does not necessarily require expensive or labour-intensive solutions. It works great in most cases using the most powerful tool at our disposal: the human brain.

Conclusion… For Now Link

As web developers, we should aim to deliver fast and reliable web services to make users feel comfortable. We can use technological means to control the objective performance of a website. However, as we’ve seen, the absolute values of time, while an important aspect of performance, are not the only factors in a performant product. The user’s brain decides whether a website is fast enough given current circumstances such as their mood, their line of thought and maybe even the time of day. Technology and resources eventually hit a limit, at which point it becomes difficult to change objective performance. Then, we have to aim to exploit what psychology and neuroscience tell us.

To summarize our discussion in the two articles in this series and to give you some strategies to deliver faster projects, below is a list of the theories and tools at our disposal:

Objective and perception61

From this article:

You could employ some or all of these techniques in your job. Still, the attentive reader might feel that this list is not comprehensive; there are still questions to answer. What do we do when the technical means reach their limit yet the event is a purely passive wait, with no active phase at all? Also, is there such thing as a product that is “too fast”? Ladies and gentlemen, let’s meet in part 3 to find the answers.

(ah, ml, al, jb)

To be continued…69

Footnotes Link

  1. 1 https://www.smashingmagazine.com/2015/09/why-performance-matters-the-perception-of-time
  2. 2 https://www.smashingmagazine.com/2015/12/performance-matters-part-3-tolerance-management/
  3. 3 https://www.smashingmagazine.com/2016/02/getting-ready-for-http2/
  4. 4 https://www.smashingmagazine.com/2016/02/everything-about-google-accelerated-mobile-pages/
  5. 5 https://www.smashingmagazine.com/2015/12/reimagining-single-page-applications-progressive-enhancement/
  6. 6 https://www.smashingmagazine.com/2014/09/improving-smashing-magazine-performance-case-study/
  7. 7 https://www.smashingmagazine.com/2015/09/why-performance-matters-the-perception-of-time
  8. 8 https://www.smashingmagazine.com/2015/09/why-performance-matters-the-perception-of-time/#choosing-a-performance-budget
  9. 9 https://www.smashingmagazine.com/2015/09/why-performance-matters-the-perception-of-time/#the-need-for-performance-optimization-the-20-rule
  10. 10 https://www.smashingmagazine.com/2015/09/why-performance-matters-the-perception-of-time/#neutralization-or-chasing-the-leader
  11. 11 https://www.smashingmagazine.com/wp-content/uploads/2015/10/limits-opt.png
  12. 12 https://www.smashingmagazine.com/wp-content/uploads/2015/10/limits-opt.png
  13. 13 https://www.smashingmagazine.com/wp-content/uploads/2015/10/ebay_amazon_stat-opt.png
  14. 14 http://goo.gl/6M1HjD
  15. 15 http://goo.gl/yvf7sv
  16. 16 https://www.smashingmagazine.com/wp-content/uploads/2015/10/ebay_amazon_stat-opt.png
  17. 17 https://www.smashingmagazine.com/wp-content/uploads/2015/10/performance-perception-opt.png
  18. 18 https://www.smashingmagazine.com/wp-content/uploads/2015/10/performance-perception-opt.png
  19. 19 http://plato.stanford.edu/entries/heidegger/
  20. 20 https://en.wikipedia.org/wiki/Being_and_Time
  21. 21 https://www.smashingmagazine.com/wp-content/uploads/2015/10/event-opt.jpg
  22. 22 http://www.jstor.org/stable/2489149?seq=1#page_scan_tab_contents
  23. 23 http://www.jstor.org/stable/171439?seq=1#page_scan_tab_contents
  24. 24 https://esd.mit.edu/Faculty_Pages/larson/larson.htm
  25. 25 https://www.smashingmagazine.com/wp-content/uploads/2015/10/passive-active-wait-opt.png
  26. 26 https://www.smashingmagazine.com/wp-content/uploads/2015/10/passive-active-wait-opt.png
  27. 27 https://www.smashingmagazine.com/wp-content/uploads/2015/10/preemptive_start-opt.png
  28. 28 https://www.smashingmagazine.com/wp-content/uploads/2015/10/preemptive_start-opt.png
  29. 29 http://www.nytimes.com/2012/08/19/opinion/sunday/why-waiting-in-line-is-torture.html
  30. 30 http://awt.cbp.gov/
  31. 31 https://www.smashingmagazine.com/wp-content/uploads/2015/10/airport-opt.png
  32. 32 https://www.smashingmagazine.com/wp-content/uploads/2015/10/airport-opt.png
  33. 33 https://www.smashingmagazine.com/wp-content/uploads/2015/10/active-passive-phase-opt.png
  34. 34 https://www.smashingmagazine.com/wp-content/uploads/2015/10/active-passive-phase-opt.png
  35. 35 https://www.smashingmagazine.com/wp-content/uploads/2015/10/safari_ios-opt.png
  36. 36 https://www.smashingmagazine.com/wp-content/uploads/2015/10/safari_ios-opt.png
  37. 37 https://github.com/w3c/resource-hints/graphs/contributors
  38. 38 https://www.igvita.com/
  39. 39 http://www.w3.org/TR/resource-hints/
  40. 40 http://chimera.labs.oreilly.com/books/1230000000545/ch10.html#BROWSER_OPTIMIZATION
  41. 41 http://chimera.labs.oreilly.com/books/1230000000545?utm_source=igvita&utm_medium=referral&utm_campaign=igvita-homepage
  42. 42 http://caniuse.com/#search=resource%20hints
  43. 43 https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_settings_attributes
  44. 44 #comment-1284958
  45. 45 http://www.w3.org/TR/resource-hints/
  46. 46 https://goo.gl/HVkbcO
  47. 47 https://css-tricks.com/prefetching-preloading-prebrowsing/
  48. 48 https://twitter.com/robinrendle
  49. 49 https://w3c.github.io/preload/
  50. 50 https://github.com/w3c/preload/issues/23
  51. 51 https://www.smashingmagazine.com/wp-content/uploads/2015/10/early_completion-opt.png
  52. 52 https://www.smashingmagazine.com/wp-content/uploads/2015/10/early_completion-opt.png
  53. 53 https://www.smashingmagazine.com/wp-content/uploads/2015/10/youtube-opt.png
  54. 54 https://www.smashingmagazine.com/wp-content/uploads/2015/10/youtube-opt.png
  55. 55 https://www.smashingmagazine.com/wp-content/uploads/2015/10/amazon_rendering-opt.png
  56. 56 https://www.smashingmagazine.com/wp-content/uploads/2015/10/amazon_rendering-opt.png
  57. 57 https://developers.google.com/speed/pagespeed/insights/
  58. 58 http://www.webpagetest.org/
  59. 59 https://www.smashingmagazine.com/wp-content/uploads/2015/10/early_completion_phase-opt.png
  60. 60 https://www.smashingmagazine.com/wp-content/uploads/2015/10/early_completion_phase-opt.png
  61. 61 https://www.smashingmagazine.com/wp-content/uploads/2015/10/conclusion-opt.png
  62. 62 https://www.smashingmagazine.com/2015/09/why-performance-matters-the-perception-of-time/
  63. 63 https://www.smashingmagazine.com/2015/09/why-performance-matters-the-perception-of-time/#part-1-objective-time
  64. 64 https://www.smashingmagazine.com/2015/09/why-performance-matters-the-perception-of-time/#the-need-for-performance-optimization-the-20-rule
  65. 65 https://www.smashingmagazine.com/2015/09/why-performance-matters-the-perception-of-time/#neutralization-or-chasing-the-leader
  66. 66 #perception-management
  67. 67 #preemptive-start
  68. 68 #early-completion
  69. 69 https://www.smashingmagazine.com/2015/12/performance-matters-part-3-tolerance-management/

↑ Back to top Tweet itShare on Facebook

Advertisement

Denys is a frontend developer living and working in Norway while advocating psychological optimizations around the world. Since the beginning of 00's he has gained experience with a wide range of frontend tasks. Being originally on "CSS side" of development, for the last years Denys has been building javascript applications, continuing breaking CSS, abusing HTML and working with optimization of pretty much all aspects of the frontend at Digital Garden AS (fastname.no and uniweb.no). Passionate about science, history, psychology, in his day-to-day job Denys enjoys getting to the heart of the matter of things and processes. Cycling, photography, impressionist paintings and many more can trigger his attention.

  1. 1

    Back in 1990 I wrote a PC-based app used to enter data from checks and invoice data for a Wholesale lockbox system. Because the app ran on somewhat poor hardware (remember PC’s back then when 286’s were tops) and because it had to establish a connection with a mainframe, the startup time was about 2-3 minutes. People would always moan and some managers would say “Well, this PC stuff is not all that good). So I add a splash screen containing some department news and quotes of the day type stuff. The screen also included a button to [Continue] which actually didn’t do anything.

    The complaints went away! And people loved the info they got to read while the app went through it’s start-up sequence. Those same managers chilled out and, in fact, would offer up ‘content’ for the display scree. We added employee anniversary’s, operational info. etc. I created a small utility for the managers to enter the content so i didn’t have to update it myself every day.

    I didn’t realize I was ahead of my time… :)

    7
    • 2

      Denys Mishunov

      November 6, 2015 7:28 am

      Thank you for the example, Steve. Really a good one. Part 3 is going to elaborate more on the cases like yours exactly.

      1
  2. 3

    Jack Tarantino

    November 5, 2015 5:11 pm

    Related to the bit about prerender tags, I wrote a Rails gem that helps get those on the page in a programmatic way: https://jack.ofspades.com/prefetching-preloading-and-prerendering-content-with-html/ . Hope that helps somebody.

    1
  3. 4

    Great article! One minor correction on ‘crossorigin’ attribute for preconnect… It’s not for indicating that you need a “cross-domain socket”, we already know that by just looking at the provided URL. Rather, its an attribute that controls the CORS policy [1] for that socket.. e.g. font requests are specified to omit cookies and hence you’ll need to specify “crossorigin” on the preconnect to indicate to the client that it should open a socket that will be used to fetch such resources. It’s a bit confusing, I know.

    [1] https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_settings_attributes

    1
    • 5

      Denys Mishunov

      November 7, 2015 10:22 am

      Thank you very much for the comment, Ilya. Tried to make the information a bit easier to understand but, apparently, confused the things on the way :) Nevertheless, I have updated the text to better reflect the purpose of the ‘crossorigin’ attribute. Thanks for the clarification :)

      1
  4. 6

    Jacopo Cappelli

    November 8, 2015 2:53 pm

    Excellent article, certainly the aspect of performance should be put in the foreground along with the design of a website

    2

↑ Back to top