Anatomy of a Publish: Timing Every Hop Between the Keyboard and the Reader
Photo: Ana Las Heras, CC BY-SA 4.0, via Wikimedia Commons
Publish button, pressed. Somewhere, a reader will see this story. The gap between those two events is treated as a black box by most editorial organizations — a matter for the platform team, invisible to the people whose bylines are on the line. We decided to open the box.
What follows is a field log from instrumenting a single standard article — roughly 1,200 words, three images, one embedded video — through a representative mid-market publishing stack of the kind used by hundreds of regional US news organizations. Every hop was timed independently. The total will not shock anyone who has audited a delivery pipeline before. The distribution of the delay might.
Hop One: The CMS Itself
From the moment publish is clicked to the moment the content API reflects the change: 8.4 seconds. This is the delay almost nobody measures, because it happens before the content technically exists on the public web. It includes database commits, revision creation, and — the largest single contributor — a WordPress-style search index rebuild that ran synchronously.
Editorial teams experience this as the spinner that hangs after publish. Readers never see it, but it establishes a baseline: no downstream optimization matters until this clock stops.
Hop Two: Transformation and Build
Our test stack rendered the article through a static site generator with an incremental build. The build itself took 41 seconds — but the deploy pipeline queued it behind two other builds, adding 2 minutes and 12 seconds of pure waiting. This is a pattern worth underlining: in static architectures, the dominant delay is frequently queue time, not compute time. Build minutes are cheap; build concurrency is not, and publishers who skimp on it publish slowly at exactly the moments they publish most.
The image pipeline added its own wrinkle. Hero images were transformed into six responsive variants, pushing total time-to-live-URL for the lead image past 90 seconds after the article itself was live. For that window, the page rendered with a lazy placeholder — functional, but not the experience anyone designed.
Hop Three: Propagation to the Edge
Once deployed, the new article URL did not exist at any edge node. First request: cache miss, 610 milliseconds to first byte, origin fetch from Virginia to a reader in Ohio. Second request from the same region: 84 milliseconds. Third region over — a reader in Portland: another miss, another origin trip.
This is the cold cache dynamic in miniature, and it repeats across every edge location until traffic or pre-warming fills the gaps. Publishers using aggressive HTML caching without a pre-population mechanism are, in effect, asking their first readers in each region to fund the performance of everyone who follows.
Hop Four: The Browser
Rendered on a mid-tier Android device over a throttled 4G connection — a reasonable stand for a meaningful share of American mobile readers — the page reached fully interactive in 3.8 seconds. The largest culprits were not the article at all but third-party tags: a consent management platform, an analytics bundle, and an ad wrapper that each blocked parsing. The article's own payload, HTML plus text-optimized images, accounted for under a third of total load time.
Where the Seconds Actually Go
Aggregated, the timeline looked like this: 8 seconds in the CMS, roughly 3 minutes in build queue and transformation, under 1 second for the first edge fetch, and 3.8 seconds to interactivity on a representative device. Of that entire journey, the portion a CDN vendor would traditionally claim credit for — edge delivery — was among the smallest contributors.
A Checklist for Your Own Audit
Any editorial organization can run a version of this exercise in an afternoon. Time the interval between publish and the content API reflecting the change. Check whether builds queue, and what concurrency you are paying for. Request a fresh URL from three geographically separated proxies and record first-byte times for each. Run the live page through a throttled mobile profile and attribute load time by request origin — first-party versus third-party.
The point is not to assign blame to any single vendor. It is that 'instant publishing' is a claim about a chain, and a chain is only as fast as its slowest unexamined link. Most publishers we talk to have measured the last link and assumed the rest.
