The discipline of building for a 56k connection

I still remember the sound. That digital handshake of a 56k modem—a screeching, hopeful cascade of noise that meant the internet was about to arrive. When it did, it came one pixelated line at a time. That experience, of waiting, of watching a page painstakingly draw itself, is a ghost that still haunts how I design systems today.

My connection is fiber now, and 5G is in my pocket. The raw constraint of bandwidth has, for many, seemingly vanished. Yet the discipline born from that scarcity is more relevant than ever. The constraints just changed their names: mobile data caps, flaky coffee shop Wi-Fi, high cloud egress fees, and the latency cost of a thousand microservice calls. Building for 56k was never just about speed; it was about respect for the connection and the user at the other end of it.

The Physics of the Wire

When every byte counted, you thought differently. I remember shipping an early e-commerce site where the product images were the entire experience. Shaving 20kb off each JPEG wasn't an academic exercise; it was the difference between a three-second load and an eight-second load. I could see the direct impact in the server logs as abandoned sessions. This wasn't theory; it was the physics of the business. This mindset follows the foundational rules of web performance, many first codified by pioneers like Steve Souders, which focused on the user's perception of speed above all else.

The best-engineered sites rendered progressively. The HTML arrived first, so you could at least see text and layout. Images filled in later. This is the direct ancestor of modern performance metrics like Largest Contentful Paint (LCP), which, as documented on Google's web.dev, measures when the main content of a page has likely loaded. It’s about delivering value immediately, not making a user stare at a blank screen.

From Page Weight to API Payloads

The "bytes over the wire" problem didn't go away when applications moved to complex client-side apps and microservices. It just moved deeper into the stack. A bloated JSON response from an API is the new un-optimized JPEG.

I've seen systems where a mobile app, needing only a user's name, would call an endpoint that returned the entire multi-kilobyte user object, complete with join dates and purchase history. On a great connection, it's unnoticeable. On a cellular network dropping to 3G in a train tunnel, the app hangs. The system, though technically "working," has failed the user. This is the exact problem technologies like GraphQL were designed to solve. As the official specification makes clear, its core idea—letting the client ask for exactly the data it needs and no more—is pure 56k thinking.

The Velocity Counter-Argument

The common objection is that this is premature optimization. Developer time is expensive, the argument goes, and far more valuable than a few kilobytes on a fast connection. Better to ship features quickly and clean up the performance later. This holds true for a prototype. It falls apart at enterprise scale.

At scale, that small, bloated payload is multiplied by millions of requests, creating real, compounding costs in egress fees, server load, and battery drain on user devices. Performance isn't a feature you add later; it's a foundational architectural concern. Performance debt, once incurred, is incredibly expensive to pay down.

Token Counts Are the New Baud Rate

Now, we are building systems where software, data, and AI work together. A new "wire" has appeared with a new set of constraints: the context window of a Large Language Model. Every call to an LLM is a payload exchange. The "weight" of that transaction is measured in tokens, and tokens cost both money and latency.

An agentic system that sends verbose, unfocused prompts is the 2026 equivalent of a website using uncompressed BMP images. It’s wasteful, slow, and expensive. The 56k discipline applies directly:

• Prompt engineering is payload optimization. Can the desired output be achieved with a 500-token prompt instead of 2000? Strip the filler and send only the essential context.
• Deterministic steps are your cache. Don't ask an LLM to parse a date or calculate a sum. Use simple, free, deterministic code for predictable tasks. This is the modern version of serving a static HTML shell before loading dynamic assets.
• RAG is progressive loading. Retrieval-Augmented Generation is a performance pattern. Instead of stuffing a massive document into a prompt, you retrieve only the most relevant chunks. You send a smaller, targeted payload to get a better, faster, cheaper result.

A Discipline of Durability

This isn't about refusing to use powerful tools. It’s about craftsmanship. It’s about building things that are robust, durable, and considerate of reality. The network is not reliable, latency is not zero, and compute is not free. These are not edge cases; they are the normal operating conditions of any system at scale.

The ghost of the modem isn't here to scare us. It’s a mentor. It reminds us that constraints breed creativity and that the most elegant systems are often the most efficient. They are the ones that hold up under pressure. They are the ones that just work, even at 3am, on a bad connection, when everything else is failing.