Describe your app. Leave with a blueprint.

A traditional site runs in one data centre; a request from the other side of the world pays for every one of those thousands of miles, twice. A CDN fixed half of that by caching static files close to users. The edge goes further: it runs your code — the logic, the personalisation, the API calls — in hundreds of locations at once, so the computation itself happens near the person, not in a distant origin.

The practical consequence is that latency stops being about your server's speed and starts being about distance and cold starts. Edge runtimes are built to start in a millisecond or two, which is why they can afford to run per-request in a way a traditional container cannot. The trade is a smaller, stricter runtime: no long-running processes, tight limits, and a different mental model where every request is stateless and fast by default.

• Cache what's shared, compute what's personal. The edge lets you do both in the same request.
• State lives elsewhere — a database, a KV store, an object store — because edge functions are ephemeral by design.
• Measure from where users are, not from your laptop, or you'll optimise a problem you don't have.

Most sites don't need the most powerful option; they need the simplest one that fits the content. If a page is the same for everyone and changes rarely — a marketing page, docs, a portfolio — pre-render it to static HTML and serve it from cache. It will be faster, cheaper and harder to break than anything dynamic, because there is nothing to compute at request time.

Reach for server-side or edge rendering only when the page genuinely differs per request: a logged-in dashboard, search results, per-user pricing. And when you do, prefer to render at the edge for anything latency-sensitive, and reserve heavier server compute for the rare operations that truly need it. The failure mode to avoid is making everything dynamic 'just in case' — you inherit all the cost and fragility of dynamic rendering for pages that never needed it.

• Static by default, dynamic by exception. Every dynamic page is a page you now have to keep fast and up.
• Incremental regeneration lets mostly-static pages refresh on a schedule without a full rebuild.
• Hydration is not free — shipping a page as static HTML and adding interactivity selectively beats shipping a heavy app for a mostly-readable page.

The scariest deploys are the ones you can't reverse. The modern answer is atomic, immutable deploys: every build produces a complete, versioned snapshot of the site, and 'going live' is just pointing a pointer at a new snapshot. Because the old snapshot still exists, rolling back is instant — you move the pointer back — rather than a frantic re-deploy of yesterday's code under pressure.

The same machinery gives you preview deploys: every branch or pull request gets its own permanent URL built exactly as production would be. That turns 'it works on my machine' into 'here's the real thing, click it' — reviewers, clients and stakeholders see the actual build before it reaches users. Treat the preview URL as the unit of review, not the diff.

• Never hand-edit production. If a change isn't in the build, the next deploy silently erases it.
• Keep deploys small and frequent. Ten tiny deploys are far easier to debug than one big one.
• Roll back first, diagnose second. Restore service, then investigate calmly.

Almost every serious performance win comes down to serving something you already computed instead of computing it again. The art is in the cache key (what makes two requests 'the same') and the lifetime (how long a cached answer stays valid). Get the key wrong and you either serve stale personal data to the wrong person, or you cache so narrowly that nothing is ever reused.

The most useful pattern is stale-while-revalidate: serve the cached copy instantly, and refresh it in the background if it's getting old. Users get speed; the cache stays fresh without anyone waiting. Pair it with an explicit way to purge — when content genuinely changes, you invalidate exactly the affected keys rather than blowing away everything and hammering your origin.

• Cache the expensive, vary on the meaningful. Don't include tracking parameters in the cache key.
• Long TTL plus purge-on-change beats short TTL guessing — cache aggressively, invalidate precisely.
• Separate the shell from the data. Cache the layout hard, fetch the personal bits fresh.

A surprising share of breaches start with a secret committed to a repository or baked into client-side code. The rule is simple and absolute: secrets live in the platform's encrypted environment, never in your source, never in the browser bundle. If an API key ends up in the JavaScript a user downloads, treat it as public and rotate it immediately.

Distinguish build-time from run-time configuration. Build-time values get frozen into the output and are visible to anyone who inspects it — safe only for genuinely public things like a site URL. Run-time secrets are read on the server or at the edge, per request, and never reach the client. When a value must reach the browser, prefix it deliberately as public so you're making an explicit choice, not an accident.

• Anything prefixed 'public' is public. Say it out loud before you expose it.
• Rotate on suspicion, not on proof. Rotating a key is cheap; a leaked key is not.
• Least privilege for tokens — scope each key to exactly what it needs, so a leak is contained.

Averages lie. A site with a great average load time can still be miserable for a quarter of its users, and those are the ones who leave. Judge performance by the slow tail — the 75th and 95th percentiles — because that's the experience of real people on real networks and mid-range phones, not the experience of you on office fibre.

Track the metrics that map to human perception: how quickly the first content appears, how quickly the main content is usable, and how stable the layout is as it loads (nothing worse than tapping a button that jumps). Synthetic tests in a lab are useful for catching regressions, but real-user measurement from actual visitors is the ground truth. Optimise for the number that changes what a person feels, and ignore the vanity metrics that don't.

• Watch the 95th percentile. If it's bad, someone's day is bad.
• Layout shift is a trust tax — reserve space for images and embeds up front.
• Ship less JavaScript. It's the most reliable way to make a page feel instant.