A case study
Coldstart 2024
Moving a newsroom's rendering to the edge, so speed peaks with the traffic.
- In one line
- Edge rendering platform for a news publisher
- My role
- Platform engineer — edge architecture, cache strategy, migration
- Timeline
- 6 months · 2023–2024
- Team
- 3 engineers working with the publisher's newsroom platform team
- Built with
- Cloudflare Workers, Astro, R2, KV
Coldstart moved a national publisher's page rendering off a central origin and onto the edge. Pages are assembled close to the reader and served from cache that the newsroom can trust, so the site gets faster exactly when a breaking story sends traffic through the roof.
Where it started
The situation
During traffic spikes — the moments that matter most for a news site — pages took four seconds to render at the origin. Caching was configured by hand, frequently stale, and just as frequently serving readers content that had already been corrected.
The constraint
A newsroom publishes corrections and retractions that must go live immediately. Aggressive caching is easy; aggressive caching that can be purged precisely and instantly is the actual problem. Editorial trust in the cache was non-negotiable.
How it was built
Rendering at the edge
Pages render in Cloudflare Workers geographically near the reader, using Astro's server output. Assets and rendered fragments live in R2 and KV, so a request in Sydney is served from Sydney instead of round-tripping to a single origin region.
Tag-based cache invalidation
Every rendered page carries content tags (article ID, section, author). A correction publishes a purge for exactly the affected tags, so a fix propagates in under a second without flushing the whole cache — the newsroom got instant corrections and the site kept its hit rate.
Stale-while-revalidate as the default
Readers are served a cached page immediately while a fresh render happens in the background. Under a traffic spike this collapses origin load to a trickle, which is what turned the old four-second worst case into a sub-second common case.
Cost as a measured constraint
Edge compute and storage were tracked against the previous origin bill from day one. Serving from cache rather than recomputing every request is what drove infrastructure cost down by more than a third while the site got faster.
What it changed
- p95 load time, worldwide
- 600 ms
- Worst case under spike
- 4s → <1s
- Infrastructure cost
- −38%
- Correction propagation
- <1s
Looking back
Tag-based invalidation was the piece that earned the newsroom's trust — once editors saw a correction go live instantly, they stopped fighting the cache and started relying on it. The thing I underestimated was observability at the edge: distributed rendering is wonderful until something is slow in one region, and I'd wire per-colo tracing in on day one next time rather than adding it under pressure.