#performance

On 2 July 2019 a single new firewall rule took Cloudflare, and a large part of the web with it, offline for 27 minutes. Not an attack, not a hardware failure. How does one rule do that to every server at once?

Every service is healthy and the dashboard average looks great, yet support is full of customers saying the app is slow. Both are telling the truth.

A celebrity posts and a million people tap the heart in ten minutes, and every one of them sees a count that seems to keep up. One row with a number in it can't take that. So what does?

A green tick appears before you've stopped typing, and behind it is a list of a billion taken names. It isn't one clever database query.

A team rewriting its app in this month's framework to fix the speed, a search box whose effects set state that sets more state, and a marketing page that ships more JavaScript than a video game. None of them is fixed by switching tools.

One product-page endpoint, the same code, ten times more traffic, then ten times more again. Each step breaks something different, and the last one breaks something extra capacity can't fix.

A reusable fetch factory that infers request/response types from an OpenAPI schema and adds in-memory caching, retry with backoff, and AbortController support, no per-endpoint boilerplate, no `any`.

An endpoint that queries once per parent row instead of once per request looks fine with ten rows and falls over with ten thousand. Batch the per-row lookups into one query and the round trips disappear.

An App Router route is prerendered by default and silently turns dynamic the moment you read something request-specific. Knowing which bucket a route belongs in (and what forces it out) is the difference between an instant page and a server render on every hit.