Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Недоліки SSR». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**SSR** порівняно з **CSR** має низку недоліків: підвищене навантаження на сервер, вищий TTFB, складнішу архітектуру, дублювання логіки між сервером і клієнтом та можливі помилки гідрації. **Ключове:** сервер повинен виконати код застосунку, зібрати дані й відрендерити HTML при кожному запиті, тоді як CSR просто віддає статичний файл.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)Зображення## 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 if (typeof window !== 'undefined') { ... } ``` **Наслідок:** більше умовного коду і потенційних помилок. --- ## Підсумкове порівняння | Недолік | SSR | CSR | |---|---|---| | Навантаження на сервер | висока | низька | | Затримка TTFB | вища | нижча | | Архітектурна складність | висока | проста | | Навігація між сторінками | вимагає доопрацювання | миттєва (SPA) | | Кешування | обмежене | просте (через CDN) | | Можливі помилки гідратації | є ризик | немає | | Доступ до браузерних API | обмежений | повний |Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.