Number Research
← Back to Explore
Information Technology Web Development Rendering Strategies and Web Performance

Every Kilobyte of JavaScript Is a Bill Paid on a Stranger's Phone

Google's switch to Interaction to Next Paint quietly settled the SSR-vs-SSG-vs-CSR debate — and demoted the single-page app to a deliberate exception.

S.J. Nam 6 min read
Every Kilobyte of JavaScript Is a Bill Paid on a Stranger's Phone

On March 12, 2024, Google changed the definition of "fast." That was the day Interaction to Next Paint — INP — became an official Core Web Vital, retiring First Input Delay after years of service. The shift sounds like bookkeeping. It was not. FID mostly measured the delay before a page started responding to your first tap; INP measures how sluggish a page feels across the whole visit, capturing the lag between clicking and actually seeing something happen. And the single biggest cause of that lag is JavaScript running on the main thread of the user's device.

Read that again, because it quietly settled an argument the web development world has been having for a decade. The rendering-strategy debate — server-side rendering versus static generation versus client-side rendering — was always framed as a question of when your HTML gets built. INP reframed it as a question of how much work you shove onto the phone in someone's pocket. By that measure, the strategy that dominated the 2010s is now the one with the most to answer for.

The Trichotomy Everyone Still Argues Was Already Dissolved

Here is the uncomfortable thing about "SSR vs SSG vs CSR: which is best?" It is the wrong question, and it has been the wrong question since roughly mid-2023. The frameworks that most engineers actually use stopped treating rendering as a page-level switch. They pushed it down to the component.

The pivot point was React Server Components. When Next.js shipped its App Router as stable in version 13.4 in May 2023, it made a genuinely strange idea the default: some components render only on the server, send their output as a serialized description to the browser, and ship zero JavaScript to run themselves. Other components in the very same page remain interactive client components. The page is no longer "an SSR page" or "a CSR page." It is a tree, and every branch of that tree can be rendered in a different place.

So the honest 2026 answer to "which rendering strategy is best" is not SSR, not SSG, not CSR. It is: all three, in the same route, chosen per component. The teams still trying to pick one globally are optimizing a decision their tooling already deleted. That is not a hedge. It is the actual state of the art, and treating it as a cop-out is how you end up shipping a slow app for reasons that felt principled at the time.

Static Is Not Retro. It Is Winning Under a New Name.

If the framing has changed, so has the scoreboard. The most counterintuitive development is that static generation — the strategy people wrote off as fine-for-blogs-only — is having its best moment ever, and it's because of a technique designed to rescue it from its own limitation.

Static's eternal weakness was the all-or-nothing bargain: pre-render the whole page at build time and it flies, but the instant one part needs to be personalized — a cart count, a logged-in name, a price that changes hourly — the entire page had to fall back to being rendered per-request. Partial Prerendering, which Next.js introduced with version 14 in late 2023, breaks that bargain. It serves a static shell instantly from the edge — the header, the layout, the product description that never changes — while the genuinely dynamic holes stream in from the server a beat later, inside the same response.

The result is a page that starts as SSG and finishes as SSR without the developer drawing a line between them. Notably, Next.js has kept Partial Prerendering behind an experimental flag well into its version 15 releases, which tells you something the marketing does not: the industry's most influential framework thinks the merger of static and dynamic is the future but isn't yet willing to sign the warranty. That caution is the most honest signal in the whole space.

The Case Against the Strategy That Built the Modern Web

Which brings us to client-side rendering, and to a claim a generic explainer will not make: pure CSR is now the default wrong answer, and defending it requires a specific excuse rather than a general one.

The single-page application won the 2010s for a real reason. Ship an empty HTML shell, let JavaScript fetch data and build the interface in the browser, and you get app-like transitions and a clean separation between a "backend" and a "frontend." The cost was hidden in a place nobody measured carefully: the user's device had to download, parse, and execute a large bundle before anything useful appeared, and then keep executing it on every interaction. When the dominant metric was First Input Delay, that cost was easy to launder, because FID forgave everything after the first tap.

INP does not forgive. Its "good" threshold is a response within 200 milliseconds, and it looks at your worst interactions, not your first one. A CSR-heavy app that hydrates a megabyte of JavaScript and then re-runs slices of it every time you type in a search box is exactly the profile INP was built to penalize. The metric didn't change what those apps do; it changed whether Google — and, through search rankings and user patience, your revenue — notices.

None of this means CSR is dead. A Figma-style canvas, a spreadsheet, a trading terminal, a drawing tool — anything where the browser is the application rather than a delivery mechanism for content — should absolutely live on the client, and forcing it through a server would be malpractice. The point is narrower and sharper: CSR has been demoted from a default architecture to a deliberate exception you should be able to justify in one sentence. "It's a highly interactive tool where the network round-trip would ruin the experience" is a good sentence. "It's what our starter template did" is not.

What "Best" Actually Means When You Stop Picking Sides

So the question worth asking in 2026 is not which acronym wins. It is: for each thing on this page, where should the work happen, and who pays for it? Content that is the same for everyone should be static and travel from the edge, computed once. Content that is personal or fresh should be rendered on the server per request and streamed into the static shell. Interactivity that genuinely needs to feel instantaneous and local should be the client's job — and nothing else should be.

That framework quietly kills the comfortable idea that there is a house style you can adopt and stop thinking about. The frameworks didn't hand engineers a winner. They handed them a scalpel and removed the excuse for using a hammer. The teams that will feel fast in 2026 are the ones who accepted that the rendering decision is now made dozens of times per page — and that every kilobyte of JavaScript they send is a bill, payable on a stranger's phone, that INP will read aloud.

References