On The Perception Of Being Fast

A humbling understanding of a user and their experience of a web page

Ian Thompson
Jun 9 · 6 min read
Auditorio de Tenerife
Photo by Claudia Lorusso on Unsplash

As performance enthusiastic (!) software engineers, we put a considerable amount of time into measuring the performance of our systems. Sometimes to prove we are doing-the-right-thing™, other times to discover we have not done the right thing.

Many times, however, we lose sight of the purpose of our creation when we focus on measurement.

In our world — software engineering — we are in the business of creating applications that help a user do “something” useful and — desirably — for “it” to be a pleasant experience in a “simply-functional” way.

For all our efforts measuring performance and thus optimising performance, does this translate to the experience a user “feels”?

Web Page Performance Measurement — Limitations

The time and effort we put into making a performance metric — like initial page load or resource HTTP request latency — number “x times smaller” generally is wasted time when focusing on front-end applications.

Not to say the time and effort should be zero but we might spend our time better focusing on other characteristics of the user experience at the front-end.

Let’s look at the traditional way in which we understand front-end — web-page — performance.

To simplify this a little we will look at page loading of static web pages rather than single page applications (SPAs). However, both SPAs and static web page performance measurement uses the same vernacular as described in this article. Thus, both are subject to the same limitations and usage.

SPAs are a little more complicated in that capturing “page load” of each subsequent page (post initial page load) must be applied to each as a “synthetic” navigation — through the browser history API; all happening within the — initial — single page. Basically, no re-load of the web page.

Whereas, in statically loaded web pages, each web page load is a request made by the web browser for resources relating to a URI change (with caching involved of course). Basically, a re-load of each subsequent page.

Anyone pondering the ramifications of these two propositions — static vs. synthetic — of loading resources would think that an SPA is far more performant; each page load does not trigger the browser to fetch resources but there are subtleties at play which mean less fetching does not equal overall performance improvement.

Something to ponder further for another day.

I digress…

Resource and navigation timing metrics measure the time a web browser takes to fully load a web page. This includes the time spent fetching (I/O-bound tasks) resources — like images, text, css, javascript — from a back-end and the time it takes the web browser to parse and render (CPU-bound tasks) those resources which, overall, represent a web page to a user.

We could go deeper into how much — it’s a lot! — I/O and CPU bound tasks play into overall web page performance and the performance of a web browser but, for now, we’ll keep this light.

These (resource and navigation) timing metrics are well-defined and perform their task fittingly; informing us of the time taken by a web browser to load and render resources required by a web page. These metrics can be said to describe what is happening within the browser context.

It’s a little bit more complicated however when we start to think about how a web page is presented what the user “sees” and that which can be interacted with — and the order in which elements of a web page are rendered to the point of being “useful”.

That last point — at which a web page can be described as “being useful”— is a hint towards the real crux of the limitation of performance timing metrics; what the user experiences is in our context (under our control) and not in the browser context. More later…

Again, performance timing metrics measure a small detail of the overall performance of a web page within the browser context. Relying on them to convey the reality of what the user experiences is naive.

Web Page Performance Scoring — The Case Against

In all reality, a user does not care about a measure of performance until it is so bad it is noticeable.

A user — predominately — cares about the look and feel and response time of useable elements, and ease-of-use of a web page. Performance merely plays a supporting role in determining any one of those factors.

In short, focus on the user experience and move away from the assumption that optimising by resource and navigation timing metrics is the only route to performant web pages.

We should care deeply about our web pages — our “product” — and the quality of the experience to a user when using them.

Google knows this and is slowly moving away from resource timing and heading towards a user-centric view of web page performance.

In Google own words (on the issues inherent in accurate performance measurement):

“When your Performance score fluctuates it’s usually because of changes in underlying conditions. Common problems include:

- A/B tests

- Internet traffic routing changes

- Testing on different devices, such as a high-performance desktop and a low-performance laptop

- Browser extensions that inject JavaScript into all pages you visit and make network requests

Furthermore, even though tooling can provide you a single overall Performance score, it might be more useful to think of your site performance as a distribution of scores, rather than a single number.”

Admittedly, this is from the perspective of synthetic test data and testing. However, it underlines a move the industry as a whole is beginning to realise; think from the top-down, through the usefulness of the experience.

A hardened software performance engineer might ask (when attempting to gauge and measure the user experience) : “How can we make the user experience better, can we improve the user experience through performance?

In answering that question we must ask ourselves how our performance is shaping the experience.

Psychology of Fast — A Brief Interlude

This is perhaps a moment to change our perspective and delve deeper into what an experience of fast is anyway…

Return Trip Effect (RTE) is quite an interesting phenomena. Most of us, I imagine, have experienced it at one point or another in our lives.

The anticipation of an experience can shape the perception we have of time itself. If a user is browsing the internet and has landed on our web page, the perception of being fast (our page) is directly effected by (in comparison to) the web page(s) the user has landed on and left previously.

On top of that — and this is the interesting aspect — if we are pronouncing the expectation of a great experience (expected by the user), when using our web page, then the anticipation of that — experience — will actually cause the perception of time to increase in the mind of the user.

That last point is immensely interesting and sobering; the more our web page is anticipated — generally a good thing (!)— the more it would seem, to the user, that time itself is taking longer when initiating an interaction with our web page.

Ultimately, the key point here is managing expectations our users have when thinking about the experience we are offering.

This is an interesting aspect which is an article in of itself as this has ramifications on how and where we begin to optimise our web pages.

Maximise The User Experience

There are many facets to how to become optimal and maximise the user experience, it’s a focused operation an entire organisation has to become involved in to get the best results. There must be a top-down approach through all aspects of an organisation to plan and tackle an optimisation task which is focused squarely on the user.

So as software engineers, how might we focus our efforts to maximise the user experience, how can we play our part?

Again, focus on the user journey and move away from the view that optimising resource and navigation timing metrics is the sole method to achieve performant web pages.

To put it simply:

  • identify the critical rendering path, and prioritise the render of the most important page elements
  • reduce the size and number of JavaScript being sent to the web browser

One might call this pre-emptive step: “getting our house in order”.

Once we have trimmed the fat and reduced parsing and rendering multiple/sizeable chunks of data, we can then concentrate on our offering to a user from the user perspective and maximise the user experience.

Geek Culture

Proud to geek out. Follow to join our +1M monthly readers.