Why Bandwidth and Modern WiFi Matter

An evidence-based analysis of how higher bandwidth and WiFi 6/7 translate into measurable time savings, lower latency, better protocol performance and reduced household friction — challenging the claim that “50 Mbps is enough.”

Evidence Review · February 2026, revised August 2026. Sources classified by evidence strength: peer-reviewed / large-scale; industry measurement; vendor / small-n.

Headline figures

Metric	Figure	Detail
Foreground transfer savings	20–40 hr	WiFi 6/7 vs WiFi 5, per year
QUIC page load gain	100–500 ms	Per navigation, vs TCP+TLS
WiFi 6 latency under load	10–20 ms	vs 30–50 ms WiFi 5
Concurrent 4K streams at 100 Mbps	4 max	At ~25 Mbps per high-bitrate 4K stream, zero margin for anything else

The question this report addresses

The companion report Wasted Bandwidth in Swedish BRFs shows that the average Swedish BRF household loses 45.5% of its purchased bandwidth to the WiFi bottleneck. A natural objection is: does that gap actually matter? If a household “only needs 50 Mbps,” then losing the rest is wasteful in accounting terms but harmless in practice.

The objection usually rests on one of two round numbers. 25 Mbps is the download speed the US FCC adopted in 2015 as its definition of “broadband” — an increase from the 4 Mbps baseline in the 2010 National Broadband Plan — and the figure most “that’s enough to browse” arguments trace back to. 50 Mbps is the looser “plenty for a home” number that circulates in everyday debate. Both were framed for an era of one-device-at-a-time use, and neither was ever intended as a ceiling on what a household could benefit from. The rest of this report tests them against what households actually do today.

This report examines the evidence against that assumption across six domains: bulk file transfers, modern web protocols, WiFi latency under load, the compounding of sub-second delays, concurrent use, and video streaming. The conclusion is that the conventional “50 Mbps” threshold is based on outdated research and significantly understates what modern households require from their network.

The “25 Mbps is enough for browsing” claim is outdated

The canonical study everyone cites is Mike Belshe’s 2010 Chromium experiment showing diminishing returns above 5 Mbps. Belshe tested pages averaging about 700 KB with 60 HTTP requests. The web has changed fundamentally since then.

HTTP Archive’s 2025 Web Almanac measures the median desktop page at 2.9 MB across 77 requests. At the 90th percentile, desktop pages reach roughly 9.2 MB and 185 requests. JavaScript alone has ballooned: a 2024 analysis of popular sites found Instagram ships 16 MB of JavaScript, Gmail 20 MB, and Slack 55 MB (uncompressed). (HTTP Archive)

A March 2025 paper, Does More Bandwidth Really Not Matter (Much)? (Mostafa, Wittie & Goel), directly revisited those classic findings and concluded that, contrary to Belshe and Grigorik’s earlier results, both latency and bandwidth improvements produce steady gains in page performance — the authors explicitly did not observe the diminishing returns from additional bandwidth that the older studies reported. They found a meaningful share of sites remain primarily bandwidth-limited, so the old 5 Mbps “good enough” plateau no longer holds as pages grow heavier.

Bulk file transfers: foreground vs. background

Not all bandwidth consumption is created equal. There is a critical distinction between foreground transfers (where someone is actively waiting) and background transfers (which complete unattended). This matters because the cost of slow foreground transfers is experienced directly as lost time, while slow background transfers merely occupy the network longer.

Foreground transfers — someone is waiting

These are the moments where bandwidth directly translates into human waiting time: downloading a game before you can play it, restoring a phone from backup, or waiting for a large project file to sync before a meeting. The table shows transfer time at typical WiFi-delivered speeds.

Scenario	Data size	WiFi 5 (225 Mbps)	WiFi 6 (400 Mbps)	WiFi 7 (750 Mbps)
AAA game install (CoD, Baldur’s Gate 3)	100 GB	59 min	33 min	18 min
macOS / Windows feature update	15 GB	9 min	5 min	3 min
iPhone/iCloud full restore	64 GB	38 min	21 min	11 min
Cloud project download (Figma, CAD)	5 GB	3 min	2 min	53 sec

• WiFi 5
• WiFi 6
• WiFi 7

Figure 1: Foreground file-transfer time by WiFi generation (minutes) — the wait before you can use a downloaded game, update or backup.

A household that downloads two AAA games, performs two OS updates, and does one phone restore per year spends roughly 3 hours waiting at WiFi 5 speeds versus 1 hour at WiFi 7. Households with multiple gamers or frequent large-file workflows (video editing, photography) can easily multiply this by 5–10×.

Background transfers — nobody is watching, but the network is occupied

App updates, photo sync, IoT firmware, cloud backup, and automatic OS patches all transfer data without anyone actively waiting. We estimate a tech-active household moves roughly 150–250 GB per month in background transfers. At WiFi 5 speeds, this occupies the connection for approximately 1.5–2.5 hours per month; at WiFi 7 speeds, under 40 minutes. The cost here is not direct waiting but network congestion during transfer windows: a 4 GB iOS update downloading over WiFi 5 can measurably degrade streaming and video-call quality for other household members during the 2–3 minutes it runs.

Scenario	WiFi 5 (225 Mbps)	WiFi 6 (400 Mbps)	WiFi 7 (750 Mbps)
100 GB game	59 min	33 min	18 min
15 GB OS update	9 min	5 min	3 min
64 GB cloud restore	38 min	21 min	11 min
5 GB project file	3 min	2 min	0.9 min

QUIC and HTTP/3: why modern protocols reward better networks

The QUIC protocol (RFC 9000), built on UDP with integrated TLS 1.3, now underpins HTTP/3 — which W3Techs measures on roughly 40% of all websites (August 2026), including Google, YouTube, Facebook, Instagram, and most Cloudflare-hosted sites. It changes the bandwidth equation in three ways. (W3Techs / IETF)

Faster connection setup. Traditional TCP + TLS 1.2 requires three round trips before data flows. QUIC’s 1-RTT mode needs one; 0-RTT mode for returning visitors sends data with the very first packet. On a path with 100 ms round-trip time, this saves 200–300 ms per new connection. With Swedish fibre’s typical 12 ms ping to domestic CDN nodes, the saving is 24–36 ms per connection — smaller but repeated across the 77–185 resources in a modern page load. (Cloudflare engineering)

No head-of-line blocking. In HTTP/2 over TCP, a single lost packet stalls all multiplexed streams until retransmitted. QUIC isolates streams: a lost packet on one resource blocks only that resource while the rest continue. This is particularly relevant on WiFi, where packet loss rates of 1–5% are common due to interference and contention. Under these conditions, QUIC’s advantage over TCP grows with the number of parallel streams — which is to say, it grows with page complexity. (APNIC / RWTH Aachen)

Measured real-world gains. Google’s 2017 SIGCOMM paper reported QUIC reduced Search latency by 8% on desktop, with the slowest 1% of users seeing up to 16% improvement. YouTube rebuffering dropped 18%. (ACM SIGCOMM) Wix measured LCP improvements of up to 20% at the 75th percentile — often exceeding 500 ms of absolute reduction. (Wix engineering) Cloudflare found HTTP/3 TTFB averaged 176 ms versus 201 ms for HTTP/2, a 12.4% improvement. (Cloudflare benchmark)

300 milliseconds is not negligible

The strongest evidence that sub-second delays are perceptible comes from a natural experiment the mobile industry ran for nearly a decade. Starting with the original iPhone in 2007, mobile browsers added a 300–350 ms delay between tap and response to distinguish single-tap from double-tap-to-zoom. The result was universal complaints about “laggy” web apps. Financial Times built the FastClick library to eliminate it. Chrome removed the delay in 2014, Firefox and IE followed, and Apple fixed Safari in March 2016. The entire browser industry coordinated to remove a 300 ms delay because users found it unacceptable. (Chrome developer blog)

Large-scale business experiments confirm this sensitivity at even finer granularity:

Source	Finding	Scale	Evidence
Google / Deloitte (2020)	100 ms faster → 8.4% higher retail conversion	30.5M sessions, 37 brands	published study
Akamai (2017)	100 ms delay → 7% conversion drop	10 billion visits	published report
Google (2009)	100–400 ms slower search → 0.2–0.6% fewer searches/user	Google-scale A/B test	Google research blog
Amazon (2006)	100 ms delay → 1% revenue loss	Attributed to Greg Linden	conference talk, unverified
Walmart (2012)	1 sec faster → 2% conversion increase	Walmart.com	conference presentation

The physiological dimension is less well-studied but directionally consistent. Riedl et al. (2012) measured elevated salivary cortisol during technology delays — a genuine stress-hormone response, not mere annoyance. (BISE journal) Ericsson’s ConsumerLab study (2016) found that buffering delays of 6 seconds produced stress responses comparable to watching a horror film, measured via EEG and heart rate, though Ericsson does not disclose the sample size and the study is vendor-funded, which limits the precision of that comparison. (vendor-funded)

WiFi 6 and 7 latency: the hidden improvement

Bandwidth is what people buy; latency is what they feel. WiFi 6 and 7 introduce scheduling improvements that reduce local wireless latency — the time between a device requesting airtime and actually transmitting — by an order of magnitude in congested environments.

WiFi generation	Idle latency	Under load (10+ devices)	Gaming latency
WiFi 4	10–30 ms	50–100+ ms	Not competitive
WiFi 5	5–10 ms	30–50 ms	20–40 ms, spikes >100 ms
WiFi 6	3–8 ms	10–20 ms	10–20 ms, stable
WiFi 7	1–3 ms	3–8 ms	3–8 ms, near Ethernet

WiFi generation	Idle	Under load (10+ devices)
WiFi 4	20 ms	75 ms
WiFi 5	7.5 ms	40 ms
WiFi 6	5.5 ms	15 ms
WiFi 7	2 ms	5.5 ms
Ethernet	0.5 ms	0.5 ms

• Idle
• Under load (10+ devices)

OFDMA (WiFi 6): serving multiple devices per transmission

On WiFi 5, only one device can transmit at a time on each channel (CSMA/CA contention). Every other device waits. OFDMA in WiFi 6 subdivides each transmission into resource units, allowing the router to serve multiple devices simultaneously. An IEEE study (Avallone et al., 2021) found this reduces median local WiFi latency from approximately 5 ms to below 1 ms. (IEEE) Qualcomm and the Wi-Fi Alliance measured 40% downlink latency reduction in home scenarios and up to 93% in dense environments. (Wi-Fi Alliance test) ACM SIGMETRICS 2023 reported 3× throughput gains and 5× latency reduction with OFDMA in dense uplink scenarios. (ACM SIGMETRICS)

MLO, BSS Coloring and Preamble Puncturing (WiFi 7)

Multi-Link Operation (MLO) allows a device to use the 2.4 GHz, 5 GHz and 6 GHz bands simultaneously. If one band encounters momentary interference, traffic shifts to another without reconnection. Simulations show 2.66× lower delay versus single-link; Intel reports approximately 60% lower latency than WiFi 6. (Intel, simulation) MediaTek claims up to 80% latency reduction and 300% throughput improvement. (vendor marketing)

BSS Coloring (WiFi 6) enables spatial reuse: in a dense apartment building, a router can transmit simultaneously with a neighbouring network on the same channel if the signals are sufficiently separated, improving throughput by up to 43%. (IEEE 802.11ax) Preamble puncturing (WiFi 7) prevents a single interfered 20 MHz subchannel from disabling an entire 160 or 320 MHz channel: the router blocks off only the affected portion and keeps using the rest of the channel that would otherwise be lost. (IEEE 802.11be)

How sub-second savings compound

Adults interact with their smartphone 150–200 times per day (Reviews.org’s survey reports 186 checks/day in 2026, down from 205 the year before). Most of these interactions involve some network activity — loading a feed, checking a notification, opening a link.

It would be misleading to attribute a full 300 ms saving to WiFi improvements for each interaction. The total latency of a page load or app interaction includes server processing, CDN delivery, TLS negotiation, DNS lookup, and rendering — of which local WiFi latency is one component. A realistic decomposition:

Latency component	WiFi 5 contribution	WiFi 6/7 contribution	Saving
WiFi airtime / local latency	5–50 ms	1–15 ms	4–35 ms
Connection setup (QUIC 0-RTT benefit)	24–72 ms	0–12 ms	12–72 ms
Bandwidth transfer (2.9 MB median page)	103 ms	58 ms	45 ms
Total WiFi-attributable saving			60–150 ms

• WiFi airtime
• Connection setup (QUIC)
• Data transfer (2.9 MB page)

Figure 4: Where the time goes in a typical page interaction (representative midpoints of the ranges above). The largest slice is data transfer — a throughput-bound step, so raising bandwidth shrinks it directly, on top of any latency gain.

Using the conservative end — 60 ms saved per interaction, 150 interactions per day — yields 9 seconds per day per person, or 54 minutes per year. At the upper end (150 ms × 200 interactions), it is 3 hours per year per person. For a Swedish household of 2.3 people, the aggregate is 2–7 hours per year in micro-latency alone.

These numbers are modest compared to the foreground file-transfer savings (20–40 hours/year). But they carry disproportionate psychological weight because they occur during active attention — the moment you tap and wait — rather than as a background process. Each sub-second delay falls within the 100 ms to 1 second range that Nielsen’s response-time thresholds identify as the zone where the user notices the system is not responding instantly but has not yet lost focus. (NN/g)

Concurrent use: how the 100 and 250 Mbps baselines hold up

The “50 Mbps is enough” claim implicitly assumes one activity at a time. Real households are simultaneous. The table below shows a realistic weekday-evening scenario for a family of three.

Activity	Down (Mbps)	Up (Mbps)	Who
4K Netflix stream	25	—	Living room TV
4K YouTube / TikTok	20	—	Teenager’s phone
Teams video call (HD, screen share)	4	4	Parent, home office
Game download in background	variable	—	Console/PC
iCloud photo sync	—	5	Multiple phones
2 security cameras	—	6	Always-on
IoT background (15–20 devices)	5	2	Smart home
Total (excl. game download)	54	17

Two subscription tiers dominate the BRF market and are each defended as “enough”: 100 Mbps, the old “good enough” baseline, and 250 Mbps, the tier that has quietly become the new default. The evening scenario above shows how each holds up.

At 100 Mbps, the 54 Mbps baseline leaves just 46 Mbps of headroom — the game download proceeds slowly, but any additional stream or a second video call pushes the link to saturation. The upload at 17 Mbps is the tighter constraint on a symmetric 100/100 line: a second parent on Teams consumes what remains. The old baseline works only as long as the household does one thing at a time — precisely the assumption modern use has abandoned.

At 250 Mbps, the same evening runs with 196 Mbps of headroom — comfortable for genuinely simultaneous use. But 250 Mbps carries a hidden ceiling: it is almost exactly the real-world throughput of a WiFi 5 router (~225 Mbps), the generation still serving roughly 38% of BRF homes. On that hardware a 250 Mbps subscription is delivered in full and nothing beyond it can be — 250 is at once the sensible baseline and the WiFi 5 wall. Paying for 500 Mbps or gigabit while running WiFi 5 hands most of the increase straight to the bottleneck — the 45.5% loss our companion wasted-bandwidth analysis quantifies.

At 500 Mbps and gigabit, contention effectively disappears — every device behaves as if it had the line to itself — but only if the WiFi can carry it, which in practice means WiFi 6 or 7.

Figure 5: Time to download a 100 GB game at each subscription tier, WiFi permitting. The old “100 Mbps is enough” baseline is roughly 10× slower than gigabit for the large files modern households now move routinely — and on a WiFi 5 router, tiers above 250 Mbps cannot be delivered at all.

Emerging use cases push the requirement higher still. NVIDIA GeForce NOW requires 45 Mbps for 4K/120fps cloud gaming (NVIDIA specs). Meta Quest 3 needs 200 Mbps for high-quality PC VR streaming via Air Link. YouTube’s 8K content (already available) needs an estimated 100 Mbps — a widely-cited third-party figure; YouTube itself publishes recommended speeds only up to 20 Mbps for 4K. A single cloud gaming session alone can consume the entire budget that is sometimes still cited as “sufficient for a household.”

Video start-up, seeking, and why more bandwidth loads faster

When you press play on a video, nothing appears on screen for a moment. That pause has a name — start-up delay, the lag between clicking play and the first rendered frame — and it is one of the standard measures researchers use for streaming quality (Yin et al., SIGCOMM 2015). What fills the pause is simple: the player cannot show a single frame until it has downloaded enough video to fill a small starting buffer. Modern streams are cut into segments — separate files a few seconds long, typically several megabytes each (Apple HLS) — and the whole segment must arrive before its frames can be shown (RFC 8216). So the wait is really the time to pull down that first chunk of data.

That time is governed above all by how fast your connection can move data: a segment’s download time is its size divided by your available throughput (BOLA, IEEE/ACM ToN). Netflix’s own engineers give the concrete numbers: a 4-second chunk encoded at 3 Mbit/s is about 1.5 MB, and that chunk takes roughly 4 seconds to arrive on a 3 Mbit/s link but about 1 second on a 12 Mbit/s link (Stanford/Netflix, SIGCOMM 2014). Faster pipe, faster first frame — and because the player has no other information about your network at the very start, it leans entirely on measured throughput to decide how sharp a picture it dares to load (Stanford/Netflix).

Seeking — dragging the scrubber to jump ahead — stalls for the same reason. The player only holds the part of the video it has already downloaded; jump somewhere it hasn’t and the buffer there is empty and must be refilled over the network before playback resumes (MDN). Every jump is a miniature start-up, and throughput sets how short it is.

Why bandwidth, not just latency, is the lever here

The report elsewhere rightly stresses low latency. But loading a video segment is a throughput-bound job, not a latency-bound one, because the file is large. A 6 MB segment fetches in about 1.92 s at 25 Mbps, 0.48 s at 100 Mbps and 0.10 s at 500 Mbps (Grigorik, HPBN). Raising round-trip latency from 10 ms to 50 ms on that same fetch adds only about 0.04 s — versus the ~1.44 s that dropping throughput from 100 to 25 Mbps adds (Grigorik, HPBN). Latency dominates only tiny transfers; a multi-megabyte segment is far past the point where bandwidth takes over.

Throughput	First 6 MB segment fetch	Rough effect
25 Mbps	~1.92 s	Near the abandonment threshold
100 Mbps	~0.48 s	Comfortable start
500 Mbps	~0.10 s	Effectively instant

Figure 6: The first video segment is a multi-megabyte download, so its fetch time is set by throughput, not latency — which is why more bandwidth produces a faster first frame.

This matters because viewers are unforgiving. Akamai’s study of 23 million views found people start abandoning a video once start-up passes ~2 seconds, with every extra second adding 5.8 percentage points to the abandonment rate, and a freeze lasting just 1% of a video’s length cuts how much is watched by about 5% (Krishnan & Sitaraman, ACM IMC 2012). The twist: better-connected viewers are less patient, not more. A faster building network is not polish — it is what keeps everyday viewing on the right side of that 2-second line. (One exception: for live, low-latency streaming, round-trip timing matters more than raw throughput — Wowza.)

Summary. The evidence across six domains — file transfers, web protocols, WiFi latency, micro-delay compounding, concurrent use, and video streaming — consistently points to the same conclusion: the bandwidth and WiFi quality that households need has risen well beyond the 25 Mbps “enough” benchmark — a figure the FCC did not adopt until 2015 (replacing the 4 Mbps baseline of the 2010 National Broadband Plan). The companion report Wasted Bandwidth shows that 45.5% of purchased bandwidth in BRF households is lost to WiFi bottlenecks. This report shows that the lost capacity is not academic overcapacity — it is bandwidth that modern devices, protocols and usage patterns are ready to consume, and that its absence produces measurable time loss, latency degradation and network contention.

Assumptions and source quality

This report distinguishes three levels of source quality throughout:

Peer-reviewed / large-scale: Published in academic venues (ACM, IEEE, USENIX) or based on datasets exceeding 1 million observations. Highest confidence.

Industry measurement: Engineering blog posts from major technology companies (Google, Cloudflare, Wix, Akamai) with described methodology but no formal peer review. Moderate confidence — likely directionally accurate but may reflect favourable conditions.

Vendor / small-n: Marketing claims from chipset or equipment vendors (Qualcomm, Intel, MediaTek, Ericsson ConsumerLab), or widely-cited anecdotes without published methodology (Amazon 100 ms claim). Use with caution; included for completeness, not as load-bearing evidence.

Assumption	Value
WiFi 5 throughput assumption	225 Mbps (download)
WiFi 6 throughput assumption	400 Mbps (download)
WiFi 7 throughput assumption	750 Mbps (download)
Background transfer estimate	150–250 GB/month
Smartphone interactions/day	150–200 (survey data)
WiFi-attributable latency saving	60–150 ms per interaction

References

Verified primary sources (URL-checked, August 2026). The numbered entries below were confirmed against the cited page during source review; the additional sources listed afterward are retained for completeness but were not individually link-verified.

1. IETF / RFC Editor — RFC 9000: QUIC — A UDP-Based Multiplexed and Secure Transport
2. Nikita Prokopov (tonsky.me) — JavaScript Bloat in 2024
3. Ilya Grigorik (igvita.com) — Latency: The New Web Performance Bottleneck (documents Belshe’s 2010 Chromium bandwidth experiment)
4. Mostafa, Wittie & Goel — Does More Bandwidth Really Not Matter (Much)? (arXiv 2503.03641)
5. HTTP Archive — Web Almanac 2025: Page Weight
6. W3Techs (Q-Success) — Usage statistics of HTTP/3
7. Langley et al. — The QUIC Transport Protocol: Design and Internet-Scale Deployment (ACM SIGCOMM 2017)
8. Robin Marx (Performance Calendar) — Head-of-Line Blocking in QUIC and HTTP/3: The Details
9. Cloudflare — Comparing HTTP/3 vs. HTTP/2 Performance
10. Google / Chrome Developers — 300ms tap delay, gone away
11. FT Labs (Financial Times) — FastClick
12. Deloitte (commissioned by Google) — Milliseconds Make Millions (2020)
13. Akamai — Spring 2017 State of Online Retail Performance Report
14. Google Research — Speed Matters (2009)
15. Riedl et al. — Technostress from a Neurobiological Perspective: System Breakdown Increases the Stress Hormone Cortisol in Computer Users (BISE, 2012)
16. TP-Link — Wi-Fi 6 (OFDMA)
17. Wikipedia — IEEE 802.11be (Wi-Fi 7)
18. MediaTek — Wi-Fi 7 Technology
19. Reviews.org — Cell Phone Usage Statistics
20. Nielsen Norman Group — Response Times: The 3 Important Limits
21. NVIDIA — GeForce NOW System Requirements

Additional sources consulted (not individually link-verified):

• Cloudflare “Introducing 0-RTT” (TLS 1.3 blog)
• Request Metrics “HTTP/3 Is Fast” benchmarks 2025
• Internet Society “Measuring HTTP/3 Real-World Performance”
• APNIC/RWTH Aachen QUIC head-of-line blocking study
• Wix engineering blog (HTTP/3 LCP measurements)
• Avallone et al., IEEE 2021 (OFDMA latency)
• Qualcomm / Wi-Fi Alliance OFDMA test results
• Liu et al., ACM SIGMETRICS 2023 (WiFi 6 OFDMA dense scenarios)
• IEEE 802.11ax / 802.11be specifications (BSS Coloring, preamble puncturing)
• Intel WiFi 7 MLO performance data
• Ericsson ConsumerLab neuroscience study 2016 (sample size undisclosed)
• Parks Associates connected device survey 2024