Недоліки SSR

#1. Підвищене навантаження на сервер

• При кожному запиті сервер повинен:
  • виконати код застосунку,
  • зібрати дані,
  • відрендерити HTML.
• На відміну від CSR, де сервер просто віддає статичний файл, SSR вимагає значно більше ресурсів.

Наслідок: для високонавантажених проєктів SSR-сервер може стати вузьким місцем і потребувати масштабування.

---

#2. Вища затримка (TTFB)

• При SSR серверу потрібно виконати логіку і рендеринг, перш ніж віддати відповідь.
• У CSR сервер одразу повертає порожній HTML і JS-бандли, тому час до першого байта (TTFB) зазвичай менший.

Наслідок: хоча перший контент з'являється швидко, час відповіді сервера вищий, особливо при складних сторінках.

---

#3. Складність архітектури та інфраструктури

• SSR-застосунок вимагає:
  • окремого серверного середовища (Node.js),
  • налаштування маршрутизації, кешування і балансування,
  • продуманої синхронізації стану між сервером і клієнтом ("гідратація").

Наслідок: DevOps-налаштування і CI/CD стають складнішими, ніж у чистого SPA.

---

#4. Дублювання коду і логіки даних

• Потрібно писати код, який працює і на сервері, і на клієнті (універсальний / ізоморфний JS).
• Наприклад, при завантаженні даних у Next.js через getServerSideProps треба думати, як не продублювати API-запити при гідратації.

Наслідок: більше точок помилок, складніше налагоджувати і підтримувати.

---

#5. Повільна навігація між сторінками (без SPA-оптимізацій)

• Якщо не реалізувати клієнтський роутинг (як робить Next.js), то кожен перехід між сторінками викликає новий запит до сервера → сторінка перемальовується повністю.

Наслідок: без оптимізацій UX може бути "важчим", ніж у CSR-SPA.

---

#6. Складніше кешувати результат

• У CSR можна кешувати статику на CDN.
• У SSR HTML-відповідь динамічна, і кешувати її безпечно можна не завжди (особливо при персоналізації).

Наслідок: вище навантаження, складніше контролювати продуктивність.

---

#7. Потенційні проблеми з гідратацією

• Після завантаження сторінки клієнтський JS має "з'єднатися" з серверним HTML (гідратація).
• Якщо структура DOM на сервері і клієнті відрізняється, виникають помилки на кшталт "Hydration failed because the initial UI does not match what was rendered on the server".

Наслідок: вимагає уважної синхронізації стану і рендер-логіки.

---

#8. Обмеження середовища

• Серверний рендеринг виконується в Node.js, а не в браузері:

  • не можна використовувати window, document, localStorage та ін.

  • доводиться писати умовні перевірки:

    javascript

    Copy

    if (typeof window !== 'undefined') { ... }

Наслідок: більше умовного коду і потенційних помилок.

---

#Підсумкове порівняння