Page speed usually gets argued as a technical concern with an SEO justification attached. For a site running paid traffic, there is a much more direct argument available, and it is arithmetic rather than best practice.
A bounced organic visitor cost you nothing. A bounced paid visitor cost you the full click fee, and produced nothing in return. Page speed is one of the few conversion levers with a countable price attached to failure.
The compounding
Google and SOASTA trained a model on millions of mobile sessions in 2017 and published the bounce probability curve. It is worth reading as a ladder rather than a threshold.
Google and SOASTA machine learning study, 2017. Vendor research from a company that profits when the web gets faster, and the direction is corroborated across several independent datasets.
Bounce probability, relative to a one second load. 1s: baseline. 3s: +32%. 5s: +90%. 6s: +106%. 10s: +123%.
The popular reading of this data is a three second cliff. The data does not show a cliff. It shows a slope with no safe side, which is worse news and more useful, because it means there is no threshold at which optimisation stops paying.
Putting a number on it for your own site
You do not need a study. You need four numbers you already have.
- $20,000Monthly paid spend at 10,000 clicks and a $2 CPC
- 5,500Visitors who bounce at a 55 percent rate
- $11,000Spend attached to visitors who saw nothing and left
- $1,100Recovered by a 10 percent relative improvement in bounce rate
Worked with round numbers: 10,000 paid clicks a month at $2, a 55 percent bounce rate, and a load time you would like to improve.
That last figure is the one to take into a prioritisation meeting. It is a monthly number, it recurs, and it compares directly against the cost of the engineering work. Note the honest caveat: a bounce is a lost visitor rather than a lost sale, so the revenue impact is some fraction of that. Even at a quarter it usually clears the bar.
Where the time goes
Almost always third parties, and almost always more of them than anyone remembers agreeing to.
- 01A tag manager, which is a loader for an unknown number of other things
- 02Analytics, often two of them, because a migration never finished
- 03A chat widget loading a full framework for a bubble nobody clicks
- 04An A/B testing script that blocks rendering to avoid flicker, trading speed for a cleaner test
- 05A session recorder capturing DOM mutations on every interaction
- 06Ad platform pixels, one per channel, each with its own retry behaviour
We build one of the things on that list, so treat the following with appropriate suspicion. The reason our tracker has zero runtime dependencies and a hard size budget under 5KB is this exact list. It is also a security argument rather than only a speed one, since every dependency in a browser bundle is somebody else's compromise becoming your customers' problem.
The audit worth doing takes an afternoon. Open the network panel, sort by transfer size, and for each third party ask who owns it, what decision it informs, and when that decision was last made. Tags accumulate because removing one requires knowing why it was added, and nobody wrote that down.
Then measure in the field rather than the lab. Our piece on the metric that replaced FID covers why lab tools cannot measure INP at all, and the five speed statistics everyone quotes checks the provenance of the numbers you will meet in this argument.