Web Rendering: SSR, CSR, SSG, ISR and Edge Explained

What is web rendering?

Web rendering is the process of turning application code and data into the HTML a browser displays. The key question is where and when it happens: on the server for each request, in the browser after JavaScript loads, or ahead of time at build time. That choice shapes speed, SEO, hosting cost and how fresh the content is.

The main rendering strategies

How each strategy works

• SSG: a build step writes one HTML file per URL and a CDN serves them. Nothing runs per request, so it is cheap and handles traffic spikes well, but content only updates after a rebuild.
• SSR: the server builds the HTML for each request. Content is always current and can depend on the user, but every visit costs server time and the time to first byte grows with it.
• CSR: the server sends a small shell and a JavaScript bundle, and the browser builds the page. Navigation inside the app feels instant, but the first view waits for the bundle to download and run.
• ISR: static pages that are regenerated in the background after a set time or when you trigger it, so you get static speed with bounded staleness.
• Edge rendering: SSR code that runs at CDN locations instead of one origin region. Latency drops for distant users, but edge runtimes limit which APIs and libraries you can use.

Hydration: where server and client meet

SSR and SSG send finished HTML, but interactive parts still need JavaScript. Hydration is the step where that JavaScript attaches to the existing HTML. It can be expensive on large pages, which is why frameworks offer partial hydration, streaming and server components to ship less JavaScript.

Example: choosing per page for an online shop

• Home page and guides: SSG, because they are identical for everyone.
• Product pages: ISR, so a price change shows up within minutes without rebuilding the whole catalog.
• Cart and checkout: CSR or SSR, because they depend on the visitor and do not need to rank.
• Banner by country: edge rendering, or a small client-side script.

Common mistakes

• Using CSR for public pages that must rank, then wondering why previews and some crawlers see an empty page.
• Using SSR for pages that never change, which adds server cost and slows the first byte for no gain.
• Shipping a huge JavaScript bundle on top of server-rendered HTML, so the page looks ready but ignores clicks.
• Caching personalized SSR output at the CDN and serving one user's page to another.
• Picking a strategy by trend instead of measuring real pages.

Rendering, performance testing and monitoring

The rendering strategy shows up directly in the numbers that matter. Static and server-rendered pages usually help Largest Contentful Paint, heavy hydration hurts Interaction to Next Paint, and CSR pushes work onto the visitor's device. Track these with Core Web Vitals on a schedule, for example with LoadFocus Page Speed Monitoring, and read how to monitor Core Web Vitals with alerts and reports for the setup.

SSR also changes capacity planning: every request runs code, so run a load test before a launch to see where response times start to climb. A statically served site mostly tests the CDN instead.

FAQ: web rendering

SSR or SSG: which one should I pick?

Pick SSG when a page is the same for every visitor and changes rarely. Pick SSR when the page depends on the request, such as a cookie, a location or fresh data. If you need both, regenerate static pages on a schedule or on demand (ISR).

Is client-side rendering bad for SEO?

Not automatically. Google can run JavaScript, but it takes an extra step and other crawlers and link previews may see an empty shell. For public pages that need to rank, send real HTML from the server or build step.

What is the difference between rendering and hydration?

Rendering produces the HTML. Hydration is the step where JavaScript in the browser attaches to that HTML so buttons and forms work. A page can be fully rendered and still not respond to clicks until hydration finishes.

Can I mix rendering strategies in one site?

Yes. Most modern frameworks choose per route. A typical site serves marketing pages statically, product pages with ISR and the logged-in app with client-side rendering.

Which rendering strategy is fastest?

Static pages served from a CDN usually give the lowest time to first byte, because no code runs per request. Speed still depends on page weight, images and JavaScript, so measure your own pages instead of trusting the label.