В чем заключаются недостатки серверного рендеринга (SSR)?

Основные недостатки SSR:

• Увеличение нагрузки на сервер: Каждое клиентское обращение требует полного рендеринга страницы на сервере, что потребляет больше ресурсов (CPU, память) по сравнению с отдачей статических файлов или SPA.
• Сложность разработки: Требуется учитывать изоморфность кода (работу на сервере и клиенте), управление состоянием между запросами, обработку асинхронных данных. Отладка может быть сложнее.
• Downtime при ошибках сервера: Если основной сервер, отвечающий за рендеринг, выходит из строя, сайт может стать недоступным, в отличие от SPA, где клиент может продолжать работать с закэшированными ресурсами или fallback-страницей.
• Более длительное время до интерактивности (TTI): Хотя первый контент появляется быстрее (FCP), пользователь не может взаимодействовать с приложением до тех пор, пока на клиенте не загрузится и не выполнится весь JavaScript (hydration). В SPA интерактивность может появиться раньше на уже загруженных частях страницы.
• Сложность кэширования: Кэшировать динамически генерируемый HTML сложнее, чем статические ресурсы. Требуются более изощренные стратегии кэширования серверной стороны.
• Более высокий First Byte Time (TTFB): Серверу требуется время на обработку запроса, получение данных, рендеринг HTML и отправку первого байта обратно клиенту.
• Могут возникнуть проблемы с изоморфным кодом: Некоторые клиентские API (например, window, document) недоступны на сервере, что требует написания условного кода или использования специальных библиотек.

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