Server-Driven UI vs Client-Side Rendering: Which Fits Your App?

Updated 5 November 2026 · Standard formula, shown below

Server-driven UI (SDUI) and client-side rendering (CSR) answer two different questions: SDUI decides what the screen shows, while CSR decides where the code runs. If your app needs to change its interface without releasing a new version, SDUI is the right fit; if your app is a complex, interactive tool that must work offline, CSR is the right fit. Many production apps use both, but choosing a primary approach depends on your team, your users, and how often your UI changes.

What Is Server-Driven UI?

Server-driven UI is an architecture where the backend sends not just data, but also a description of the interface itself. The client receives a JSON payload that defines the layout, components, and actions, then renders it natively. For example, a home screen might be described as:

{
  "type": "list",
  "items": [
    {"type": "banner", "text": "Welcome back!", "action": "open_promo"},
    {"type": "button", "text": "View Orders", "action": "orders"}
  ]
}

The client has a set of pre-built components (banner, button, list) and simply maps the JSON to those components. The server controls the order, the content, and even which components appear, so you can change the entire layout without waiting for an app store review.

What Is Client-Side Rendering?

Client-side rendering is the traditional approach for single-page applications (SPAs). The server sends a minimal HTML shell plus JavaScript bundles. The browser downloads the JavaScript, executes it, fetches data from APIs, and then renders the UI in the browser. Popular frameworks like React, Vue, and Angular use this model. The client is responsible for both the logic and the presentation, and the server only provides raw data via JSON endpoints.

Key Differences: Who Controls the UI?

The core difference is control. In CSR, the client code is the single source of truth for the UI. In SDUI, the server is the source of truth for the structure, and the client only provides the building blocks. This has several practical consequences:

Updates: With SDUI, you can change the UI instantly by updating the server payload. With CSR, any UI change requires a new JavaScript bundle to be deployed and the user to refresh the page.
Offline capability: CSR apps can work fully offline if they cache data and code. SDUI apps typically require a network connection to fetch the UI description, unless you implement complex caching.
Performance: CSR often feels faster after the initial load because subsequent interactions don’t require a round trip. SDUI can feel slower on every screen change because the client must wait for the server to send the layout.
Debugging: CSR is easier to debug because all logic lives in one place. SDUI requires you to trace through server payloads and client rendering logic, which can be harder to reproduce.

How to Choose: Questions to Ask

There is no universal answer, but these questions will guide you:

How often does your UI change? If you release new features or layout changes weekly, SDUI saves you from app store reviews. If your UI is stable, CSR is simpler.
What is your team’s skill set? If your team is strong in backend development, SDUI lets them control the UI. If they are frontend specialists, CSR is more natural.
What are your users’ network conditions? If users are on slow or unreliable connections, CSR with service workers can provide a better experience after the first load. SDUI requires a network call for every screen.
Do you need deep offline support? CSR wins here. SDUI can be made offline-capable, but it’s a lot of extra work.
How complex is your UI? Highly interactive, stateful interfaces (like a spreadsheet or a design tool) are much easier to build with CSR. SDUI works best for content-heavy, list-based interfaces.

Common Problems and Misconceptions

A common misconception is that SDUI is the same as server-side rendering (SSR). They are not. SSR renders HTML on the server for SEO and initial load speed, but the client still controls the UI after that. SDUI is about the structure of the UI, not just the HTML. Another misconception is that SDUI eliminates the need for a frontend developer. In reality, you still need frontend developers to build the component library and the rendering engine.

Common problems with SDUI include:

Versioning hell: When the server sends a component that the client doesn’t know about, you get a crash. You need a versioning strategy to ensure compatibility.
Latency: Every screen change requires a network round trip. You can mitigate this with caching and prefetching, but it adds complexity.
Testing: Testing SDUI is harder because you need to test the server payloads and the client rendering together.

Costs and Performance Trade-offs

SDUI shifts work to the server. You need to design, version, and host the UI description payloads. This can increase backend complexity and server load. CSR shifts work to the client. The initial JavaScript bundle can be large, increasing load time. However, after that, interactions are fast because they don’t require a server round trip.

Performance metrics to consider:

Time to Interactive (TTI): CSR often has a slower TTI because the browser must download and execute JavaScript. SDUI can be faster if the server sends a minimal payload and the client renders it immediately.
First Contentful Paint (FCP): CSR often has a slower FCP because the screen is blank until JavaScript runs. SDUI can show content as soon as the payload arrives.
Network requests: CSR typically makes one request for the HTML, one for the JS, and then multiple API calls. SDUI makes one request per screen, but each request contains both data and layout.

Alternatives and Hybrid Approaches

You don’t have to choose one exclusively. Many apps use a hybrid:

SDUI for dynamic screens: Use SDUI for home screens, promotions, or any area that changes frequently.
CSR for complex features: Use CSR for features like a checkout flow or a dashboard where the user needs immediate feedback.
Static rendering for SEO: For public-facing pages, consider static site generation (SSG) or server-side rendering (SSR) to improve SEO and initial load.

Another alternative is progressive enhancement: start with server-rendered HTML, then enhance with JavaScript on the client. This is a middle ground that gives you SEO and fast initial load, plus interactivity.

Frequently Asked Questions

Is server-driven UI the same as server-side rendering?

No. Server-side rendering (SSR) generates HTML on the server for the initial page load, but the client still controls the UI after that. Server-driven UI (SDUI) sends a description of the UI structure (often JSON) that the client renders using native components. SSR is about where the HTML is generated; SDUI is about who controls the UI structure.

Can I use server-driven UI with React?

Yes. You can build a React component that takes a JSON schema and renders the appropriate components. Libraries like react-json-view or custom renderers can map JSON to React components. However, you lose some of React’s client-side state management benefits if you rely on the server for every UI decision.

Does server-driven UI work offline?

Not by default. Because the UI description comes from the server, you need a network connection to render the screen. You can cache the last known payload and use it offline, but you need to handle conflicts when the server updates. CSR apps can work fully offline if they cache the JavaScript and data.

Which is better for SEO?

Client-side rendering is generally worse for SEO because search engines have to execute JavaScript to see the content. Server-driven UI, if it returns HTML (which it often doesn’t), can be better, but most SDUI implementations return JSON, which search engines don’t parse. For SEO-critical pages, use SSR or static generation instead.

Is server-driven UI more secure?

Not inherently. SDUI can reduce the risk of client-side injection because the client only renders known components. However, you must validate the JSON payload to avoid malicious content. CSR is more vulnerable to XSS if you use dangerouslySetInnerHTML or similar. Security depends on how you handle user input and sanitize data, not on the rendering approach.

When should I avoid server-driven UI?

Avoid SDUI when your UI is highly interactive, stateful, or requires real-time updates (like a chat app or a game). Also avoid it if your team is small and you don’t have the resources to build and maintain the server-side UI description system. For simple CRUD apps, CSR is often simpler and faster to develop.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.