Slow internet: make a 100 kbit/s connection usable
A low-bandwidth field guide: measure the link, budget bytes, keep useful work local and make pages survive retries.
A slow link changes the order of work. Before optimizing an app or buying another router, determine whether the limit is throughput, latency, loss, a data cap, or an unstable radio connection. Each calls for a different fix.
About 12.5 kB/s. A 1 MiB transfer takes roughly 84 seconds before overhead.
About 800 kbit/s. The same transfer takes roughly 10.5 seconds before overhead.
Many tiny requests can feel slower than one larger transfer even when the byte total is unchanged.
Measure the bottleneck you actually have
Record several samples at different times: downstream and upstream throughput, round-trip latency, packet loss, and whether the connection drops. Check one wired device when possible, so a weak Wi-Fi link is not mistaken for a mobile-network problem. Keep the units with every result: bits and bytes differ by a factor of eight.
A speed-test headline cannot tell you how a page behaves under loss or congestion. Compare a small text page, a large download, and a page with many third-party requests. If only the last is painful, reduce requests and script work before chasing raw bandwidth.
Put the first useful answer in the first transfer
For publishers, send meaningful HTML without requiring a client-side bundle to render the article. Compress text, set sensible cache headers for versioned assets, use responsive images, and lazy-load images below the fold. Reserve image dimensions so a late image does not move the text. A site can have a tiny homepage yet still waste a constrained connection through analytics, fonts, autoplay video and repeated API calls.
Choose a page-weight budget from the user's connection, not from a desktop broadband test. At 100 kbit/s, every extra 100 kB can cost around eight seconds in the ideal case. A 50 kB article body is therefore more useful than a decorative megabyte before the first paragraph.
Keep work local and make failure resumable
For readers and operators, prefer offline-capable documentation, a local copy of frequently used references, and resumable downloads where the server supports range requests. Schedule large updates for a reliable connection. Do not depend on an online-only editor for work that must survive a drop.
When a transfer fails, first identify which layer failed: radio, DNS, TLS, server response or application. A second attempt should not duplicate a form submission or destroy a partly downloaded file. Test the recovery path deliberately.
Throttle a browser to an appropriately slow profile and load your own article from a cold cache. Record transferred bytes, request count, time to readable text and the largest blocking resource. Repeat with a warm cache. The difference shows whether caching helps your real visitors.
What the sources contributed
An earlier writer described living with an unstable, very slow cellular connection. This article uses that constraint as a design question. It does not repeat their personal circumstances or claim their measurements as ours.
Sources & scope
These sources support the technical principles above. Commands and compatibility can change; verify the current version before changing a machine.
This is this website. Its articles are original work inspired by the domain's technical history; we are not the former author. Meet the author.
Give a proposed dependency its own byte-budget line
Use a complete cold-load ledger before approving an extra dependency. This is a decimal-unit calculation, not a measured browser benchmark.
- Count each transferred resource once: HTML 50 kB, stylesheet 20 kB and illustration 30 kB in this invented page. The cold total is 100 kB.
- Add the proposed dependency and any resources it requests. A 200 kB addition raises this example to 300 kB; do not report only the small script that initiates a larger download.
- Keep throughput arithmetic separate from observed load time. At an ideal 100 kbit/s, 100 kB × 8 ÷ 100 kbit/s = 8 seconds; 300 kB takes 24 seconds before latency, overhead or loss.
Decision record: the added feature has not justified an extra ideal 16 seconds. Keep it out of the initial reading path while checking whether an ordinary link or deferred optional action solves the task. This is a proposed trade-off, not proof of a performance improvement.
Ledger: resource __; transferred bytes __; cold/warm cache state __; initial-reading dependency __; optional alternative __; measured result __. Cached resources can change a later load, but freshness and validation must be observed rather than assumed. MDN explains lazy loading; it does not certify this fictional page's timings.
Source: developer.mozilla.org.