The Need for Speed

One of an occasional series of articles about the technical fundamentals which underpin the ability to meet the demand in your market or information space (the latter being what my normal work is all about). This one's about speeding up web pages to astonishing load times. It's quite long, for a LinkedIn article, but I promise it's worth the time (10 mins). Go and make a cup of tea first, I would.

· * * *

Speed is just like logistics. If you can move products from a warehouse to a customer, then the problems are much the same.

Get the stuff, put it into packets, group the packets into larger bundles (files on a webserver, pallets on a truck), fill the trucks as full as possible, use fewer, bigger trucks where possible. Take the most efficient routes, and place product in distribution centres close to centres of population. Ruthlessly reduce the time taken from the order being received to the truck leaving the depot, reduce the packaging to no more than you need, use vehicles that can accelerate back up to speed quickly after any hold-ups (in a world where the fuel cost is zero and every vehicle travels as fast as it possibly can), don’t slow down if you lose something off the back (there’ll be another truck along in a minute). Oh, and don’t send things people didn’t order. And send things out before people ask for them.

Easy.

Well, no, not easy. But certainly a problem that is well within your capabilities to solve. So sit back, step away from your email and spend a very valuable hour finding out just how to get your customers to their goals by making your website awesomely, shockingly fast.

AT THE SPEED OF THOUGHT

The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it. — Mark Weiser, the ‘father’ of ubiquitous computing, Xerox Palo Alto Research Center (PARC)

As you are reading these words, you are absorbing their information almost instantaneously, without consciously performing the act of reading. Reading is a ‘profound technology’ in Mark Weiser’s phrase. Most of us have practised it so often that the time it takes to do requires no mental attention. That precious mental attention is devoted to the content of what you are reading, rather than to the act of getting it.

If we can make the act of getting a web page as instant as glancing at a word and reading it… what would that do? Does the difference between five seconds and four seconds… or even one second and two seconds… make a difference?

Yes. It does.

Just two seconds is all it takes to get distracted [for some academic references on this, see note 1]. This is because two seconds is as long something will stay in our short term memory without us having to mentally rehearse it. If something else takes our attention during that rehearsal — walking into a new room, for example, gets me every time — we can lose the task from our short term memory. To restore it, we have to delve into long term memory to see if we bothered to transfer it to store. If it’s not easily found, we can use a few tricks to ‘jog’ the long term memory, for example by walking back into the previous room. This improves our ability to search our long term memory for the item in question by adding a some context — a whole bunch of other things we may have stored at the same time, and hopefully, therefore, nearby.

With this in mind, it should come as little surprise that as waiting time for a web page gets longer, and as the new devices and environments we use them in bring with them ever increasing distractions, the likelihood of us becoming diverted from our task increases substantially. But what may be surprising is how much that distraction costs.

TIME IS MONEY. BUT HOW MUCH MONEY?

On Monday, December 4th, 2006, an ex-Amazon über-geek called Greg Linden gave a lecture to the Stanford University data mining class, CS345. Greg was the primary inventor and developer of Amazon’s recommendation engine, directly responsible for billions of dollars of incremental revenue for Amazon.com. Much of his presentation was devoted to the data science challenges of a recommendation engine, encouraging the students to measure and optimize again and again when approaching their own data science challenges. But two thirds of the way through, Greg suddenly dropped in a quote from Marissa Mayer from her spot at the Web2.0 conference earlier that year.

“Users really respond to speed.”

Then he said: “Marissa found a large drop in Google traffic if the page took longer to load. We at Amazon found something similar in our tests.”

The next slide contained just two short statements:

Greg wasn’t just Amazon’s recommendations guru. He was also a contributor to the overall architecture, design, performance analysis, and optimization of Amazon.com’s early web servers and website databases. Greg really knew what he was talking about. Amazon had conducted an audacious experiment. It had artificially introduced a series of delays into the load times of its pages, of up to a few tenths of a second. And what they found was being presented as a hard fact within Amazon. Every tenth of a second delay cost them 1% of sales [Wal*Mart saw similar - see note 2]

If time was money, Greg had suddenly made the conversion scale quietly public. A very small amount of time turned out to be worth a very, very large amount of money.

· * * *

THE FIVE ROAD BLOCKS TO SPEED

So why the heck is the web so slow? And why is it getting slower? It’s too easy to say that it’s because developers don’t build it right. Almost every developer I have ever met has been highly motivated by the idea of building something well — something they can be proud of. So what goes wrong? Why are we currently building web pages that load ten times slower than we could do? [see note 3]

My experience so far is that there are five common psychological road-blocks in the way:

• Road-block 1: People think the web is getting faster
• Road-block 2: People don’t really believe the value of getting faster
• Road-block 3: People don’t know what is reasonably achievable
• Road-block 4: People don’t know how to measure speed and speed improvements
• Road-block 5: Speed crosses business functions

ROAD-BLOCK 1: People think the web is getting faster

Connection bandwidth is increasing at an amazing rate. This alone makes it hard to believe that we need to do anything to make the web faster except sit around and wait. Sadly not. In June 2015, CNN reported “It's not you. Web pages really are loading slower” [see note 4]. Average website homepage size had doubled over the preceding 3 years to a horrifying (to me, at any rate) 2.1 MB. And it has kept on climbing since then.

The code used to generate the pages is bloating, images are getting bigger as screen resolution improves, and ever more third party add-ons (for tracking, customer analysis and more) are being added. At the same time website visitors are shifting from fast desktop wired connections to comparatively patchy, lossy mobile signals and Wi-Fi... with an ever growing number of devices in each household and every street competing for the available bandwidth.

ROAD-BLOCK 2: People don’t really believe the value of getting faster

In 2008, Dave Hyatt, a lead technical architect for Safari, Firefox and other browsers, read a blog post by a young developer who was suggesting a new way of selecting which elements of a page styling was applied to. Dave commented:

“The sad truth about CSS3 selectors is that they really shouldn’t be used at all if you care about page performance. Decorating your markup with classes and ids and matching purely on those while avoiding all uses of sibling, descendant and child selectors will actually make a page perform significantly better in all browsers.”

Steve Souders, a notable web speed evangelist, was intrigued. He ran his own tests and posted on his own blog that he had determined that the difference between ‘efficient’ and ‘inefficient’ selectors on a test page of 2,000 styled links was perhaps 20 to 50ms. Steve’s concluding paragraph ran:

“Based on these tests I have the following hypothesis: For most web sites, the possible performance gains from optimizing CSS selectors will be small, and are not worth the costs.”

And at that point the page speed community, such as it was, just moved on. A tribal elder had spoken, and there was nothing more to be done. No one said “Hang on a minute. If Amazon’s tests were right then that throws away a potential half-percent improvement in incremental revenue.” What Souders actually meant, of course, was that there were usually going to be bigger problems to concentrate on — quite right, there are. So no, it’s not the first thing you would look at. But not worth the cost? Really? Some quick back-of-the-envelope calculations are in order:

One-off Cost to Refactor CSS to make 20ms more efficient:

say ten days of rewriting and testing @ ￡400 per day

= ￡4,000.

Incremental Gain in Annual Revenue:

0.2% on website turning over ￡100M a year

= ￡200,000.

Assume modest gross margin @ 20%

= ￡40,000 gross profit (36-day payback on investment)

Not even people who work in the field of web performance have really and truly internalised that 100ms = 1% revenue equation. What hope then for the rest of us?

ROAD-BLOCK 3: People don’t know what is reasonably achievable

What does good look like? A 1-second page-load? 3 seconds? The following should be considered to be perfectly reasonable proactive targets for a typical page load.

1. Most server connections are made in less than 20ms.
2. Most landing page views do not require a URL redirection.
3. Most URL redirections take less than 50ms.
4. Most servers respond to a request in less than 100ms.
5. Most landing page views spend less than 750ms (regardless of device) downloading critical resources. At maximum bandwidth usage, perfect lossless transfer, and a typical 5Mbps available connection bandwidth, this gives you a maximum file-size of around 450KB (compressed).
6. Most pages start rendering (the ‘DOM Content Loaded’ navigation timing) by the 1000ms mark.
7. Most pages finish painting (so that all elements in the viewable portion of the window have finished loading) by the 1500ms mark.
8. Most users experience after-load frame rate of no less than 60 frames per second during scrolling.

ROAD-BLOCK 4: People don’t know how to measure speed and speed improvements

We are privileged to see the detailed analytics data from a number of major internet retailers. In 2014, we were developing our Value Landscape product, which spotted the causes of changes (‘deviancies’) we were seeing in that analytics data.

It's algorithms were interested in three particular kinds of change.

• Firstly, the case where a sub-category had a conversion rate (click-through rate, bounce rate, or transaction rate) that deviated strongly from the typical rate for the site — a rate deviancy.
• Secondly, the case where a conversion rate changed from one steady state over time to another, lower steady state, and did not recover — a step-change deviancy.
• Thirdly, the case where a conversion rate was sliding downwards over time — a rate-slide deviancy.

In each case, we calculated how much money would be made by correcting each deviancy, then ranked them by value. We also attempted to figure out the most likely cause of the most valuable deviancies.

In site after site, the story was the same. A site-wide rate-slide in what we called ‘engagement rate’ – the flipside of a site’s bounce rate was mirrored by an increase in page load time. The slower a page got, the more likely someone was to end their visit to the site and head on over to somewhere else.

How does the bounce rate vary with the page-load time? If you know that, you can model any speed gain in pounds and pence… as you can reasonably expect a 10% improvement in the bounce rate (from 40% to 36%, say) to translate to 10% more visitors… and 10% more revenue.

There is a sweet spot in the effect that page load speed has on bounce rate. A study by PhocusWright/Akamai in 2010 (Consumer Response to Travel Site Performance) suggested that “57% of online shoppers will wait 3 seconds or less before abandoning the site” [see note 5]. Our own research with our larger e-commerce clients... they need to be big enough for the sample sizes to be robust... backs this up. But the most interesting result is that you don't really see serious benefits until you start getting the page load time down below 2s.

***INSERT SPEEDOMETER GRAPHIC HERE WITH NOTE Generated by our Speedometer Google Analytics plug-in.***

It’s hopefully obvious that improving a page load time from 2.5 seconds to 2 seconds is likely to have a greater effect on the bounce rate than improving it from 10 seconds to 9.5 seconds.

ROAD-BLOCK 5. Speed crosses business functions

A QUICK CASE STUDY...

One of our large e-commerce retail clients conducted an inadvertent experiment across the calendar year of 2014. The website’s measured average page load speed slowed down by 0.94s. The site’s measured bounce rate worsened by 6.2% … with a spike in week 34 mirrored from one to the other strongly suggesting more than mere co-incidental correlation. To put it another way, the observed increase in bounce rate corresponded to lost online revenue of ￡27M that year.

To put it another way: +100ms = -0.7% sales

That’s pretty close to Amazon’s figures.

Our subsequent work identified three simple technical changes modelled to improve page load time by an estimated 215 milliseconds. To my knowledge they have not been implemented, due to the sheer organisational difficulty of getting the changes made. Given the estimated benefits, what was holding back taking action to improve? Lack of belief? No method to assess? No clear responsibility of any one business function?

· * * *

One of the main management challenges is the number of areas of expertise and functional responsibility that speed performance involves. These include:

• Physical hardware (servers, CPUs, routers, switches);
• Software defined networking;
• System architecture (webservers, databases, load balancers, CDNs);
• Operating System Kernel;
• TCP/IP settings and tuning;
• HTTP settings and tuning;
• Security policy, TLS/SSL setup and tuning;
• eCommerce platform setup and tuning;
• Web Application layer refactoring and tuning;
• Application Performance Measurement instrumentation;
• Webserver log analysis;
• Packet capture and analysis;
• User Experience design;
• QA testing;
• Front end development (HTML, CSS, JavaScript);
• Font design;
• Graphics production (graphic design, graphics processing, graphics serving);
• Analytics and Channel Tracking setup;
• Other third party service setup such as review services;
• Online (especially pay-per-click) advertising;
• Web Merchandising and day-to-day operational management.

IT directors, sysadmins/dev-ops, system implementers, e-commerce managers, marketing managers, back end and front end developers, graphic designers, and analytics analysts all need to be involved and pointed in the same direction.

There can be financial and budgeting challenges for agreeing whose budget should pay for speed improvements, or whether every budget be involved.

There may be particular cultural problems depending on the function – for example, IT usually prefer to resist change, as they are focused on stability, on preventing system failure, and on maintaining performance under heavy load, rather than introducing changes to improve performance when under normal load. Marketing tend to be rewarded on making rapid positive changes, not long-term strategic improvements to performance, and furthermore do not like to have to justify the impact every new idea for tracking, customer acquisition or retention may have on speed performance. Security specialists like security, and have never had to worry about speed, on the whole. Designers have focused on making it visually attractive, not fast.

The size of the prize, combined with these organisational, financial, technical, cultural, administrative, operational and compliance challenges involved means that CEO (or at least CTO/CIO/CFO) involvement is likely to be required.

But once you have managed that, the mere technical challenges are easy. Say hello to the sub-second page load.

· * * *

Intrigued? Want to knock down those road blocks as you accelerate towards a golden, market-aligned tomorrow? Coming soon:

• In Search of the Dark Bounce
• The Eightfold Path of Speed Reporting
• The Twelve Principles Of Speed

Notes

1. See any of Miller, R.B., 1968, Response time in man-computer conversational transaction. Proceedings of AFIPS Fall Joint Computer Conference, 33, 267-277; Shneiderman, B., 1984, Response time and display rate in human performance with computers. Computing Surveys, 16, 265-285; Nielsen, J., 1993, Response times: the three important limits. Ch.5, Usability Engineering. Academic Press; Baddeley, A.; Eyesneck, M. W.; Anderson, M. C. (2015). Memory. New York: Psychology Press.
2. A later study (February 2012) by Wal*Mart reported pretty much the same thing – a 100ms improvement corresponded to an incremental revenue growth of approximately 1%. We have an original copy of the Wal*Mart presentation available on request (it is no longer available online), assuming that they are relaxed about us sharing it. It used to be publicly available, after all.
3. Website speed checker tool Pingdom has collated statistics of websites that have used their tool in the past year: Average load time: 5 seconds. In Google’s Site Performance for Webmasters video, Maile Ohye, states that “2 seconds is the threshold for e-commerce website acceptability. At Google, we aim for under a half second.” My own work for a selection of enterprise e-commerce clients shows that a half-second median page-load to be perfectly achievable even for complex e-commerce sites.
4. https://money.cnn.com/2015/06/16/technology/web-slow-big/ – they were taking their data from http archive, the largest public repository of home page requests in the world. It has not improved much since.
5. https://www.akamai.com/us/en/about/news/press/2010-press/new-study-reveals-the-impact-of-travel-site-performance-on-consumers.jsp