Какви са недостатъците на сървърното рендиране (SSR)?

Основните недостатъци на SSR:

• Увеличаване на натоварването на сървъра: Всяко клиентско искане изисква пълно рендиране на страницата на сървъра, което консумира повече ресурси (CPU, памет) в сравнение с предоставянето на статични файлове или SPA.
• Сложност при разработката: Необходимо е да се вземе предвид изоморфизмът на кода (работа на сървъра и клиента), управлението на състоянието между заявките, обработката на асинхронни данни. Отстраняването на грешки може да бъде по-трудно.
• Време на престой при грешки на сървъра: Ако основният сървър за рендиране се повреди, сайтът може да стане недостъпен, за разлика от SPA, където клиентът може да продължи да работи с кеширани ресурси или fallback страници.
• По-дълго време до интерактивност (TTI): Въпреки че първото съдържание се появява по-бързо (FCP), потребителят не може да взаимодейства с приложението, докато цялата JavaScript (хидратация) не бъде заредена и изпълнена на клиента. В SPA интерактивността може да се появи по-рано на вече заредените части на страницата.
• Сложност при кеширането: Кеширането на динамично генерирания HTML е по-трудно, отколкото на статичните ресурси. Необходими са по-усъвършенствани стратегии за кеширане на сървърната страна.
• По-високо време за първия байт (TTFB): Сървърът трябва да обработи заявката, да получи данни, да рендира HTML и да изпрати първия байт обратно към клиента.
• Могат да възникнат проблеми с изоморфния код: Някои API на клиента (например, window, document) не са достъпни на сървъра, което изисква писане на условен код или използване на специални библиотеки.

// Пример за условно рендиране на сървъра
if (typeof window === 'undefined') {
  // Код, който се изпълнява само на сървъра
  console.log('Рендиране на сървъра');
} else {
  // Код, който се изпълнява само на клиента
  console.log('Рендиране на клиента');
}