@vaskadogana
Frontend developer

Зачем использовать server-side rendering? Какие преимущества у рендеринга на сервере?

Никак не могу взять в толк в чем смысл рендеринга на стороне сервера.
Мой взгляд на ситуацию (чисто мои умозаключения, так как аргументированной информации зачем, нигде не встретил, натыкаюсь только на мануалы - "пошаговая инструкция"):
плюсы:
- отдаем клиенту готовый (рендеренный) контент, (но вроде как на клиенте сейчас довольно мощное железо, а там где слабое, реакт всё равно не пойдет в силу устаревшего ПО)
- приложение отдается по фрагментам (вроде как взаимодействие происходит быстрей, за счет скорости получения данных)
минусы:
- расход лишних ресурсов сервера (насколько я понял, для каждого клиента происходит компиляция нужного компонента из исходников)
- большой тайм-аут отклика (мне так кажется, если хороший трафик большое количество параллельных процессов рендера. Или я про рендеринг не так понимаю?)
- отсутствует возможность кеширования данных на клиенте (ведь при каждом запросе новый рендер компонента)
- лишние требования к коду во время разработки (классическое redux хранилище вроде как уже не катит, нужно следить, чтобы данные не пропали при переходе по страницам.

p.s. меня привлекает возможность отдавать приложение по частям, но напрягают перечисленные мной минусы.
  • Вопрос задан
  • 28136 просмотров
Пригласить эксперта
Ответы на вопрос 2
vahe_2000
@vahe_2000

кстати очень хороший вопрос


Использовать SSR, если...
Тебе нужно с Bing, Yahoo или Baidu,Google.
У вас уже есть работающее приложение, требующее максимальной производительности, и оно готово заплатить за дополнительные ресурсы сервера.

Не используйте SSR, если...

Ресурсы сервера ограничены, возможно, из-за низкого бюджета или невозможности масштабирования.

SSR это очень круто но в некоторых случаях это имеет недостатки.

  1. Рендеринг стороне сервера помогает seo, но иногда Google может найти ваше содержание без SSR.
  2. SSR обычно повышает производительность вашего приложения, но не всегда.
  3. Это повысит сложность приложении, что означает меньше времени работы с другими функциями и улучшениями.
SSR улучшает производительность

После того как браузер загрузит HTML-и CSS, он может отображать визуализированные компоненты пользователю, не дожидаясь загрузки JavaScript или реакции на визуализацию.

Если файл JavaScript очень велик, это может быть большим улучшением.

Веб-страница не будет интерактивной до тех пор, пока не будут загружаться и реагировать на сценарии загрузки JavaScript, но предполагаемая производительность по-прежнему улучшается, поскольку пользователь видит содержимое быстрее.

SSR снижает производительность

SSR является больше работы для вашего сервера, так что ваш ответ HTTP займет немного больше времени, чтобы вернуться. Гораздо дольше, если ваши серверы находятся под большой нагрузкой.

Размер вашего HTML будет увеличена и займет больше времени для загрузки. Для большинства приложений этого должно быть незначительным, но может стать фактором, если ваш REACT компоненты содержат длинные списки или таблицы.

Другие факторы производительности

Когда один пользователь загружает несколько страниц на вашем сайте или возвращает часто, ваш JavaScript-файл должен быть кэширован. SSR обеспечит менее прирост производительности в этой ситуации.

Мы не можем сказать, производительность лучше с SSR или производительность хуже с SSR. В целом ни заявление будет верно сказать что ssr это хорошо


используйте zeit/now с zeit/next.js
наверно слышали или пробовали
Ответ написан
Комментировать
sim3x
@sim3x
Клиент - поисковый бот, который понимает только хтмл

Клиент - мобильник со слабым инетом, у него нехвататет ресурсов, чтоб всю логику через себя пропустить
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы