All posts

Engineering

From 5s to 0s: solving the cold boot problem

·4 min read

Five seconds of nothing

The first visitor of the day always paid.

A parent checks the school website on a phone, on the way to drop-off. They tap the link and nothing happens for five seconds. That was the reality at the Freie Evangelische Schule Kirchheim: the legacy platform rendered every page on demand, on cheap shared hosting, and the server slept between requests. Waking it meant connecting to the database, fetching content, and rendering HTML before the first byte went out.

The time to first byte on a cold request was close to five seconds. For a site whose whole job is answering small questions quickly, that is a broken front door.

Why it matters

A school website has traffic spikes in the morning and silence at night. An architecture that sleeps when idle punishes exactly the visitor who arrives first with the most urgent question.

The diagnosis

Rendering on demand was the wrong default.

The content changes a few times a day. The pages were being rendered thousands of times a day. That mismatch was the entire problem: the expensive work happened per request instead of per change.

Time to first byte, before and after

Legacy (cold)5200ms
Legacy (warm)800ms
Next.js ISR50ms

The architecture

Render per change, not per request.

The rebuilt platform uses Next.js with incremental static regeneration. Every visitor is served a static HTML file straight from the edge cache. When the cached copy is older than the revalidation window, Next.js regenerates the page in the background and the next visitor gets the fresh one. The database sits entirely behind the cache; no visitor ever waits on a query.

app/news/page.tsxtypescript
// Revalidate at most once per minute
export const revalidate = 60;

export default async function NewsPage() {
  // Runs on the server, in the background.
  // No visitor ever waits for this query.
  const news = await db.news.findMany({
    orderBy: { date: 'desc' },
    take: 10,
  });
  
  return <NewsGrid items={news} />;
}

What it saved

Speed and cost come from the same decision.

Rendering per change instead of per request collapses the load. A thousand visitors in one minute used to mean a thousand database round-trips; now they can mean one. The same change that removed the cold boot cut the infrastructure bill.

0s

Cold boot time

Down from 5 seconds

-60%

Infrastructure cost

Per year

100

Lighthouse performance

Core Web Vitals

The difference is night and day. Information is now instant, and we no longer worry about the site crashing during registration week.
Feedback from the FESK administration

The full story

The website was chapter one. The case study covers the infrastructure and the Atrium pilot that followed.

Read the case study