Skip to content
All posts
PerformanceEdgeArchitectureCloudflare

What moving to the edge taught me about performance

Three hard-won lessons from moving a product's front end to a global CDN: measure first, cache aggressively, and design for the cache miss.

KSKavin SmithMarch 14, 20262 min read

Last year I moved a client's marketing site + docs from a single Node server to static files on Cloudflare's CDN. The headline numbers were great — time-to-first-byte dropped from ~300 ms to ~40 ms globally — but the real lessons were about discipline, not tooling.

1. Measure before you move

I benchmarked the old site from three regions for a week first. Some "obvious" optimizations (a new framework, code splitting) turned out to be noise; the actual problem was round-trips, not payload.

You can't optimize what you haven't measured. Baseline first, always.

2. The cache hit is easy. Design for the miss.

Serving cached HTML is trivial — the CDN does it. The interesting engineering is the first request from a new region, or a cache purge gone wrong. Architect so a cache miss is still fast:

  • Prerender everything that can be prerendered
  • Keep per-page JS small
  • Make assets immutable with content hashes

3. Edge functions are for the 5% that must be dynamic

Forms, auth callbacks, previews — put those in tiny edge functions and keep everything else static. This keeps the "fast by default" property intact: dynamic work is opt-in, isolated, and easy to reason about.

The numbers that matter

MetricBefore (server)After (edge)
TTFB (US East)289 ms38 ms
TTFB (Sydney)640 ms41 ms
99th pct load2.1 s0.9 s

That last row is the one nobody sees in a marketing demo but everybody feels in real life. Slow tail latency is what makes a site feel "slow" even when the median looks fine.

Move to the edge — but measure first, and treat the cache as a design surface, not an afterthought.