After adding a `middleware.ts` to a Next.js app, p95 TTFB rises on marketing pages that are fully prerendered at build time. Why does a prerendered page still pay for middleware, and how would you bring the cost down?

## Why static does not mean untouched It is tempting to reason that a page prerendered at build time is "just a file", and files do not run code. That is true of the *rendering*, not of the *request*. Next processes an incoming request in a fixed order: config-declared headers and redirects, then middleware, then rewrites, then filesystem routes — which is where `public/`, `_next/static` and your prerendered route output actually live — then dynamic routes and fallbacks. Middleware is upstream of that filesystem step. At the moment the matcher is consulted, the router has not yet decided that `/pricing` resolves to a prerendered document. It is a path. If the matcher accepts the path, the function runs, and only afterwards does the static response get served. Prerendering eliminated the render, and middleware reintroduced a per-request hop in front of it — which is exactly the shape of a TTFB regression that appears on the pages you were most confident about. This is not a flaw; it is the point of middleware. Being ahead of route resolution is what lets it rewrite or redirect before anything has resolved. The cost is that the privilege applies to every matched request. ## Diagnosing before fixing Three questions, in order. **What population is actually matched?** Read the matcher literally and enumerate what it lets through. A catch-all with no exclusions admits `/_next/static/*` chunks, `/_next/image` requests, `public/` files, API paths, and — the one people forget — the RSC payload requests that client-side navigation and `next/link` prefetching issue at the target route's own pathname. Those look exactly like page requests to a matcher. On a link-dense page, prefetching alone can multiply invocations well past page views. **How long does the function take?** Middleware is on the critical path of everything it matches. A network call inside it — a session lookup, a flag service, a geo API — adds its latency to every matched request, and its p99 becomes your p95 tail. Middleware that only reads the URL and a cookie is cheap; middleware that awaits I/O is a synchronous dependency in front of your whole site. **Where is the regression concentrated?** Compare TTFB on a matched path against an excluded one. If excluded paths are flat and matched paths moved together by a similar amount, you are looking at fixed per-invocation overhead rather than something specific to one route. ## The fixes, cheapest first **1. Exclude what can never need it.** Start from the deny-list shape and cut build output, the image optimizer, the favicon and static file extensions. This is pure win: those requests have no per-request logic worth running. **2. Narrow to route trees that need it.** If the concern applies only to the authenticated area, match that area explicitly and leave the marketing tree out of the matcher entirely. An allow-list is the strongest available lever because an unmatched request never loads the middleware module — no cold start, no execution, no per-invocation charge on hosts that meter it. The tradeoff to state deliberately: routes added later fall outside an allow-list silently, so it suits stable path sets and wants a test asserting the intended paths match. **3. Filter prefetches if they dominate.** A matcher entry can be an object with `source`, `has` and `missing` conditions, so a `missing` condition on the `next-router-prefetch` header keeps speculative navigation requests out of the function while still covering real ones. Worth reaching for only when measurement shows prefetch traffic is the driver. **4. Take work off the hot path.** Whatever remains matched should do URL-and-header-shaped work: read the path, read a cookie, decide, return. Anything requiring a round trip belongs where it can be scoped to the routes that need it and cached, rather than executed in front of the whole site. ## What not to do Do not "fix" it with an early `return` at the top of the function for paths you do not care about. It reads like scoping and is not: the module has already been loaded and invoked by the time that line runs, so you keep the invocation and its overhead and lose only the body. The matcher is the only mechanism that prevents the invocation itself. Also resist the instinct to make the page dynamic "since it's being touched anyway". The static output is still saving you the render; the middleware hop is a separate, additive cost, and removing prerendering makes the situation worse, not better. ## The sentence that shows seniority "Prerendering removes rendering work, not the request pipeline — middleware runs ahead of the filesystem, so the matcher, not the page's rendering mode, is what decides whether that page pays."