When I build a website I obsess over performance. I will rip out a JavaScript library from a project and replace it by another to save an extra 10KB. I do this because I understand the impact of performance. Both as a developer who has built a wide variety of sites and as a user who spent last weekend struggling to get one bar of signal at a campsite.

While my experience as a developer means I will go to extraordinary lengths to ensure the websites I build are performant, there is a limited ammount of impact that I can have on my own. I therefore need to look at how I can champion performance with the project’s stakeholders to ensure that everyone is committed to ensuring the website is fast.

Being aware of why performance matters will help your stakeholders get on board and to start with we need to help them understand what it is.

The different kinds of performance

When we start talking about performance with our stakeholders it’s important that they understand specifically what we are talking about. The complication comes because there are three main types of performance and when talking about any one of them it’s important you all are aware which one you are talking about so you don’t get your wires crossed. The three types of performance that I am talking about are:

Render performance

The time it takes for the browser to start rendering the page. From a user’s point of view, until the page starts to render they are stuck staring at a blank white screen. At the point it starts to render they finally get to see some of the content.

Page load performance

Page load performance is the time it takes for the ‘window.onload’ event to trigger. This happens after the HTML, CSS, JavaScript, images and all other resources have been loaded and been rendered. In the past page load performance was the most common metric used to measure the performance of a page however with the change in how we build websites this metric has become less of a focus as it no longer reflects when the page is ready to use by the user.

Perceived performance

Perceived performance sits somewhere in the middle between the two. It refers to how fast a user thinks your website is, not necessarily how fast your technical stats say it is. It is impacted by both how the page is designed and by how it has been built.

A quick comparison of the three

To help demonstrate the three different types of performance I have put together the following video of The Guardian website loading on a slow 3G connection on an iPhone.

What you will notice is that at 4 seconds the page starts to render. This is an important moment as the user now starts to see some content. At 7 seconds we finally can see some imagery, from a user’s perspective the page now feels ready to use and interact with. It actually takes a full 32 seconds for the entire page to finish loading.

Helping your stakeholders to understand further

Of these three, the most important is perceived performance and this is also the easiest for your stakeholders to understand how it applies to their website. This is because we are all users of websites and as users themselves they can understand how their own perception of a site can be affected by its performance.

To designers the perceived performance has an impact on the user experience of the site. It is the first impression the user gets when they visit your site so even if the site’s design is visually amazing a site that loads slowly has already given a bad impression.

To clients/product managers, performance can affect what they are trying to achieve. The majority of clients/product managers are aiming to reach specific KPIs. Examples of these might be:

Number of new signups

Minimising the cost of acquiring or retaining customers

Higher visitor return rate

Lower visitor bounce rate

Higher interaction rate

Ranking in search engines

Performance however has an impact on all the KPIs of our site. In order to demonstrate this to our stakeholders we would need to use data.

Using data to demonstrate benefit of performance

Luckily many large brands are keen to publicise what they have achieved through improving the performance of their site. Here are a few such case studies:

Amazon found that every 100ms delay in loading a page cost them 1% in sales. To put this in perspective, in 2014, Amazon revenue totalled 89 billion dollars, so 1% would be almost 900 million dollars

delay in loading a page cost them in sales. To put this in perspective, in 2014, Amazon revenue totalled 89 billion dollars, so 1% would be almost 900 million dollars Google found an extra 500ms delay loading search results decreased traffic by 20% , to put this in perspective that is 20% fewer adverts they can show to their users.

delay loading search results decreased traffic by , to put this in perspective that is 20% fewer adverts they can show to their users. The Trainline reduced latency by 0.3 seconds and customers spent an extra 8 million pounds a year.

and customers spent an extra a year. Walmart saw for every 1 second decrease in page load they had a 2% increase in conversions.

More examples of case studies can be found at wpostats.com. Using up to date data on how performance impacts your users can help your stakeholders understand the impact on the business.

If you are interested in running your own study on how performance impacts your business’s site I am currently working on another blog post which which will take you through the steps you will need to take, for notifications of when this is posted follow me on twitter.

Where is it hard to demonstrate the benefit?

It is very easy for us to link a metric showing an increase in performance to an increase of a KPI such as signups, however there are other impacts of having a performant site which are not quite as easy to track.

The key metric with a difficult to measure benefit is search engine ranking. It is therefore unlikely you will find a study that shows an increase in perfomance being linked to better search engine rankings. The reason for this is that there are a large number of factors that contribute to a websites search engine rankings. This includes things in our control such as the content and things outside our control including what websites are linking to our website and the content of competing website’s.

When it comes to search engine optimisation we therefore need to take the search engines (Google, Bing etc) word on it that our site performance will affect our rankings.

The competitive advantage of performance

Having demonstrated with data the advantage of performance we can see that there is a competitive advantage in a site being performant. It therefore is important that we ensure our site is more performant than our competitors.

To measure ourselves against our competitors we can use Web Page Test to perform a visual comparison. To do this we can simply visit https://www.webpagetest.org/video/ and enter the different competitors we want to benchmark against.

Once the test has finished running you can then export a video like this showing your site and your competitors. Below is an example video that I generated comparing Beamly against a few of its competitors.

How much faster should my site be?

Being able to benchmark against our competitors enables us to see how we perform against them. In order to have a competitive edge, we want to ensure our site loads faster than our competitors.

Steven Seow identified the minimum we should be aiming to achieve in his book “Designing and Engineering Time” where he suggests a 20% rule. The 20% rule is as follows; in order for your users to perceive a task as faster than another task the difference in time needs to be a minimum of 20%.

Tim Kadlec summed up how this applied to the web in his post “Fast Enough” saying:

For example, say a competitors site loads in 5 seconds. 20% of 5 seconds is 1 second. So to be perceived as faster than them, you need to have your pages taking no longer than 4 seconds (5 seconds load time - 20% difference).

When comparing our competitors we therefore want to look at the load time of our faster competitor and then set our own target as 20% less. Its important to add a caveat to this however; if your competitors site takes 10 seconds to load, to be perceived faster you only need to load your site in 8 seconds BUT 8 seconds is still a really slow site. In this case you should aim to be significantly faster than your competitor.

In Summary

As developers it falls on our shoulders to ensure that performance championed where we work. In developing a site, whether it is an existing site or new build it is important that all those involved are aware of the impacts of performance.

To enable them to understand these impacts they need to understand the 3 different kinds of performance that we looked at in this post. In particular they will want to understand the perception our users get about how fast our site is when they visit our site. In discussions with stakeholders its this perceived performance that we want to use when talking about the impacts performance has.

Once your stakeholders understand the kinds of performance it is important that they can see the benefits to your business. The best way we can demonstrate the benefits it through the use of data, both through looking case studies and through comparing agaisnt your competitors.

I hope this post along with the next few I am currently writing help you understand how you can be a champion of performance in your business.

Are you looking for your next role? I work as an Lead Engineer at RVU where we are currently looking for Full Stack software engineers based in our London office. Find out more

Please enable JavaScript to view the comments powered by Disqus.