Glossary
Server-Side Rendering (SSR)
Rendering a page’s HTML on the server for each request, so the browser receives finished markup first and JavaScript then hydrates it. Real-time chat components are the classic case for opting out on the client.
General definition
Server-Side Rendering (SSR) means the server runs your UI code, produces the full HTML for the requested page and sends it to the browser, which shows it immediately. The JavaScript bundle then loads and hydrates the page: React walks the existing markup, attaches event handlers and takes over rendering from that point. Compared with client-side rendering (CSR), where the browser downloads an empty shell and builds everything in JavaScript, SSR gives faster first paint, content that search engines and link previews can read without executing scripts, and a better experience on slow devices.
The rendering strategies teams choose between:
- SSR: HTML generated per request. Best for pages that differ per user or change often.
- Static site generation (SSG): HTML generated at build time and served from a CDN. Best for content that rarely changes.
- Incremental or on-demand regeneration: static pages refreshed on a schedule or a trigger.
- CSR: everything rendered in the browser. Simplest for authenticated dashboards where SEO does not matter.
- Streaming SSR and React Server Components: the server streams HTML in chunks and some components never ship JavaScript at all. The Next.js App Router is built on this model.
The rule that catches most teams is that the server render and the first client render must produce the same markup, or React reports a hydration mismatch. Anything that depends on the browser, such as window, local storage, the current time zone or a live network connection, cannot run during SSR. That is why real-time components are rendered client-only: a chat window that opens a WebSocket and needs the user’s token has nothing meaningful to render on the server. In Next.js this is a component carrying the use client directive, loaded through next/dynamic with ssr: false, or rendered only after an effect confirms it is running in the browser. The page shell, navigation and any static content still benefit from SSR.
In the Ethora ecosystem
The Ethora React chat component is a client-side component by design: it authenticates with a short-lived chat token, opens the real-time connection to the XMPP backend from the browser and keeps room state on the client. In a Next.js or Remix app you render it on the client only, inside a client component and, in Next.js, through a dynamic import with SSR disabled, while the rest of the page (marketing content, dashboards, help articles) renders on the server as usual.
This is the normal shape for a real-time feature and it costs nothing in SEO, because chat content is private and should not be indexed anyway. What you gain is a server-rendered shell that paints instantly, then a chat panel that connects once the user and token are known. The same client-only rule applies to any live widget, including the embeddable AI assistant from the AI SDK, which runs in an iframe from a script tag and therefore never touches your server render.
