Should we design for iffy internet?

Original Article ↗ Hacker News Discussion ↗

Many developers build web and mobile apps assuming fast, reliable broadband, but commenters argue that real-world connectivity is often slow, congested, high-latency, or intermittently unavailable — even in wealthy countries and big cities. They highlight how this breaks common apps and sites in trains, tunnels, rural areas, crowded venues, planes, and power outages, and point to products like WhatsApp, mosh, and offline‑first PWAs as better models. The prevailing view is that designing for low bandwidth, high latency, and dropped connections — via smaller payloads, fewer round trips, caching, and offline capability — improves usability for everyone and is essential for resilience, not just for a "long tail" of edge cases.

Consensus: Yes, Design for Iffy Internet

  • Many commenters say you should assume bad or variable connectivity by default; anyone with good internet just has an even better experience.
  • This is likened to designing for low‑end hardware: it improves UX for everyone, not just edge cases.

Intermittent vs Slow Connections

  • Several distinguish “slow” from “intermittent”: slow links are tolerable, dropping connections is qualitatively worse and requires different design.
  • Examples: rural DSL, overloaded LTE/5G, satellite and in‑flight Wi‑Fi where connections flap or packet loss spikes.

Mobile, Wi‑Fi, and Real-World Usage

  • Even users with gigabit at home are often on trains, planes, subways, in basements, crowded venues, or power outages with overloaded cell towers.
  • Home Wi‑Fi quality and congestion often negate fast last‑mile links; many people are on cheap/throttled data plans.

Good and Bad App/Web Behaviors

  • Praised: WhatsApp, mosh, some OpenAI API experiences, well‑built PWAs and offline‑first/local‑first apps.
  • Criticized: Spotify, Apple Music, Google Maps, NYT games, many Electron/SPA apps that hang on “technically online” but useless connections; lazy‑loaded content that never fetched before going offline.
  • Common complaints: non‑resumable downloads (e.g., large git clones), apps blocking on network before showing cached data, UIs that become irrecoverably stuck.

Technical Strategies Proposed

  • Local/offline‑first design: cache data, show it instantly, sync in background, retry transparently.
  • Server‑rendered pages or one‑round‑trip APIs; minimize serial request waterfalls and payload sizes.
  • Handle timeouts, partial downloads, and range requests; tolerate packet loss.
  • Use tools (browser throttling, tc‑netem, toxiproxy, mobile emulators) to simulate latency, loss, and flakiness.

Trade-offs, Audience, and Ethics

  • Debate over “long tail” users: some argue excluding users with weak devices/links is bad business or morally wrong; others say targeting specific segments is legitimate.
  • General agreement that gratuitous bloat, ad/analytics payloads, and “always online” assumptions are poor design unless truly required.

Infrastructure Reality

  • Many anecdotes of poor or unstable broadband in rural US, Canada, UK, Germany, and elsewhere despite optimistic maps.
  • Starlink is seen as a major improvement over legacy satellite but still has noticeable brief drops and slowdowns, so robustness still matters.