The Bandwidth Sniffer
The same product, honest about the network it's actually on.
The incident
The redesign looked beautiful on office fiber. In the field, the 4MB hero image took 80 seconds on a rural connection, and the page was blank until it landed. Analytics later showed what that meant: users on slow networks weren't converting worse — they were leaving before the product existed.
Why the obvious approach fails
One-size-fits-all asset delivery quietly optimizes for the network your team has, not the networks your users have. Compressing everything punishes the fiber user with needless quality loss; serving full fidelity punishes the 2G user with an unusable page. The information needed to do better is available at runtime — effective connection type, observed throughput, the OS's own data-saver flag — but most applications never ask. Adaptation isn't a nice-to-have for the 'next billion users' market; it's the difference between having those users and not.
The standard
- The client estimates effective bandwidth passively (connection API plus observed throughput) and sends it with requests.
- Asset fidelity adapts by tier: full-quality media on fast links; compressed images and click-to-play video on slow ones.
- OS-level data-saver settings are detected and respected automatically.
- The critical rendering path is protected regardless of tier: the page is usable before any heavy asset arrives.
- Experience is measured per network tier — page-usable time on 2G is a tracked metric, not an unknown.
How Cortex validates it
At plan time
consumer-facing blueprints declare their fidelity tiers and the slow-network experience explicitly.
At validation
assert: asset_response == f(effective_connection)assert: data_saver_flag → reduced_payloadassert: page_usable(2g_profile) < declared_budgetAssertion syntax is illustrative.
At review
the approver sees the throttled-profile run: the same page loaded on fiber, 4G, and 2G profiles, with payload sizes and usable-time per tier.