Choosing the Right Frontend Rendering Strategy
July 23, 2026
Choosing a rendering strategy is one of the first decisions you will face in almost any modern frontend project. Frontend engineers therefore need to understand the available approaches and know which one fits a given situation. In this article, we will walk through the most common rendering strategies and the scenarios where each works best.
Before continuing, we recommend reading the E+ frontend article on the critical rendering path. This article builds on several concepts covered there and will not revisit them in detail, so having that background will make the discussion easier to follow.
Client-side rendering (CSR)
In the early days of the web, before frontend and backend development became separate disciplines, servers rendered most pages. The browser received the server-generated output, while JavaScript handled only simple interactions and animations. As browsers became more powerful, however, they gained the ability to perform complex computation and rendering themselves. The smoother user experience made possible by this shift led the industry to adopt client-side rendering, or CSR.
How CSR works With CSR, the initial request returns a mostly empty HTML document that provides only the basic shell:
<html>
<body>
<div id="root"></div>
<script src="bundle.js"></script>
</body>
</html>
The browser then follows the <script> tag and downloads the JavaScript—in this example, bundle.js. That JavaScript renders the application, creates the DOM, and carries out the steps described in the article on the critical rendering path. Once the application has rendered, client-side code calls backend APIs to fetch data. LCP is reported only after that data arrives and the main content appears.
Advantages of CSR CSR emerged in response to a major limitation of the traditional server-rendered model: every navigation required the server to prepare and return an entirely new page, which made interactions feel disruptive. With CSR, an interaction with the backend—such as submitting a form—does not require the server to send a new page. The application can update in place, avoiding the jarring experience of a full-page reload.
CSR also creates a clearer separation between frontend and backend code. Compared with traditional applications, where the two were often mixed together, this separation can make a codebase easier to maintain.
Problems with CSR Although CSR can provide a smoother interactive experience, it has some clear drawbacks:
- A longer wait on the initial visit: When users first open a CSR application, they may see a blank page or a skeleton screen. The real interface does not appear until the JavaScript has been downloaded, parsed, executed, and used to update the DOM. The larger the application bundle, the longer this process takes—and the worse the initial experience becomes.
- Less reliable SEO: Because the server initially returns an empty HTML shell, that is also what a search crawler sees at first. Many modern search engines can execute JavaScript while crawling, but there is no guarantee that every crawler will execute it as expected. As a result, SEO can be less predictable.
How to address the problems with CSR
- To reduce the wait on the initial visit:
- Keep bundles as small as possible. A common industry target is no more than 100 KB after gzip compression. Code splitting and lazy loading can help by delivering only the JavaScript needed for the current page instead of downloading the entire application at once.
- Use preload hints to start downloading important resources earlier.
- Cache HTML, CSS, and JavaScript with a Service Worker. As long as the cache remains valid, returning users can avoid downloading those resources again.
- To improve SEO: Earlier research from Vercel found that Google generally downloads and executes JavaScript, so CSR is less of an SEO concern for Google Search than it once was. Still, keeping JavaScript small is important because search engines assign each site a crawl budget. If executing a large JavaScript bundle consumes too much of that budget, some pages may never be rendered by the crawler, which can hurt their visibility in search.
For a much deeper discussion of CSR, the open-source Client-side Rendering project (link) provides a detailed analysis and is well worth reading.
Server-side rendering (SSR)
Now that we have covered CSR, let us turn to server-side rendering, or SSR. The way SSR is implemented has changed considerably over time, so we will examine its major forms separately.
Traditional SSR
As mentioned earlier, before frontend and backend development were clearly separated—and before CSR existed—web applications did nearly everything on the server. The server fetched data from the database, rendered the page, and sent the result to the browser.
Advantages of traditional SSR: Unlike CSR, traditional SSR does not send a full JavaScript application bundle to the browser. Instead, it sends ready-to-display HTML. Users on lower-end devices or slower connections therefore do not have to spend as much time downloading and parsing JavaScript. Because the HTML already contains the page content, SEO is also much less of a concern.
Problems with traditional SSR: Traditional SSR has real strengths, but CSR became popular for a reason. Every action that requires a new server response—submitting a form, for example—reloads the entire page. These full-page transitions can make the application feel slow and disruptive.
SSR with hydration
At this point, you might wonder whether it is possible to keep the main advantage of traditional SSR—HTML that is ready before it reaches the browser—while letting the client handle subsequent interactions as CSR does. That is precisely how modern SSR works.
Frameworks such as Next.js still render HTML on the server, but they add another step after the page reaches the browser: hydration. Hydration allows the client to take over subsequent interactions without full-page reloads.
The process works like this:
- The server renders the page and sends complete HTML to the browser. At this point, the user can already see the page content.
- The browser downloads a smaller amount of JavaScript and attaches event handlers to the existing DOM. This step is hydration. Because the initial interface is already present, the client only needs to make it interactive.
- Once hydration finishes, the client takes control as it would in a CSR application. Users get a responsive interactive experience without the full-page transitions of traditional SSR.
Advantages of SSR with hydration: It solves the interaction problem of traditional SSR while avoiding the blank initial state associated with CSR.
Problems with SSR and hydration: This approach may appear to offer the best of both worlds, but it has a problem of its own. The HTML can appear as soon as it reaches the browser, yet the page remains non-interactive until its JavaScript has finished hydrating. You have probably encountered a page that looks ready but whose buttons do nothing when clicked. That gap between visible content and working interactions is the main drawback of SSR with hydration.
Streaming SSR
In recent years, the industry has developed better ways to address the limitations of SSR with hydration. One of them is streaming SSR.
Early implementations of SSR with hydration rendered the entire HTML document on the server and then sent it to the browser all at once. But HTML can be streamed. When SSR uses streaming, the server can render and send each part as soon as it becomes ready.
The browser no longer has to wait for every data request to finish before receiving any rendered content, nor does it have to wait for the server to finish rendering the entire page. From the user's perspective, the page feels faster.
Better approaches to hydration
Streaming can improve SSR itself, but hydration can also be optimized. Early SSR applications hydrated the entire page in one pass, which meant that nothing became interactive until hydration finished everywhere. Several approaches now make this process more efficient.
Progressive hydration Progressive hydration lets developers decide which parts of a page should hydrate first. Only the most important sections hydrate during the initial load; the rest follow later. A high-priority section becomes interactive as soon as its hydration finishes, without waiting for the whole page.
Island architecture Island architecture was proposed by Etsy architect Katie Sylor-Miller. It divides a page into independent components—like islands—and hydrates only the ones that need to be interactive. Compared with progressive hydration, island architecture can be understood as separate hydration.
Hydrating one island does not block another. If one component takes longer to process, other components can still become interactive first. With a strictly progressive sequence, by contrast, a slow early component could delay everything that follows.
Selective hydration Selective hydration was introduced by the React team. Like island architecture, it divides the page into components. By default, React hydrates those components in the order they appear in the virtual DOM tree. If a user interacts with a component, however, React pauses lower-priority hydration work and prioritizes that component. The part the user needs first can therefore become interactive sooner, improving the overall experience.
Support ExplainThis
If you found this content helpful, please consider supporting our work with a one-time donation of whatever amount feels right to you through this Buy Me a Coffee page.
Creating in-depth technical content takes significant time. Your support helps us continue producing high-quality educational content accessible to everyone.