SSR, CSR, SSG and ISR: what actually changes
SSG creates HTML before the user requests a page, usually during the build. SSR creates HTML on the server for a request. CSR sends little pre-rendered content and builds much of the interface after JavaScript executes in the browser. ISR keeps a static result but allows selected pages to be regenerated after deployment based on time or explicit cache invalidation. [6][9][16]
The useful questions are therefore not just whether a page is called `SSR` or `SSG`, but when its HTML is generated, how long that result is cached, and how much work the browser still has to perform.
SEO: Google can render JavaScript, but CSR is not equivalent to prerendering
Google describes JavaScript processing in three stages: crawling, rendering and indexing. If the initial HTML response does not contain the real content, Google must execute JavaScript in its Web Rendering Service and the page enters a render queue. [1]
Google also states that server-side rendering or prerendering remains a good idea because it makes sites faster for users and crawlers, and not all bots can run JavaScript. [1]
The practical conclusion is that CSR can work in Google Search, but public content that should be indexed quickly and reliably is safer when meaningful HTML is already present in the response.
SSG: the best starting point for content that does not need request-time freshness
With SSG, HTML is generated during the build and can then be served as static files from a CDN. Next.js describes Static Generation as prerendering before a user request and recommends it where pages can be generated ahead of time. [9][12]
Typical use cases include landing pages, documentation, articles, help pages, portfolios and some product listings. Serving a static result removes server rendering work from each request and makes caching straightforward. [10][16]
The trade-off is freshness. If data changes frequently or the page count makes builds excessively long, pure SSG can stop being practical.
SSR: when content must be fresh or depends on the current request
SSR generates HTML on the server for a specific request. It can therefore use fresh data, headers, cookies, localization, query parameters or other information available only at request time. [6][10][11]
For SEO, the content arrives as HTML without requiring client-side rendering first. The cost is server work per request and potentially higher TTFB if rendering or data fetching is slow. web.dev calls out this trade-off explicitly. [6]
SSR does not mean every part of a page must be dynamic. Stable sections can often be cached while only request-dependent data remains dynamic.
ISR: static HTML with controlled freshness
ISR keeps the benefits of static HTML while allowing selected pages to be refreshed after deployment without rebuilding the entire site. Next.js describes ISR as updating static pages after the build, while Nuxt 4 offers similar per-route behavior through `isr` and `swr`. [9][13][16]
It fits product catalogs, articles, documentation, category pages and other public content that changes periodically but does not require absolute real-time accuracy.
Teams must understand their platform's cache semantics. In stale-while-revalidate models, the first visitor after expiry can receive the stale version while regeneration happens in the background. [13][16]
CSR: best for applications that do not need indexing
With CSR, the browser downloads, parses and executes JavaScript before it can construct much of the DOM. web.dev notes that growing JavaScript bundles can hurt responsiveness and INP, especially on mobile devices. [6][7]
Nuxt lists client-rendered SaaS applications, back-office tools, games and other highly interactive interfaces that do not need indexing as suitable cases. [13]
For public content, CSR increases dependence on crawler JavaScript execution. Google recommends testing such sites carefully and still points to server rendering or prerendering where possible. [1][2]
SEO and performance comparison
| Mode | When HTML is generated | Content in initial HTML | Freshness | Request-time cost | SEO |
|---|---|---|---|---|---|
| SSG | Build time | Yes | Until next build | Very low | Very strong |
| ISR | Build or revalidation | Yes | Depends on revalidation | Low | Very strong |
| SSR | Each request | Yes | Very high | Higher | Very strong |
| CSR | In browser | Often limited | High after fetch | Low server cost, higher client cost | Possible, but less optimal |
There is no universal ranking such as `SSG > ISR > SSR > CSR`. SSG and ISR usually have cost and caching advantages for content shared by all users. SSR wins when freshness and request-specific data matter. CSR gives the browser maximum application responsibility but also moves more rendering work to the client. [6][9][13]
For SEO, SSG, ISR and SSR can all return meaningful HTML immediately. CSR can be indexed by Google, but it requires the additional rendering stage and depends more heavily on JavaScript execution. [1][9]
Core Web Vitals: rendering mode is only one part of performance
| Metric | Good | Poor | What it measures |
|---|---|---|---|
| LCP | ≤ 2.5 s | > 4.0 s | Loading of the main content |
| INP | ≤ 200 ms | > 500 ms | Interaction responsiveness |
| CLS | ≤ 0.1 | > 0.25 | Visual stability |
Google uses Core Web Vitals in its ranking systems, but explicitly says good scores do not guarantee top rankings. The current metrics are LCP, INP and CLS. [4][5]
The recommended good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1, evaluated at the 75th percentile of visits. [4][8]
SSG can improve HTML delivery while still producing poor INP if the page ships too much JavaScript. SSR can improve first paint but a slow backend can hurt TTFB. CSR may feel fast after browser caching, yet its first visit must still pay for JavaScript download and execution. [6][7]
Hydration: SSR does not finish when HTML reaches the browser
Many frameworks hydrate SSR or SSG output by attaching application state and event handling after HTML arrives. web.dev warns that full rehydration can increase TBT and hurt INP even when the first content appears quickly. [6]
A page can therefore look ready while interactions remain blocked for a period. The presence of SSR alone is not proof of good interaction performance.
Teams should minimize client JavaScript and use code splitting, lazy loading and partial or delayed hydration where the framework supports it. Nuxt 4 documents mostly-static patterns that can ship almost no JavaScript for content pages. [7][14]
Caching and data freshness: the key difference between SSG, ISR and SSR
SSG assumes a generated result can be reused until the next build. ISR adds revalidation. SSR can generate a new response for every request, but it can also be combined with server or CDN caching. [6][13][16]
The rendering choice should therefore start with the maximum acceptable age of data. If a product description may lag by a few minutes, ISR can be a good fit. If an account balance must be current for the logged-in user, full-page static caching is usually inappropriate.
A strong cache model should be tied to real content changes whenever possible rather than an arbitrarily short TTL chosen only to create the appearance of freshness.
SEO does not end with rendering
Meaningful HTML helps crawlers understand content, but it does not replace correct HTTP status codes, crawlable links, canonicals, sitemaps, titles and metadata. Google recommends that important content has its own URL and is reachable through crawlable links. [1][2]
A poorly implemented SSR page can still return 200 for errors, omit canonical tags, create duplicates or generate invalid metadata. A well-built CSR page can still be indexed correctly by Google. Rendering is one part of technical SEO, not a substitute for it.
Google no longer recommends dynamic rendering as a long-term solution for JavaScript SEO. It recommends server-side rendering, static rendering or hydration instead of maintaining bot-specific output. [3]
What to choose for common page types
Landing pages, blogs, documentation and informational pages usually fit SSG. Large catalogs or news content that changes periodically often fit ISR. Public pages with request-specific data may require SSR. Authenticated account areas and internal tools can often remain CSR. [9][13]
An e-commerce application can mix several approaches: a static category shell, ISR for product pages, SSR for session-dependent cart data and CSR for interactive filters after the initial load.
The choice should be made per route, and modern frameworks increasingly allow it at an even finer UI level.
2026 reality: frameworks are moving beyond one rendering label per page
Next.js 16.3.4 documents Cache Components, `use cache`, data and UI revalidation, a static shell, and streaming for request-time data. The current caching guide was updated on August 25, 2026. [11]
Nuxt 4 allows `prerender`, `ssr`, `swr` and `isr` to be configured per route through Route Rules. One application can therefore contain static, revalidated, server-rendered and client-rendered sections. [13][14]
SSR, CSR, SSG and ISR remain useful mental models, but they no longer describe every modern application precisely at the component level.
How to move a CSR application toward SEO without rebuilding everything
First identify the public routes that are actually expected to acquire organic traffic. There is little value in moving a private dashboard to SSR just to make the whole application use one rendering model.
Then move critical content, titles, metadata and links into HTML generated before client JavaScript runs, while leaving truly interactive behavior on the client. Google recommends SSR or prerendering over dynamic rendering for JavaScript-dependent public content. [1][3]
Finally validate the result with Search Console, rendered-HTML inspection and field Core Web Vitals. A rendering migration by itself does not guarantee an SEO or performance improvement.
A practical decision rule
If a page can be generated ahead of time and the content is shared by everyone, start with SSG. If it changes periodically, consider ISR. If the result must depend on the current request and should be present in HTML, use SSR. If the page is a private application and SEO is irrelevant, CSR is often sufficient. [9][13]
Then validate that decision with production data: TTFB, LCP, INP, CLS, server cost, content-change frequency, page count and personalization requirements.
- Must the important content be indexed?
- Can the HTML be generated before the request?
- How fresh must the data be?
- Does the result depend on cookies, session or request data?
- How many routes must be generated and how long does the build take?
- Can the page be safely cached?
- How much JavaScript must the browser execute?
- What are real production LCP, INP, CLS and TTFB values?
