Should dashboards default to SSR or stay client-side SPAs?

[adonisdev313]

Building a React dashboard with real-time data (Supabase, analytics, payments). Everyone keeps saying "use Next.js for SSR" but I'm seeing faster dev cycles and simpler deploys with Vite + client-side rendering.
When does SSR actually matter for dashboards? Or is it just cargo-culting best practices from content sites?

[Hagen779]

Dashboards should stay client-side. SSR is solving the wrong problem.
Here's why:
SSR wins for:

Public content (blogs, marketing, e-commerce)
SEO requirements
First-paint performance for strangers

Dashboards don't need any of that.
Your users are:

Authenticated → They wait for login anyway, SSR's "instant first paint" is irrelevant
Returning daily → Browser caches everything after first visit
Behind auth walls → Zero SEO benefit
Expecting real-time data → You're hydrating from APIs post-render regardless

What actually matters for dashboards:

Fast API responses (optimize your Supabase queries)
Aggressive caching (React Query, SWR with stale-while-revalidate)
Code splitting (lazy load heavy charts/tables)
Optimistic updates (feel fast > be fast)

Vite + React is the right call. Next.js adds:

Serverless complexity
Vendor lock-in (Vercel edge functions)
Extra render cycles (server → hydration → client state)

Ship client-side. Optimize what users actually feel: interactions, not initial paint.

[adonisdev313]

thanks! that's a real solution! I will refer to this.

[icyJoseph]

32 seconds between post and answer... are we actually interested in helping here?

[xiaoxin313]

Hello adonisdev313, nice to meet u.
Your discussion topic is very interesting for me.
I think like this.
Client-side. Period.
SSR optimizes for strangers. Dashboards serve authenticated users with live data.
SSR costs:
Hydration overhead
Serverless complexity
Stale HTML (pointless for real-time)

What matters:
Code-split routes
Parallel API calls
Optimistic updates

Vite = faster dev, static deploy, zero vendor lock-in.
Next.js for blogs. Vite for apps.

[adonisdev313]

Hey! Who are u? What does it matter?

…

On Tue, Mar 17, 2026 at 12:53 AM Joseph ***@***.***> wrote: 32 seconds between post and answer... are we actually interested in helping here? — Reply to this email directly, view it on GitHub <#91475 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B2ZEMT7FGG5QXIFPHMDTU234RCAVZAVCNFSM6AAAAACWT4WSOWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMJWG42DIMQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[anthonysides23]

IM THE MASTER APPLICATION BUILDER

[adonisdev313]

So? what does it matter? He is lord of sky? Lol

[icyJoseph]

I was answer going to answer this, but it is looking like unauthentic user activity, probably trying to drive a narrative, or farm answers.

For what is worth what I had been drafting. I didn't finish it, but I don't think anyone on this thread cares lol

---

Everyone keeps saying "use Next.js for SSR" but I'm seeing faster dev cycles and simpler deploys with Vite + client-side rendering.
When does SSR actually matter for dashboards? Or is it just cargo-culting best practices from content sites?

You can do dashboards with Next.js. Focusing on SSR is the wrong level of abstraction even, and shows that, even if you go CSR, you are likely designing the solution incorrectly.

"SSR first paint is irrelevant for authenticated users"

With the App Router, the server reads the session cookie and fetches data in a single request. The user sees a fully rendered page on navigation, not a blank shell followed by client-side fetch waterfalls. This is faster than SPA-style useEffect → fetch → render, especially when the server is co-located with the database.

"First-paint performance for strangers"

As if SSR is some kind of hospitality feature for anonymous visitors. Server rendering isn't about "strangers vs regulars"; it's about where computation happens. A returning authenticated user still benefits from getting a server-rendered page with data already in it instead of a blank shell + spinner + client fetch waterfall.

"You're hydrating from APIs post-render regardless"

Server Components ship zero client JS. Initial dashboard data arrives server-rendered, and only the real-time subscription piece needs a thin Client Component. This means less JavaScript shipped and a faster meaningful paint.

"Vendor lock-in (Vercel edge functions)"

Next.js is open source and runs on any Node.js host with next start. output: 'standalone' produces a self-contained server you can deploy anywhere (Docker, VMs, any cloud).

The Adapters API is for individuals or organizations, with a predefined infrastructure, CDN, Cache layers, etc, to map their infra into the Next.js server, not that this requires an existing custom infra, which further eliminates barriers of adoption into other providers.

"Serverless complexity"

next start is a standard long-running Node.js server. No serverless infrastructure required.

For dashboards specifically, server-rendering has advantages: data fetching without exposing API credentials to the client, reduced client bundle size (heavy transformations stay server-side), and elimination of client-side fetch waterfalls. These matter for dashboards with many data-heavy panels.

A Vite SPA is absolutely a valid choice, the point is that the tradeoffs should be evaluated on accurate technical grounds, not outdated assumptions about how SSR works.

Dev Cycles and HMR

Next.js with Turbopack has fast HMR too. When HMR feels slow, it's usually a bottleneck in server-side evaluation, something you'd hit client-side too, just masked as a loading spinner instead.

[adonisdev313]

Do you have nothing better to do? Or is monitoring this discussion forum your full-time job?