Stop Answering "CSR or SSR?" Like It Is a Loyalty Oath

Stop Answering "CSR or SSR?" Like It Is a Loyalty Oath

"Which do you prefer, CSR or SSR?" The interviewer asks a decision question, and half the candidates answer like they were asked about their favorite football club. SSR people want to server-render the 404 page. CSR people ship a blank div, a spinner, and a prayer. Static fans are pre-rendering the admin dashboard that three employees use.

Watch the 40-second version first: CSR vs SSR vs Static: Pick Wrong, Fail the Interview

The interviewer is not testing your trivia

They are not checking whether you can recite what hydration is. They are checking whether you can decide with trade-offs. "CSR or SSR" has no correct answer. The wrong answer is picking one for the whole app and defending it like a thesis.

The right instinct is smaller than people think: choose per route, not per framework. Your marketing site and your logged-in dashboard have nothing in common except the repository. One wants instant first paint for strangers on slow phones. The other wants a rich workspace for users who already logged in. Same rendering strategy for both is like giving a fish and a bicycle the same fuel.

The non-obvious part: you are buying operations, not pixels

Everyone talks about first paint like rendering is a graphics decision. It is an operations decision wearing a graphics costume.

Pick SSR and you now own a server. Not "the cloud handles it." You. Cold starts at 3am, cache invalidation for data that changes every minute, a Node process that falls over the week you go on vacation. Pick static and you bought build times that grow until every deploy feels like a launch, plus the joy of telling marketing their urgent copy change ships "after the next build." Pick CSR and congratulations, you own loading-state chaos: skeletons, spinners, and the blank white flash that makes your CEO ask if the site is down.

A senior answer names who pays the bill, not just what the user sees.

The route cheat sheet

For the next interview, and honestly for the next architecture review:

• Static (SSG/ISR): public pages, same content for everyone, changes rarely. Docs, marketing, blogs. Cost: your build pipeline and deploy patience.
• SSR: personalized on first paint, SEO matters, data changes often. Product pages, feeds. Cost: you are running a server now, act like it.
• CSR: behind authentication, heavy interaction, first paint barely matters because the user is already yours. Dashboards, editors, admin tools. Cost: you own every loading state by hand.

And the one-liner that ends the interview question: "I would decide per route. Static where content is shared, SSR where first paint is personalized, CSR where the user is already authenticated, and I would name the operational cost of each."

The closer

The framework does not care. The route does. Say that, with one concrete trade-off attached, and the interviewer stops testing you and starts listening. That is the whole game.

This is question 11 from my Frontend System Design Interview Playbook, where all 60 questions get the same treatment: the decision, the trade-off, the one-liner that lands it.