Hi there! I'm Maneshwar. Right now, I’m building LiveAPI, a first of its kind tool for helping you automatically index API endpoints across all your repositories. LiveAPI helps you discover, understand, and use APIs in large tech infrastructures with ease.
One of the key decisions you'll face building for the web is where to render your content, the server, the client, or somewhere in between.
Your choice impacts page speed, interactivity, and scalability.
Chrome's team has worked with big sites over the years, and the takeaway is clear:
Prefer static or server-side rendering over full client-side hydration — when you can.
Here’s a breakdown of each rendering method, performance tradeoffs, and when to use what.
Quick Glossary (aka Let's Speak the Same Language)
- Rendering: Turning your app/data into HTML the browser can show.
- Server-side rendering (SSR): HTML is generated on the server — browser gets the finished product.
- Client-side rendering (CSR): HTML is built in the browser — browser gets JS, does all the work.
- Prerendering / Static rendering: HTML is generated ahead of time (build time), often deployed to CDNs.
- Rehydration: JavaScript takes over static/SSR HTML to "activate" the app on the client.
Key Performance Metrics
| Metric | What it Means |
|---|---|
| TTFB | Time to First Byte — network + server processing time. |
| FCP | First Contentful Paint — how quickly content appears. |
| TBT | Total Blocking Time — JS execution that blocks interaction. |
| INP | Interaction to Next Paint — how snappy user input feels. |
Server-Side Rendering (SSR)
HTML is generated per request on the server. Think: dynamic but lean.
Pros:
- Fast FCP (users see something quickly).
- Low TBT (less JS on initial load).
- Scales better across devices (especially low-end phones).
- Works even when JavaScript fails.
Cons:
- TTFB can increase — the server does more work per request.
- Hydration cost on the client can hurt INP if not managed well.
- React’s
renderToString()is slow — use streaming if possible.
Use when:
- Pages rely on fresh data.
- You want decent SEO + speed.
- You're okay with backend complexity.
Real-world example:
Netflix SSRs landing pages, but prefetches JS for rich, interactive pages.
Static Rendering (Prerendering)
HTML is built at compile-time and served instantly. Think: blogs, docs, landing pages.
Pros:
- Insanely fast TTFB and FCP.
- Very low TBT and INP — especially if you keep JS minimal.
- Deployed to CDNs = global performance wins.
Cons:
- You must know your URLs at build time.
- Doesn't scale well for highly dynamic or personalized content.
Use when:
- Content doesn't change often.
- You want speed and SEO.
- You can build your pages ahead of time.
Popular tools:
- Next.js static export
- Astro, 11ty, Jekyll, Hugo
- Gatsby (with caveats)
Client-Side Rendering (CSR)
HTML is built in the browser with JavaScript. Think: single-page apps (SPAs).
Pros:
- Great for complex, app-like interactions.
- No need for a backend to generate pages.
- Easy routing and state management.
Cons:
- Terrible FCP and TBT if you’re not careful.
- Requires lots of JS = slower on mobile.
- Can harm SEO unless prerendering/hybrid techniques are used.
Use when:
- You're building a real app, not just a website.
- You rely heavily on client-side state and interactions.
Tip:
Use PRPL pattern and code-splitting. Lazy-load heavy parts.
Rehydration (Hybrid)
Render HTML on the server, then hydrate it on the client. Best of both worlds? Not quite.
Pros:
- Fast FCP from server-rendered HTML.
- Keeps app state + interactivity like CSR.
Cons:
- Hydration JS blocks interaction = worse INP/TBT.
- On mobile, hydration can be slooooow.
- Often requires you to render the app twice (server + client).
Use when:
- You need SEO and rich interactivity.
- You want to SSR some parts, hydrate others.
Frameworks:
- Next.js (React)
- Nuxt (Vue)
- SvelteKit, Remix, Qwik
How to Test Your Setup
- Disable JS → Static pages should still work. Prerendered apps won’t.
- Throttle network → See how much JS loads before interaction works.
- Measure FCP, TBT, INP using Chrome DevTools or Lighthouse.
TL;DR: What to Use When?
| Use Case | Best Rendering |
|---|---|
| Marketing / Landing Pages | Static Rendering |
| Dynamic Data (e.g. Dashboards) | SSR or Rehydrated SSR |
| Full-blown Web App | CSR or Hybrid |
| Personalized Content | SSR |
| Blog, Docs | Static |
Final Thoughts
Rendering isn’t one-size-fits-all.
Your job isn’t to pick one rendering strategy — it’s to mix and match where it makes sense.
Use static rendering where you can, SSR where you must, and hydrate carefully when you need rich interactivity.
Smart rendering = faster apps = happier users.
LiveAPI helps you get all your backend APIs documented in a few minutes
With LiveAPI, you can quickly generate interactive API documentation that allows users to search and execute APIs directly from the browser.
If you’re tired of manually creating docs for your APIs, this tool might just make your life easier.
Top comments (2)
Great overview! I’d just add that sometimes client-side rendering can still be the best fit, especially for apps with lots of real-time updates or offline functionality. While SSR and static approaches are fantastic for speed and SEO, CSR’s flexibility with dynamic content or user-specific data can be a big advantage in certain use cases. It really all depends on the project goals and user needs!
Love how you broke down when to use each rendering strategy, it's so practical. Curious, what's your take on partial hydration or islands architecture for big apps?