The Cartwright's Two Wheels: On the Opposing Spokes of Build-Time and Runtime Optimization

Every cartwright knows a wheel needs two opposing forces to be true: the outward push of the spokes, tensioned against the inward pull of the rim. Without this balance, the whole structure wobbles and fails under the first serious load. Lately, I’ve been thinking about our work in similar terms. We spend our days building for the web, a machine that must roll smoothly for every visitor, and our craft is defined by a similar tension—the push and pull between optimizing at build-time and optimizing at runtime.

On one side, we have the meticulous, pre-departure work of build-time optimization. This is the cartwright’s workshop, a controlled environment where we can shave every imperfection. Here, we minify CSS and JavaScript into dense, efficient bundles. We generate multiple, art-directed versions of a single image, carefully sized and compressed for their destined viewport. We inline critical CSS and preload key requests, attempting to chart the user’s entire journey before they’ve even taken a single step. This philosophy is one of prediction and preparation. It seeks to answer every possible question the browser might have before it has a chance to ask, aiming for a first impression that is as instantaneous as it is polished.

The other side is the unpredictable road itself: runtime. This is where our carefully laid plans meet reality—a user on a faltering 3G connection, a browser extension injecting a rogue script, a device with an unknown viewport we hadn’t perfectly anticipated. Runtime optimization is less about prediction and more about adaptation. It’s the logic of lazy-loading images only as they approach the viewport, of serving a tiny, sharp core font instantly while the more expressive typeface loads in the background. It’s the ingenuity of intersection observers and adaptive components that render only what is needed, precisely when it’s needed.

The friction, the true craft, lies not in choosing one wheel over the other, but in tensioning them correctly. A build process obsessed with pre-compiling every possible state can produce a cart so heavy with anticipation that it can barely move, its initial payload bloated with assets a user may never see. Conversely, a site that relies entirely on runtime cleverness can feel janky and uncertain, as the browser frantically assembles the experience piece by piece, leaving the user waiting at every turn.

The balance is the goal. It’s the build that produces lean, logical bundles, paired with a runtime strategy that is graceful and responsive. It’s knowing which critical path resources must be forged into the initial payload, and which can be fetched on-demand with intelligence and poise. Like a well-made wheel, the best digital experiences feel inevitable. They are both solid from the start and resilient to the bumps in the road, a seamless union of the cartwright’s foresight and the cart’s inherent flexibility. The journey is smooth because the opposing forces are, at last, in harmony.

Notes & further reading

A few pages I came back to while writing this: