Headless Migration for a High-Traffic News Portal
Let's Connect
Overview
What we built
A regional news portal kept falling over at exactly the moments its readers needed it most: breaking news. We rebuilt how its pages are built and served, and the crashes stopped.
In plain terms: the portal serves 800,000 visitors a month, but its old setup assembled every page from scratch each time a reader asked for it. On a quiet day that meant a wait of 3.2 seconds before the server even began responding. On a big news day, when everyone arrived at once, the servers simply could not keep up and the site went down, at precisely the time it had the most readers to win.
We changed the model so the hard work happens before the reader arrives. Articles are now generated in advance and served as ready-made pages from CDN edge nodes close to the audience, refreshed automatically whenever the newsroom updates a story. The wait for a response dropped from 3.2 seconds to 180 milliseconds, the portal sailed through two major breaking news events at 3x normal traffic with zero downtime, infrastructure costs fell by 55%, and a published story now reaches readers in under 60 seconds instead of 4 minutes.
The Problem
Crashing under breaking news
For a news portal, traffic does not arrive evenly. It arrives in spikes, driven by the stories that matter most, and this portal's architecture was at its weakest exactly then. Every page request was assembled on demand by the origin servers, so 800,000 monthly visitors translated into constant server work, and a breaking story multiplied that work faster than the machines could absorb it.
Readers felt the strain before the outages made it visible. Time To First Byte averaged 3.2 seconds, so browsers sat waiting before a single byte of the page arrived, and Core Web Vitals sat in the failing range, which weighs on search visibility for exactly the article pages that should be winning traffic. During spikes, slow turned into unavailable.
The crashes were the sharpest cost. Repeatedly, at the height of a breaking story, the portal went down while readers flooded in, sending them straight to competitors and undermining the newsroom's credibility at its most valuable moments. The team could keep adding servers, but scaling on-demand page assembly for spike traffic is an expensive race the architecture kept losing.
On-demand page assembly
Every request forced the origin servers to build the page from scratch, so both cost and fragility scaled directly with reader numbers.
Crashes during spikes
Breaking news multiplied traffic beyond what the servers could assemble in time, taking the portal offline at its highest-value moments.
Slow first response
Time To First Byte averaged 3.2 seconds, leaving readers staring at a blank tab before the page even began to arrive.
Failing Core Web Vitals
Google's page-experience measurements sat in the failing range, dragging on search visibility for the article pages the portal depends on for reach.
What it was costing them
Each spike carried the same bill: readers bounced to rival outlets mid-story, advertising went unserved while attention peaked, and the newsroom watched its biggest audiences of the year hit an error page. Between spikes, the portal paid for enough server capacity to survive the next surge, and still went down when the surge arrived.
The Solution
Headless Next.js edge rebuild
We migrated the portal to a headless architecture: the newsroom's content lives in Sanity CMS, a Next.js front end renders it, and a Node.js API layer connects the two. The decisive change was when pages get built. With Incremental Static Regeneration, article pages are generated ahead of time and regenerated in the background whenever a story changes.
Those pre-built pages are served from CDN edge nodes near the reader, so a traffic spike no longer multiplies server work: whether one reader or the whole region opens an article, the edge simply hands out the same ready-made page. The origin only works when content actually changes, which is why the infrastructure bill fell rather than rose.
The newsroom's workflow was strengthened alongside the plumbing. Editors publish in Sanity much as they did before, but a published or corrected story now flows through regeneration and out to the edge in under 60 seconds, instead of the 4 minutes the old stack needed, which matters most on the fast-moving stories that cause the spikes.
Key decisions
Pre-build pages, not requests
Incremental Static Regeneration turns each article into a ready-made page before readers ask for it, removing page assembly from the critical path entirely.
Serve from the edge
Article pages are delivered from CDN edge nodes close to the audience, so spikes are absorbed by the CDN rather than the origin servers.
Headless split of concerns
Sanity CMS holds the content, Next.js renders it and a Node.js API layer connects the two, so each part scales and fails independently.
Regenerate in the background
When an editor updates a story, the affected page is rebuilt behind the scenes and swapped in, so corrections ship without waiting on deployments.
Keep the newsroom workflow
Editors kept a familiar publish flow in the CMS; the architecture changed underneath them rather than asking the newsroom to change how it works.
Measurable Impact
What changed after launch
Time To First Byte fell from 3.2 seconds to 180 milliseconds, moving the portal from the failing range to genuinely fast, and the real test arrived quickly: two major breaking news events drove 3x normal traffic, and the portal served both with zero downtime. The pattern that had defined the old stack, biggest story equals broken site, was gone.
The economics improved along with the resilience. Because the origin no longer assembles a page per request, server infrastructure costs fell by 55% even as the portal became far better at absorbing spikes. Editorial gained speed too: publish-to-live time dropped from 4 minutes to under 60 seconds, so the newsroom can lead a breaking story rather than trail it.
Spike resilience
Repeated crashes during breaking news traffic
Zero downtime through two events at 3x normal traffic
First response
Time To First Byte averaging 3.2 seconds
First byte served in 180 milliseconds from the edge
Infrastructure spend
Paying for origin capacity that still fell over
Server infrastructure costs down by 55%
Publish to live
Stories taking 4 minutes to reach readers
Updates live in under 60 seconds
Headline results
Time To First Byte reduced from 3.2 seconds to 180 milliseconds
Zero downtime during two major breaking news events driving 3x normal traffic
Server infrastructure costs reduced by 55%
Editorial publish-to-live time reduced from 4 minutes to under 60 seconds
Ready to Build your Media & Publishing Business with Performance & Optimization
Ask Byte
Ask Byte
Typically replies instantly
just Now
Hi! I'm OrganByte's assistant. How can I help you today?
AI-generated content may be incorrect
