Dev Server vs Production

A meta-framework gives you two ways to run the same application, and they are tuned for opposite goals. The **development server** exists to shorten the distance between typing a character and seeing the result. The **built output** exists to answer a request as cheaply as the framework can arrange. Nearly every surprise in the gap between them follows from that single divergence of purpose. ## Compiled when something asks for it In development the server holds your source and compiles only what a request actually needs. The first request for a route triggers compilation of that route and the modules it pulls in; later requests reuse the compiled result until a file it depends on changes, at which point the affected part is compiled again. Two visible consequences follow: - a large application starts almost immediately, because nothing has been compiled yet; - the **first** visit to each route pauses briefly, and that pause says nothing about how fast the route is — it is compile time, not render time. The built output never does this. Everything was compiled once, by the build, before any request existed. A request executes already-compiled code, or is answered without executing your code at all. ## Rendered again on every request The second difference is that development skips prerendering. A route that the build would render once and store as a document is, in development, rendered per request the way a fully dynamic route is. Your loader or data function runs again, your components render again, and the HTML is produced again. That is why an edit to a page that is *prerendered in production* still appears instantly while you are working on it. The cost is that the **classification** a build performs — deciding which routes can be rendered ahead of time and which must run per request — is simply not exercised in development. You cannot look at a development response and tell which side of that line a route will land on. ## The cache tiers are off The third difference is caching. A deployed meta-framework typically layers several caches: a stored prerendered document, a cached result for a data fetch, a cached rendered fragment, and a client-side store of already-visited routes. Frameworks differ in how many of these they have and what each is called, but in development they are disabled or reduced to near-nothing, precisely so that what you see is what your code currently does. The consequence is uncomfortable and worth stating plainly: **a page that shows fresh data in development is evidence of nothing.** It is fresh because caching is off, not because your revalidation is right. ## What that hides | Behaviour that matters in production | What the development server shows instead | |---|---| | Whether a route is prerendered or rendered per request | Everything rendered per request | | How stale a response may be before it is refreshed | Always current | | Whether regeneration of a stored page after a window, or on demand, actually works | Never exercised | | Which requests are answered without running your code | Your code runs every time | | Compiled size and what ships to the browser | An unoptimised development build | | First-visit latency | Compile time mixed into the measurement | ## How to read a development observation honestly Development is authoritative about one thing: **what your code does when it runs**. Logic, markup, styling, and the shape of the data are all faithfully represented. Treat everything about *when* and *how often* your code runs as untested until you run the built output. Practically, that means: 1. Debug behaviour in development — it is the fastest loop you will get. 2. Verify freshness, reuse, classification and payload size by building and running the build, not by watching the development server. 3. Do not tune a cache window against the development server; it will confirm whatever you already believe. A useful habit is to treat the development server as a **draft renderer**: correct about content, deliberately wrong about economics. Once that distinction is explicit in a team's head, the whole class of "it worked locally" surprises shrinks to the smaller set that really does need the deployed target to reproduce.