Page speed and conversion: separating the myth from the measurement

Speed is the most oversold item in small business web work, because it produces a number. Numbers feel like progress, and a report showing a score going from red to green is easy to sell and easy to bill.

The number is not the customer. Nobody has ever chosen a plumber based on a performance score.

Does page speed actually affect conversion?

Yes, and there is better evidence for it than for almost anything else in web design, because speed is one of the few things large companies can isolate in a controlled experiment.

The strongest source is a peer reviewed 2014 KDD paper by Ron Kohavi, Alex Deng, Roger Longbotham and Ya Xu, written out of Microsoft and LinkedIn. They ran deliberate slowdown experiments at Bing, adding 100 milliseconds of delay to 10% of users and 250 milliseconds to another 10%, for two weeks. Their conclusion, in their words, is that every 100 millisecond speedup improves revenue by 0.6%. A 250 millisecond server delay cost about 1.5% of revenue and 0.25% of clickthrough rate. Amazon, they report separately, saw a 1% drop in sales from a 100 millisecond slowdown, and Google's Jake Brutlag measured searches per user falling 0.2% to 0.6% when the results page was slowed by 100 to 400 milliseconds.

Those are real, isolated, enormous samples. They are also all desktop, and the paper says so itself. They are search engines and retailers, not a roofing company.

The mechanism that matters for you is narrower and simpler. A visitor taps a search result on a phone with a weak connection, sees white, and goes back to the results. They never saw your business. Google's own SOASTA analysis, using a model with 90% prediction accuracy, put it this way: as page load time goes from one second to 10 seconds, the probability of a mobile visitor bouncing increases 123%. That is 2018 data and it should be dated when quoted, but the direction has not changed.

Fix the delay a human would notice. Ignore the score.

Is it true that Google lost 20% of traffic from half a second?

No, and this is the single most repeated claim in the entire page speed category.

The story comes from a talk by Marissa Mayer, then at Google, describing an experiment where Google showed thirty search results instead of ten. Traffic and revenue from the experimental group dropped 20%, and her explanation was that the page took half a second longer to generate.

Kohavi and his coauthors take that claim apart in the same paper, and they are the right people to do it because they had run the isolating experiment. Their words: they suspect the delay only accounts for a small percentage of the loss. Working from Bing's own controlled slowdown data and a linear approximation, 500 milliseconds is worth about 3% of revenue, not 20%. The other seventeen points came from showing thirty results, not from the half second.

Half a second was worth roughly three points. The pitch that quotes twenty is quoting the wrong cause. Anyone who hands you that number has not read past the headline, and it is a fast way to check whether a performance proposal is built on reading or on repetition.

Which speed problems matter and which do not?

Four things account for nearly all real slowness on small business sites, and none of them are exotic.

Enormous images. A photo exported straight from a camera can be many times larger than it needs to be, and one uncompressed hero image will outweigh every other optimization on the page. Google's analysis of 11 million mobile web domains on a representative 4G connection found 79% of pages over 1MB, 53% over 2MB and 23% over 4MB, and that 25% of pages could save more than 250KB by compressing images and text alone. That is where almost all of the available gain sits.

Too many third party scripts. Chat widgets, review carousels, booking embeds, three analytics tools, two pixels from an agency that stopped working with you two years ago. Every one loads separately and blocks the page. Removing dead scripts is free.

Cheap hosting under load. If the server takes a long time to send the first byte, nothing on the page can help. This is the one case where paying more actually fixes something.

Video backgrounds and animated heroes. Heavy, rarely persuasive, and hostile on mobile data.

Now the part that gets left out. Position on the page decides whether milliseconds are worth anything. The same Bing team delayed elements in the right hand pane by 250 milliseconds in a controlled experiment covering almost 20 million users, and the impact on key metrics was not detectable at all. A delay that costs real money above the fold costs nothing below it. That single finding kills most of the work sold as speed optimization.

Why is my score bad when the site feels fast?

Because most scoring tools simulate a slow device on a throttled connection, which is not your office fiber and your new phone.

That simulation is useful information. It is closer to the customer standing outside on a weak signal than your own experience is. But the score compresses many different things into one figure, and the underlying metric is often broken in a way nobody mentions.

Page load time is usually measured at the browser's window load event, and Kohavi's paper shows how badly that misleads. An Amazon page can render everything above the fold in 2.0 seconds while the load event does not fire until 5.2 seconds. Gmail is the reverse: the load event fires at 3.3 seconds, at which point only a progress bar is visible, and the real content arrives at 4.8 seconds. One of those sites looks slow and is fast. The other looks fast and is slow.

Google's current Core Web Vitals are a better set, because they measure what a person sees. Largest Contentful Paint should be at or under 2.5 seconds, Interaction to Next Paint at or under 200 milliseconds, and Cumulative Layout Shift at or under 0.1, all assessed at the 75th percentile of real visits.

Then test it the way it will be used. Load your site on a phone, on cellular data, away from your building. Count out loud until you can read the headline. If you get past three or four, you have a real problem. If the headline appears fast and the rest fills in behind it, you are fine no matter what the score says.

This is the same discipline that applies to everything else on a phone, and the problems desktop testing never reveals are usually more expensive than the load time anyway.

What is a tenth of a second actually worth to me?

Run it with your own numbers. This is the calculation that ends the argument.

Start with the best available lift figure. Google, Deloitte Digital and Fifty-Five studied 37 brands across EMEA and the US, covering 30.5 million sessions over four weeks in October and November 2019. A 0.1 second improvement in mobile load time produced an 8.4% increase in retail conversions and a 9.2% increase in average order value. Date it hard when you use it. That is nearly seven year old data from large retail and travel brands, not local service sites.

Apply it to your traffic. Say you get 500 sessions a month and convert at 3%. That is 15 leads. An 8.4% relative improvement gives you 16.26 leads, so a tenth of a second is worth about one and a quarter extra inquiries a month.

Price it. If a lead is worth $400 in eventual revenue to you at your close rate, that tenth of a second is worth roughly $500 a month. That is a real number and it is not nothing.

Now the part that matters. You cannot verify it. To detect an 8.4% relative improvement on a 3% base rate, the two proportion sample size formula gives about 73,300 visitors per variant, so roughly 146,600 visits in total. At 500 sessions a month that is 293 months (derived), which is a little over 24 years. You would be measuring a business that stopped existing two decades earlier.

So the honest position is this. Speed is worth fixing because the physics are well established at large scale and the cheap fixes cost you an afternoon. It is not worth a monthly retainer, because you will never see it in your own numbers and the vendor knows that. Run it through the conversion math that decides where spending pays before you approve one.

How fast is fast enough?

Fast enough that the visitor sees the answer to their question before they consider leaving.

Practically, that means three things render early: the headline that confirms what you do, the phone number or button, and enough layout that the page does not jump around while they are trying to tap. Everything else can arrive late, and the Bing right pane experiment is your permission slip for that.

Page weight is not the same as page length. A long service page that loads its first screen quickly is fine, which is worth remembering when someone tells you to cut content for speed. Long pages can convert better than short ones, and the fix for a heavy long page is compression and lazy loading, not deletion.

What to do this week

Find your three largest images and compress them. Any free image compressor will do it in ten minutes and it is usually most of the available improvement.

Then open the source of your homepage, or ask whoever manages it, and list every third party script loading on it. Delete every one you cannot name a current use for. Old pixels and abandoned tools are the most common thing I find on small business sites.

Turn on lazy loading for images below the first screen if your platform supports it, which most do with a checkbox.

Then do the cellular test away from your office and time how long until the headline is readable. Write that number down. That is your real speed metric and it is the only one a customer experiences.

If you are mid project on branding or visual work, keep this in view, because heavy graphics arrive during those projects. Whether a logo matters much for a local business is a separate argument, but a giant uncompressed version of it on every page is not helping either case.

Questions about whether speed is your problem?

Email me at eric@seod.com with your URL. I will load it on a phone on cellular data, time how long until your headline and phone number are readable, and send you that number along with the single heaviest thing on the page.

If the answer is that your site is fast enough and something else is costing you inquiries, that is what the reply will say, and it will save you a performance invoice.

Otherwise, keep reading the conversion library.