В чем суть SSR (Server Side Rendering)?

Question

[Иван Веков]

Читал-читал про SSR, и не понимаю в чем соль. Почему считается, что это должно работать быстрее для пользователя? Или точнее даже - чем это отличается от любого сайта созданного до понятия "SSR"?

Ведь, если я не ошибаюсь, суть подхода в том, что сначала один js получает от другого js, некий json, конвертит его в строку, и вставляет в хтмл.
Тут вопрос. А зачем? Если сервер мог сразу сгенерить страницу с итоговым хтмл...

Получается нужно знать express, babel, webpack, какой нибудь там next/nuxt или как их там... Или же просто взять и на условном рнр, без знаний десятка доп технологий, написать index.php, в котором уже будет всё сгенерировано и так же отдано пользователю.

Answer 1

[Константин Б.]

Вы путаете немного понятия. Ну или много путаете) SSR на PHP это когда вы используете его как шаблонизатор. Но сейчас не то время когда все пишется на одном только PHP. Сейчас очень много браузерной логики и интерактивности. И удобнее и производительнее использщовать SPA приложения. Но у них есть минус, их не видят поисковые роботы и пользователь видит хоть какой-то контент только когда получит весь JS. Для этого и используется SSR SPA приложения. Это процесс когда пользователю при первой загрузке страницы отдается HTML с сервера, а все дальнейшие манипуляции с ним происходят на клиенте внутри SPA

Если вы пользуетесь фреймворками Vue/React то для них есть решения Nuxt.js/Next.js которые являются по сути обертками удобно реализующими SSR этиъх приложений. Что касается терминов, Express в случае этих решений вам не понадобится. А вот babel, webpack в любом случае придется использовать, так как они нужны для работы не только SSR но и сборки и работоспособности клиентского JS

Comments

[Иван Веков]

Ну я на самом деле и не говорил про SSR на PHP. РНР я привел как пример "старого" подхода.

И как раз вопрос в том, зачем эти "новые подходы" нужны. Например, мы писали SPA еще лет 10 назад, используя PHP + Jquery. И как бы этот вариант идеально воспринимали поисковики даже в те времена.

А сейчас слышу как восторгаются тем, что появились технологии позволяющие формировать html на стороне сервера... И не понимаю в чем прикол.

И вот не пойму - получается то, что мы делали самописные SPA через PHP+Jquery - это было SSR? А зачем сложности с JSON и прочими вроде бы лишними историями?

[Константин Б.]

Иван Веков, PHP + Jquery это не SPA. Поисковики и сейчас SPA не воспринимают никак, а уже 10 лет назад тем более. Вы к нам может из другого времени прилетели? Джедай jQuery? Угадал?
Ваш вопрос из серии я говнокодил на jQuery и у меня все хорошо было, зачем вы модники придумали все это новое и пользуетесь этим педики?

[Константин Б.]

Иван Веков, то что вы там городили это ад. Например вам нужно было взять кусок кода на сервере, отрендерить и внедрить на странице через jQuery. Отделение фронта от бека сейчас нормальная практика. Возмем какой-нибудь сервис где есть сайт, даже его две версии (мобайл, десктоп) и пара, а то и тройка нативных приложений. Зачем городить огород если можно написать один API бекенд и обращаться к нему со всех приложений и сайтов без размножения бизнес логики внутри каждого.

Answer 2

[Радость моя]

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

говорят ща работы умные, и генерацию понимают, но раз этот инструмент все еще есть - значит есть и не очень умные роботы, которым надо сразу разжеванный текст подавать.

Comments

[Иван Веков]

Так а ведь любой старый сайт работает так же, нет? Отдает сразу читаемый вид html. Будь то рнр или что еще.

Или эта вся история с SSR чисто для сайтов полностью на JS? Хотя и тут мимо. Я 5 лет назад писал на ноде, и тоже передавал пользователю с сервера полную хтмл страничку.

[Константин Б.]

Иван Веков, вы не понимате просто про что спрашиваете видимо. У вас все одно и тоже. Да SSR нужен для тех сайтов которые полностью написаны на JS и устроены для полноценной работы внтури браузера обмениваясь по HTTP только лишь данными, так же как это делают например нативные приложения. То что вы писали на ноде не было как таковым приложением. Вам нужно понять что такое изоморфные приложения, наверное станет понятнее

Answer 3

[Арсений Матыцин]

Динамические сайты, которые все больше занимают места на рынке, в виде загруженной html страницы представляют собой обертку типа:

<html>
   <head>...
   <body>
       <p>Сообщение, которое будет отрисовано, если у юзера выключен JS</p>
       <script src="скрипт, генерирующий внешний вид и логику">
   </body>

Т.е. данных нет. Из минусов:
1. Роботы, которые не ждут отрисовки страницы просто не получают никаких данных.
2. Пользователь получает данные тогда, когда они у него будут отрисованы, что создает некоторую задержку.

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

Comments

[Иван Веков]

Добрый день, спасибо за ответ.
То есть по сути, когда мы десяток лет назад делали библиотеку, которая реализовала некий SPA через аякс (для пользователей, которые не роботы, - href'ы заменялись на OnePage.Load('href') и без перезагрузки всей страницы подгружалась нужная область, сгенерированная на php на сервере и возвращенная в виде html разметки), то получался как раз по сути SSR только для другого стэка?
Понятно что это не так продумано и круто было как тщательно проработанные nuxt'ы и react'ы, но суть та же?

Я правда пока еще не очень понимаю зачем вообще столько заморочек, но думаю проблема в том, что я всегда был слишком "бэковым". Стоит получше познакомиться с современными фронтовыми фреймворками и думаю тогда придёт лучшее понимание)

[Арсений Матыцин]

Иван Веков, нет, суть не та. Все, что загружается асинхронно, кем бы оно ни было сгенерировано это не SSR. SSR это уже заготовленные нужные страницы в момент её получения. Все что «без перезагрузки» это уже работа фронта и только.

В принципе, если убрать асинхронное получение заготовленной страницы, то и получается SSR. Фикус в том, что современный фронт полностью строится на JS. Некие данные, шаблоны, получения данных по веб-API, вычисления и т.д. Вот для неё и нужно SSR. Бэк и фронт разделены полностью, общение происходит запросами.

Хотя все еще существует генерация страниц бэком и частичная интеграция фреймворков.

Answer 4

[Алекс Глебов]

Реактивные spa фреимворки обеспечивают перерисовку интерфейса при изменении данных. Это гораздо более удобный подход, чем jquery. Плюс есть организация кода из коробки. Замороченный интерфейс можно написать меньшим количеством кода и более структурировано.
Если у вас данные на странице не меняются при взаимодействии с пользователями, то это вам не нужно.
https://youtu.be/LV235z6qOUI
https://youtu.be/4xyb_tA-uw0

А ssr это просто костыль для поисковиков, когда они научатся индексировать spa, от ssr откажутся.

Comments

[Владимир Коротенко]

Ну это вы зря. Есть ещё аспект в том что быстрее отображается на клиенте