The Editor's First Galleys: On the Unseen Strain of a Pre-Rendered Web Page
I remember the first time I held a galley proof in my hands. It was during an internship at a small, fiercely independent publisher, a place that still smelled of old paper and fresh ink. My task was to read the long, narrow columns of type, printed on cheap, translucent paper, looking for errors before the final press run. The text was set. The layout was fixed. It was a perfect, unchangeable snapshot of a book that was almost, but not quite, real. There was a tangible strain to it, a tension born of the immense effort required to make a single change. To correct a typo meant resetting a line, which might alter the spacing of a paragraph, which could ripple through the entire chapter. The pre-rendered page was a high-stakes commitment, a fragile finality.
Today, as a developer, I see the same tension in the modern obsession with pre-rendering and static sites. We have new tools, of course—entire forests of build tools and generators that promise the ultimate in performance by doing all the hard work upfront. The logic is irresistible: serve a page that is already complete, pristine, and fast. No waiting for a database, no assembling components on the fly. It’s the galley proof, baked into a distributable PDF. The Core Web Vitals sing. The Lighthouse score shines. The page appears, fully formed, like Athena from the head of Zeus.
But the strain is still there; it has just shifted from the printing press to the build server. That beautifully static page, which loads in a flash for a user, represents a moment in time. It's a snapshot of your data, your content, your entire application state, frozen at the precise second the build command finished. What happens when a product goes out of stock ten minutes after a deployment? Or when a critical typo is discovered in the hero text? Or, more subtly, when a user-specific piece of content needs to be displayed? The promise of instant performance is suddenly weighed against the cost of invalidation.
This is the editor’s dilemma in a new guise. We are trading the dynamic slowness of a page that *can* adapt, for the static speed of a page that *cannot*. The build process becomes our printing press, and a site rebuild is our new press run—a heavy, resource-intensive operation that recreates the entire work from scratch. The strain is no longer on the user’s browser at the moment of request, but it’s distributed across our infrastructure and our processes. It’s a debt of immediacy, the hidden cost of that perfect, instantaneous First Contentful Paint.
The craft, I’ve learned, lies not in choosing one extreme over the other, but in understanding the nature of the commitment. Just as a good editor knows which changes are worth resetting a chapter for, a good developer understands which parts of a page can be pre-rendered with impunity and which must retain a thread of dynamism. It’s about building with an awareness of the strain, designing systems that embrace the speed of the static where it serves the user, while leaving room for the flexibility of the live where the real world demands it. The goal is not a perfect, frozen galley, but a living document that respects both the user’s time and the inevitable flux of the truth it aims to represent.
Notes & further reading
A few pages I came back to while writing this: