📊 I took the csswizardry.com homepage and tested it over a 3G connection. I then ‘improved’ bandwidth or latency by 10% until 2× change, then I did 4× and 8× changes. 
📈 For every 10% improvement in bandwidth, we see an average 0.21% *increase* in FCP.
📉 An 8× improvement in bandwidth only yields a 1.64% improvement in FCP.
📉 An 8× improvement in bandwidth only yields a 1.64% improvement in FCP.
📉 For every 10% improvement in latency, we see an average 2.1% improvement in FCP.
📉 An 8× improvement in latency yields a 94% improvement in FCP.
📉 An 8× improvement in latency yields a 94% improvement in FCP.
🕵️♂️ Key findings:
🔍 Improvements in either are not guaranteed to be linear (i.e. a 10% improvement in latency != a 10% improvement in FCP; doubling bandwidth does not halve timings)
🔍 The user experience is far more tied to latency than bandwidth.
🔍 Improvements in either are not guaranteed to be linear (i.e. a 10% improvement in latency != a 10% improvement in FCP; doubling bandwidth does not halve timings)
🔍 The user experience is far more tied to latency than bandwidth.
💡 The former goes some way to discrediting ‘but connections are getting faster’ rhetoric; the latter confirms what we already know about the impact of latency on casual web browsing.
⚠️ I only measured FCP as it’s fairly network-bound and is a good UX metric.
⚠️ I ran 125 tests to get this data, but it’s still only one page on one site.
⚠️ My site is already fast, so not particularly representative of the web as a whole.
⚠️ I ran 125 tests to get this data, but it’s still only one page on one site.
⚠️ My site is already fast, so not particularly representative of the web as a whole.
⚠️ I’d expect to find different outcomes measuring something like load or LPH on image-heavy pages.
⚠️ I’d expect different outcomes if there was a substantial amount of weight on the critical path (e.g. Base64—yuk!).
⚠️ I’d expect different outcomes if there was a substantial amount of weight on the critical path (e.g. Base64—yuk!).
❓ Why doesn’t more bandwidth help?
🍩 Most pages—hopefully—don’t weigh many MB, so extra bandwidth is superfluous. It’s like expecting a truck would be able to deliver a single donut faster than a car. It can deliver more donuts, sure, but not one donut any faster.
🍩 Most pages—hopefully—don’t weigh many MB, so extra bandwidth is superfluous. It’s like expecting a truck would be able to deliver a single donut faster than a car. It can deliver more donuts, sure, but not one donut any faster.
🐌 All new TCP connections go through a period of slow-start whereby they begin with only a ~14KB capacity. It takes a while for a connection to (if ever) reach full utilisation, and by the time it does, hopefully the page has started to render.
🖼 Because of the previous point, additional bandwidth isn’t usually realised until much later in the page-load lifecycle: ipso facto, smaller assets discovered early on (i.e. your critical path) are more sensitive to latency.
💡 When optimising for firstlike paint timings (SR, FP, FCP), optimise for latency rather than capacity. No matter how much better bandwidth gets, it’s not useful here.
