tech-blogs

Why I stopped hating React Server Components

Tushar Motwani — Sat, 19 Sep 2026 17:36:05 GMT

When I first migrated to next js from react, I was frustrated by the idea of having components named differently as "client" or "server" components.

And a rule book of how to use what kind of component, like not having listeners and hooks in the server components, adding the top directive "use client" to explicitly mention client components, calling the DB directly from server component and all.

Like, I mean why do we need that at all?

As a react developer, I was habitual with the way of webapps operating completely on the client.

Apps that get built at client, js bundles execute at client and even data fetches happen from the client.

But when I got introduced with the metrices like build time (js bundle execution) at the client, SEO, FCP and all, and how they differ in the classic SPAs and Next js server components, I realised that something was really off working that way.

How do classic SPAs work?

At the classic Single Page Applications like React, everything happens on client like fetching the js bundle, building the app shell, executing the javascript and fetching the data.

In a typical client-rendered SPA, the application cannot start its own data fetching and rendering until enough JavaScript has been downloaded and executed to bootstrap the application.

When you visit the app for the first time, the server sends you a raw html with no content, but a useful script which looks something similar too:



  
    
    
  
  
    
    /* script executes on client to load the content */

This HTML has nothing, no content, no elements in the body (except the root) to show at the client browser.

What it does have is a useful script tag with a JS file. The browser then loads this javascript file, compiles and executes it to render the app shell or what we call as layout of the app. The loaders or skeleton or static elements appear by now.

Means for a component like this:

import { useEffect, useState } from "react";

export default function App() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch("http://api.data.com/user")
      .then((res) => res.json())
      .then((data) => setData(data))
      .finally(() => setLoading(false));
  }, []);

  if (loading) {
    return (
        User info
        Loading...
    );
  }

  return (
    User info
    {data.userName}
  );
}

Once the JS is loaded, compiled and executed at the browser, you will have the heading as "User info" and the "Loading..." text appear on your browser.

And once the data fetch is completed, you will the actual data in place replaced by the "Loading..." text or any kind of skeleton or spinner you have.

But we have got a major problem with this, because of these steps:

HTML sent to client
JS bundle sent to client
Browser loads, complies and executes JavaScript
Data fetching occurs

You see the actual data fetch occurs at the fourth step, once the JS is loaded, complied and executed on the client.

And if the JS bundles are huge or the browser network is slow, this may take a few seconds and until then user sees a blank screen on his browser which is enough for him to feel that the app is broken.

React Server Components

The way that the server components work is that you can have your async functions calling the database or api directly from the component without any useEffect hook.

Like the similar code block for data fetching above can be rewritten in server components as:

// app/dashboard/profile/page.tsx

async function getData() {
  const res = await fetch("http://api.data.com/user");
  return res.json();
}

export default async function ProfilePage() {
  const data = await getData();

  return (
    <>
      User info
      {data.userName}
    
  );
}

And of course for the loading component, you can have a loading.tsx too:

// app/dashboard/profile/loading.tsx:

export default function Loading() {
  return (
    <>
      My Dashboard
      Loading...
    
  );
}

or a tag for a better suspense boundary.

Now the cool thing with server components is, they are built at server. The data fetching or processing occurs much faster there.

And there is way less Javascript bundle size to get loaded, compiled and executed on the client if you can mark the components as "client" or "server" correctly.

Also, your app is way more faster, has less FCP time (if you have your suspense boundaries placed correctly).

RSC + streaming lets the server start sending useful UI while slower parts are still resolving.

And since the server components, never get re-executed on the client, that means they shouldn't and can't be hydrated (Hydration is the process of taking server-rendered HTML and attaching React's client-side behavior to it so that it becomes interactive. It includes attaching listeners, events to your functions or hooks), and that's exactly the reason why you can't have listeners (like onClick) and hooks (like useState, useEffect) on your server components.

The biggest advantage of this is the size of the JS bundle that will now get executed at the client is less as we have less components to built and hydrated at the client (marked as client components).

Why Your Next.js Navigations Feel Slow

Tushar Motwani — Mon, 14 Sep 2026 17:45:59 GMT

You click a dashboard link. Nothing changes. You wait. And then suddenly the entire page appears.

The database query might only take a couple of seconds. But from the user's perspective, the application feels frozen.

The problem isn't necessarily Server Components.

The problem is letting an async Server Component block the user from seeing any feedback.

I can route around a web app, observe the slow navigations and almost for every such app, I can tell you that it is built using next server components.

But honestly, this isn't a problem with the Next.js team or Server Components themselves. The problem is how we build applications with them. We bring the same mindset we use when handling async operations in client components, without thinking about how server-side async work affects navigation UX.

Understanding the Problem

The server components in next can be async, they can have multiple async operations inside them before the component is completely ready to be served to the client.

That's why they are built at server, they need (or are at least meant) to perform some async operations before they are ready to be rendered on the client.

Like a profile page needs to call the database and fetch the logged in user's info to display it inside the component. So your /app/profile/page.tsx may look like:

export default async function page() {
 // have the db call:
 const user = await db.users.find(session.userId) // ---> ASYNC

 return (
    {user.username}
 )
}

Now the db call above is an async operation, it takes time probably a few milliseconds but still that's some time, and to be honest if you have large data operations, complex queries, it can take around 3-4 seconds or more.

And since this is a server component which means it builds on server, when your user clicks profile tab, it takes time to build at the server and it takes over the page only when it is completely ready. So your app is sitting there unresponsive to the user in the time, the page is being ready.

The UI is unresponsive on the user click, there's no way for the user to know that his action is registered and now the page is being ready.

And that is an awful UX. I click on a page and I see no response, that's terrible, and suddenly the page is ready on my screen, that's even worse.

Remember the problem is not the db call taking time, it will eventually as your app grows, you can optimise upon it but still there is some time taken. The actual problem, not responding the user that the requested content is "loading".

How next renders the react tree

To have the solution, and more importantly to understand why this happens, we first need to get into how the react tree is rendered with your app.

Let's take a standard next app which looks something like this:

my-next-app/
│
├── src/
│   ├── app/
│   │   ├── layout.tsx
│   │   ├── page.tsx
│   │   | 
│   │   │
│   │   └── dashboard/
│   │       ├── layout.tsx
│   │       └── page.tsx --> // async server component (calls db)

Here in this app, the page.tsx inside dashboard is the one that is an async server component, it fetches the data from DB, and renders on the page, so the page is avaliable at "/dashboard".

Now this page is routed inside dashboard which is further routed inside the root app, so effectively the page is at: "my-next-app/app/dashboard".

A classic app/layout.tsx is something like:

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    
      
          {children} 
      
    
  );
}

This app/layout covers app/page and similarly the dashboard/layout covers the dashboard/page and looks something like:

// dashboard/layout.tsx:

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    
      
        
        
          {children} 
        
      
    
  );
}

where in our case, the dashboard/page.tsx looks somthing like:

// dashboard/page.tsx:

export default async function page() {
 // have the db call:
 const user = await db.users.find(session.userId) // ---> ASYNC

 return (
    {user.username}
 )
}

To render /dashboard, Next.js composes the layouts and page belonging to that route into a React tree.

So effectively to reach /app/dashboard/page.tsx, the tree collects /app/layout.tsx, /app/page.tsx and /dashboard/layout.tsx.

So building the page "/app/dashboard/page.tsx", the react tree looks something like:

 // -> root layout
    
        
            .....
	    
        
             // --> dashboard layout
                 // --> sidebar
                
                     // --> dashboard page

A small note: This is a simplified way of looking at what's happening. Next.js and React have a much more complex rendering and streaming system under the hood, but that's a topic for another article. For now, all we need to understand is that async work can leave the user staring at an unchanged screen if we don't give them a loading or Suspense fallback.

Note, everything except the dashboard page (app/dashboard/page.tsx) is static and available at build time, so next js is actually ready to render the tree and display the content as soon as someone navigates to your dashboard page but since the dashboard page itself is an async server component and it needs time to get resolved, and literally from the user's perspectve, it feels like a hang.

Means, I have clicked on the dashboard and there is no visual response in my screen indicating that my action has been registered which is actually the fact and the page is being ready, but who's gonna tell me that.

This also means, if the route doesn't have to wait for server-side async work before showing its content, the user can see the UI much sooner.

The static pages, not having any async server side operation to display their content can be available instantly as the user navigates to them.

But wait, does that means there's no way to get the server component work that way?

No, there's a way and that's pretty simple that most of us think.

When the UI you're navigating to depends on async work, you need a boundary that gives Next/React something to show while that work is pending. Next allows us to pass a static component to render as a fallback, until our actual async component or page is being resolved.

Now, there are a couple of ways to do that.

One very simple way is to add a loading.tsx at the same level of your page.tsx:

src/
└── app/
    ├── layout.tsx
    ├── page.tsx
    │
    └── app/
        └── dashboard/
            ├── layout.tsx
            ├── loading.tsx // ---> ADD THIS
            └── page.tsx

export default function Loading() {
  // You can add any UI inside Loading, including a Skeleton.
  return Loading...
}

Adding the loading.tsx at the same level as page.tsx make the tree look like:

 // -> root layout
    
        
            .....
	    
        
             // --> dashboard layout
                 // --> sidebar
                
                     // --> loading
                         // --> dashboard page

Now, as the next app renders down the component tree and it sees a component that needs to be resolved before it is rendered, then instead of blocking the page, it renders the loading component as a fallback until the page is resolved.

As soon as the tree reaches a component which needs time to resolve (server component), it looks up to render some fallback component in the same boundary...you just need to provide that static fallback component.

Under the hood, Next.js uses a Suspense boundary for loading.tsx. The important part for us is that it gives the route a fallback UI to show while the page is loading.

And that's it, now your users are not feeling the "lag" in your app as soon as they route to a page, which is or has a server compoent.

Why Suspense over loading.tsx?

So the main point is,
You need to tell next js to render the page statically as the fallback version until the server component is being ready or the children is being resolved.

Adding loading.tsx does this, tag does the same too.

But with , you can have more control over the component for which you want to render the static fallback version.

To be more precise, you have more control over the suspense boundary, and instead of showing the loading for the entire page, you can still have the static parts of your page in place and show loader or skeleton as fallback for the exact async component that takes time to get resolved.

With loading.tsx:

// app/dashboard/page.tsx

async function getStats() {
  const res = await fetch("https://api.example.com/stats", { cache: "no-store" });
  return res.json();
}

export default async function DashboardPage() {
  const stats = await getStats();

  return (
    
      Dashboard
      
        Overview of your account
      
      {stats.users}
    
  );
}

// app/dashboard/loading.tsx

export default function Loading() {
  return (
    
      
    
  );
}

As you navigate to /dashboard, your screen looks like:

And with Suspense:

// app/dashboard/page.tsx
import { Suspense } from "react";

async function Stats() {
  const res = await fetch("https://api.example.com/stats", { cache: "no-store" });
  const stats = await res.json();

  return (
    
      {stats.users}
    
  );
}

export default function DashboardPage() {
  return (
    
      Dashboard
      
          Overview of your account
      

      
        }> // --> Suspense 
          
        
      
    
  );
}

function StatsSkeleton() {
  return (
    
      
    
  );
}

on instant navigation, your dashboard page looks something like:

You can see the difference, with suspense, you can have more control that over what components exactly, you need to show the loaders or skeletons and just wrap those components with suspense fallback instead of the entire page which eventually has a much better UX.

Also one more thing that on adding both the loading.tsx and the tag can show the loading.tsx content for a few milliseconds and then the Suspense fallback component as the component gets resolved.

That's because, the next app first builds the shell, at that time the loading.tsx is the suspense boundary and once that's done, the tag takes over.

Nothing wrong with it, just be aware while using.