When Server-Side Rendering Matters

We get this question from founders who have heard that their stack choice will make or break search traffic. Server-side rendering is the practice of generating a page's HTML on the server for each request and sending the finished page to the browser, instead of sending a mostly empty page and building it with JavaScript on the user's device.

The decision matters because it changes how fast first-time visitors see content, how reliably crawlers read your pages and how much server work every request costs. It is also easy to overspend on, by rendering pages on the server that no crawler or new visitor will ever see.

This post covers how server-side rendering differs from client-side rendering, where it matters most, a step-by-step way to decide page by page, when client-side rendering is the better choice and the mistakes that cost speed and money.

How Server-Side Rendering Differs From Client-Side Rendering

Server-side rendering builds the HTML before it leaves the server, while client-side rendering ships JavaScript that builds the page in the browser. MDN defines server-side rendering as "the practice of generating HTML content on the server and sending it to the client", and that one difference drives most of the trade-offs we weigh.

The third column matters more than most founders expect. Static rendering produces the HTML at build time, so pages that change rarely get the speed and crawlability of server rendering without paying for it on every request. We reach for it first for content that is the same for every visitor.

Server rendering is not free on the user's side either. Google's web.dev guide notes that generating pages on the server takes time, which can increase your page's TTFB, the time to the first byte, so a slow database query behind a server-rendered page shows up directly as a slower start.

Where Server-Side Rendering Matters Most for a Product

Server-side rendering matters most on pages whose job is to be found and to make a first impression. We look for these cases when we plan a new product:

• Marketing pages, pricing and landing pages that new visitors reach from search or ads.
• Blogs, guides and help centers that should rank and be quoted.
• Public listings and profiles, such as a directory, marketplace or job board, where each page targets its own searches.
• Pages shared on social networks and messaging apps, whose link previews come from the HTML the server returns.
• Audiences on slow phones or networks, where waiting for a large JavaScript bundle hurts most.

Crawlers are the strongest argument. Google's own search documentation says that server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript. Googlebot can render JavaScript, but other crawlers may read only the HTML they are sent.

How to Decide Which Pages Need Server-Side Rendering

Decide which pages need server-side rendering by sorting every route in the product into a short list of categories and choosing a rendering mode for each, rather than picking one mode for the whole application. We use six questions, in this order, on every new build.

1. List Every Route and Who Sees It First

Write down each page type and the person who usually lands on it first. A pricing page is usually seen first by a stranger from a search result, while a settings page is seen only by a signed-in user who already knows the product.

Pages that strangers see first are candidates for server or static rendering. Pages behind a login usually are not, because no crawler can reach them and the user has already committed.

2. Check Which Pages Must Rank or Be Quoted

If organic search, AI answers or link sharing is a real acquisition channel, the pages that feed it need complete HTML. Mark each of those routes and the queries or audiences it serves.

If the product grows through sales calls, partnerships or an existing customer base, this list may be very short. That is a legitimate outcome and it saves real engineering time.

3. Decide How Fresh Each Page's Content Must Be

Content that is the same for everyone and changes rarely, such as articles and feature pages, can be rendered once at build time. Content that changes per request or per user needs server rendering or client rendering.

Many frameworks also support regenerating static pages on a schedule, which covers listings that change every few minutes without rendering each request from scratch.

4. Measure First-Load Speed on Real Devices

Test key public pages on a mid-range phone over a slow connection and look at when meaningful content appears, not just when the page technically finishes loading. Client-rendered pages often look done to developers on fast laptops and feel blank to real visitors.

If first content is slow because of a large JavaScript bundle, server or static rendering helps. If it is slow because of a slow API, server rendering simply moves the wait to the server, and the fix is the query or a cache.

5. Price the Server Work and the Complexity

Every server-rendered request uses server CPU and memory, and traffic spikes land on your servers rather than on visitors' devices. Server rendering also adds hydration, where client code attaches to the server's HTML, and a class of bugs that appear only when the two disagree.

Compare that cost with the traffic and revenue the rendered pages are expected to bring. For a handful of marketing pages, static rendering usually gives most of the benefit at almost none of the cost.

6. Choose a Framework That Lets You Mix Modes

Pick a framework that supports static, server and client rendering per route, so the decision can change page by page as the product grows. web.dev notes that frameworks such as Next.js and Nuxt offer both static rendering and server-side rendering for this reason.

Being able to mix modes keeps the first decision cheap to revisit. A listing page that starts static can move to server rendering later without rewriting the rest of the product.

When Client-Side Rendering Is the Better Choice

Client-side rendering is the better choice for the signed-in heart of most products, because those screens are highly interactive, private and visited repeatedly by the same people. We keep dashboards, editors, admin panels and internal tools client-rendered unless there is a specific reason not to, which keeps server rendering for the pages that need it.

After the first load, a client-rendered app fetches only data for each new screen, so navigation feels quick and the servers stay simple. The usual cost, a short wait on first load, matters far less for a user who opens the tool every morning than for a stranger deciding whether to stay.

The hybrid approach is part of the product engineering work we do when planning a new product, because it keeps search and first impressions strong without making every screen harder to build. Our post on the tech stack question founders overrate explains why the framework itself matters less than these decisions.

Server-Side Rendering Mistakes That Cost Speed and Money

The most expensive server-side rendering mistakes come from applying it everywhere or from expecting it to fix problems it cannot reach. We see the same five patterns often:

• Rendering private dashboards on the server, which adds load and complexity with no search or first-impression benefit.
• Shipping public content only through client-side JavaScript, so crawlers that skip scripts see an empty page.
• Server rendering pages that never change, when static rendering would be faster and cheaper.
• Ignoring hydration mismatches, which cause flicker, broken buttons and errors that only appear in production.
• Expecting server rendering to fix slow APIs or bloated bundles, which still slow the page down from the server side.

Server-rendered pages also need the same care as any other server code under load. Caching rendered output is often the cheapest win, which our guide to caching strategy for cost and speed covers, and our founders' guide to software scalability at ten times the traffic covers what happens when those pages get popular.

Render Public Pages on the Server and Keep the App Simple

Server-side rendering matters on the pages strangers find through search, AI answers and shared links, and it rarely matters behind a login. Sort your routes, render public content on the server or at build time, keep the app client-rendered and measure first-load speed on real devices before and after. We would start with static rendering for content and add server rendering only where data must be fresh on every request.

If you are choosing an architecture for a new product and want a second view, the team at Better Software can talk it through with you.

Frequently Asked Questions

Why Use Server-Side Rendering?

We use server-side rendering so that visitors and crawlers receive a complete page immediately instead of waiting for JavaScript to build it. It helps public pages load faster on slow devices, show correct link previews and be read by bots that do not run JavaScript.

Is Server-Side Rendering Better for SEO?

Server-side rendering is usually better for SEO on public pages, because every crawler receives the full content in the first response. We still treat it as one factor among many, since content quality, links and page speed decide rankings, and static rendering gives the same crawlability.

Is Server-Side Rendering More Secure?

Server-side rendering is not automatically more secure. It lets us keep some logic and data access on the server, which helps, but it also adds server code that must be protected. Security still depends on authentication, input handling and how APIs check permissions.

Is Server-Side Rendering Expensive?

Server-side rendering costs more to run than serving static files, because the server builds each page on request. We keep the cost down by rendering only the pages that need fresh data, caching rendered output and using static rendering for content that changes rarely.

Is Server-Side Rendering Dead?

No, server-side rendering is widely used and supported by most modern frameworks. We see it used more selectively now, alongside static rendering and client-side rendering in the same product, with each page rendered in the mode that suits its audience and data.