This content originally appeared on Web Performance Calendar and was authored by Stoyan
Intro. A confuse.
Have you ever read, or heard sentences like “a company X got NN% increase in revenue when they improved their site speed by YY%”?
Or something like this?
(Image shamelessly stolen from “Progressive Web App 2016” video)
I bet you have.
Working on the performance of an on-premise enterprise operational support system for 10+ years, I didn’t pay much attention to this as it was mostly out of my “reality” – an operator won’t leave the main app because it is not entertainingly fast.
Moreover, internal operation support systems usually have no direct relations with sales. With the risk of processing interruption – for sure. With ergonomics – quite often. With sales – rarely, and typically indirect. So, for a decade, performance for me was about decreasing probability of loss – rather than an increase in revenue.
But when I joined EPAM Systems in 2017, I started seeing this sentence much often. And I got … itching. I felt I am missing accuracy: when we think about performance, we do it in terms of significant digits, percentiles, multi-modal distribution, non-linear scalability. And we’re OK with the “Performance = Money”?
Do we mean “performance improvement was the only driver of revenue increase”?
Because it’s very tempting to start thinking like “every X% of a performance increase will bring Y% increase in sales”, like:
Rimprov = Rimprov * (1 + k), where k is a “performance to revenue increase factor”.
And managers seems to like it!
Source: https://xkcd.com/605/
Part one – humanitarian.
Let me give you two examples before I move on.
Example 1.
(Disclaimer: I am not related anyhow to or sponsored by below companies)
Please open https://www.lamborghini.com or https://www.bugatti.com
Take as much time as it required to assess how fast this site should be for you to buy their brand new car.
Example 2.
Please read this NY Post article
By the way, this is not the first time I see news meaning “X-Box fans were trying over and over, through page delays, timeouts and crashes, to reach and preorder so desired …er.. product”.
We are used to saying that customers will definitely leave the site if it feels tooooo slooww.
But X-Box pre-orders/sales history proves to be quite the opposite:
- Some of them would tolerate page crashes and bad performance if you are the only place to buy what they want
- Some of them would tolerate bad performance because of better price/delivery/service
I have to admit: I am a strong supporter of the theory that the customer base for any product/service has an upper limit. Of course, if you are the only supplier of oxygen on a Lunar base – then everyone is your customer. But, still – on the Moon, not on Earth.
So, here is how I see it:
- Site performance has no impact on the “Group-N[ever]”, those who aren’t buying a product at all because they have reasons not related to performance – from financial to matter of taste.
- Site performance has low to zero impact on the “Group-A[lways]”, those who ARE buying on that site whatever it takes – and site capacity is more essential than responsiveness (aka speed)
- Site performance could affect the “Group-M[aybe]” those who might buy on that particular site, or do it somewhere else – they are kind of ‘site agnostic’
- Site performance could bring you some new visitors because of improved search rank, but they are still from the “Group-M”
In layman words: the slower site is, the more potential customers will bounce, the faster site is – fewer potential customers will bounce. Something like graph below:
So, I suggest treating performance of e-comm site as a detractor – the factor decreasing actual customer base from its maximum potential.
And, because visitors do NOT measure performance, but feel it – not every measurable performance improvement could be noticed and impactful. For example, 50 milliseconds shaved off 5+ seconds LCP metric most probably won’t change bounce rate.
Summing up, simplified speed-sales formula to me looks like
Rimprov = Price * Nalways + Price * Gmaybe * Ximprov
…where performance impact is Ximprov = [0..1] – a portion of Group-M visitors, who did not abandon and finalized a purchase because of the performance improvement.
Part two – diminished return.
In early 90ies in our Economics 102 course, we were told about diminishing value concept. Let me apply it to the site performance improvements:
Let’s assume we have 20% performance improvement caused 10% monthly sales increase.
For the sake of simplicity, let’s assume:
- the site we’re dealing with is not season-dependant
- starting point was 5 seconds LCP metric
- every performance improvement is 20%
So, our first step was 5 seconds to 4 seconds (0.8*5000) and resulted in 10% monthly sales increase. Next step would be 3.2 seconds, and we could expect Group_M will react.
Then it would be 2.56 seconds, and it should be noticeable.
Then 2.048 seconds – minus 500msec, should be still noticeable.
But will next step from 2.048 to 1.64 seconds have same impact? And the next one, to 1.3 seconds? Will 300 milliseconds off 1.6 seconds bring the same 10% sales increase?
What about 300ms off 1.3 seconds – what sales increase would be?
I have not such experience yet, so I am doubtful that it will be the same 10%.
By the way, what about efforts? What is the cost for each of 20% steps from 5seconds down to 1.3 – are they equal? Will sales increase worth it?
To my experience, it depends: performance impact/efforts margin for site doing 100USD/hour would be different from the site doing 10K/hour. When we should stop – when performance improvements cost overcomes sales increase, or right before – so the stakeholders still feel themselves “winners”?
Summary
Performance improvements for e-commerce site seems to be limited factor with decreasing “power”.
Does it mean that performance engineering in e-commerce is declining?
I don’t think so, because there are quite a lot development teams on the first and second levels of “NFR process maturity”, so we will have work to do for a while.
This content originally appeared on Web Performance Calendar and was authored by Stoyan
Stoyan | Sciencx (2020-12-23T17:29:28+00:00) Non-orthodox (renegade) rumblings on speed-money relationship. Retrieved from https://www.scien.cx/2020/12/23/non-orthodox-renegade-rumblings-on-speed-money-relationship/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.