Rendering on the Web: What, Where, and Why?

[Lomanu4]

Hi there! I'm Maneshwar. Right now, I’m building

Пожалуйста Авторизируйтесь или Зарегистрируйтесь для просмотра скрытого текста.

, 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.

Пожалуйста Авторизируйтесь или Зарегистрируйтесь для просмотра скрытого текста.

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.

Пожалуйста Авторизируйтесь или Зарегистрируйтесь для просмотра скрытого текста.