Suggest an editImprove this articleRefine the answer for “Disadvantages of SSR”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)Compared to **CSR**, **SSR** has a number of drawbacks: increased server load, higher TTFB, a more complex architecture, duplicated logic between server and client, and possible hydration errors. **Key point:** the server must execute the application code, gather data, and render HTML on every request, while CSR simply serves a static file.Shown above the full answer for quick recall.Answer (EN)Image## 1. Increased server load - On **every request** the server has to: - execute the application code, - gather the data, - render the HTML. - Unlike CSR, where the server just serves a static file, SSR requires far more resources. **Consequence:** for high-load projects, the SSR server can become a bottleneck and require scaling. --- ## 2. Higher latency (TTFB) - With SSR, the server has to **run the logic and rendering** before it can respond. - With CSR, the server immediately returns an empty HTML shell and JS bundles, so the time to first byte (TTFB) is usually lower. **Consequence:** although the first content appears quickly, the **server response time** is higher, especially for complex pages. --- ## 3. Architectural and infrastructure complexity - An SSR application requires: - a dedicated server environment (Node.js), - configuring routing, caching, and load balancing, - carefully synchronizing state between the server and the client ("hydration"). **Consequence:** DevOps setup and CI/CD become more complex than for a plain SPA. --- ## 4. Duplicated code and data logic - You need to write code that **works both on the server and on the client** (universal / isomorphic JS). - For example, when loading data in Next.js via `getServerSideProps`, you have to think about how to avoid duplicating API requests during hydration. **Consequence:** more points of failure, harder to debug and maintain. --- ## 5. Slower navigation between pages (without SPA optimizations) - If client-side routing isn't implemented (the way Next.js does it), then **every navigation between pages triggers a new server request** → the whole page repaints. **Consequence:** without optimizations, the UX can feel "heavier" than a CSR SPA. --- ## 6. Harder to cache the result - With CSR, static assets can be cached on a CDN. - With SSR, the HTML response is dynamic, and it's not always safe to cache (especially with personalization). **Consequence:** higher load, harder to control performance. --- ## 7. Potential hydration issues - After the page loads, the client-side JS has to "connect" to the server-rendered HTML (hydration). - If the DOM structure differs between the server and the client, errors appear such as *"Hydration failed because the initial UI does not match what was rendered on the server"*. **Consequence:** requires careful synchronization of state and render logic. --- ## 8. Environment limitations - Server-side rendering runs **in Node.js**, not in a browser: - you can't use `window`, `document`, `localStorage`, etc. - you have to write conditional checks: ```javascript if (typeof window !== 'undefined') { ... } ``` **Consequence:** more conditional code and potential bugs. --- ## Summary comparison | Disadvantage | SSR | CSR | |---|---|---| | Server load | high | low | | TTFB latency | higher | lower | | Architectural complexity | high | simple | | Navigation between pages | needs extra work | instant (SPA) | | Caching | limited | simple (via CDN) | | Possible hydration errors | there's a risk | none | | Access to browser APIs | limited | full |For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.