Рендеринг на стороне сервера – SSR, разве это не то что всегда делал PHP?

Александр ранее правильнее ответил, SSR это решение конкретно для seo придуманное в основном, генерить статику для ботов при использовании SPA. А дальше все преимущества SPA можно почитать, в основном это разделение приложений, то есть вэб морда становится таким же приложением как мобильное на андроиде и любое другое, уже нет зависимости от технологии на бэкенде. Я уже стараюсь делать именно такие проекты, с учетом что уже есть много готовых инструментов, а манипулировать например страницей сильно удобнее во вью и реакте, чем через какой нибудь jquery пытаться строить сложную страничку

Манипулировать страницей совсем просто и удобно в WP
генерить статику для ботов ?🤣 Так генери кэшироваинием, в чем сложность?
SSR это решение конкретно для seo придуманное - это решение, сказки про seo

уже нет зависимости от технологии на бэкенде - И куда она делась, эта зависимость? Или точнее, куда ты ее перенес, эту зависимость?)))

PS Т.е не пытаюсь тебе, что то доказать или сказать что, что то плохо делаешь...нет. Во всем этом вижу ложь как у инфоциган, докажи обратное))

Ну где уж нам, так, погулять вышел, настоящие пишут на WP. Хочешь тыкнуть - тыкаю:

Что по твоему есть клиент??? 

Набор слов без понимания работы. Не имеет значения способ формирования страниц, в данном случае все это SSR. Рендеринг на стороне сервера. В случае СПА серверу отдается JS- код, который формирует страницу используя мощности клиента + возможность общения с бэкендом по АПИ. 

Хороший фреймворк  это умеет. Не обязательно с использованием JS-фреймворков. По факту любая старниуа состоит из блоков , которые кэшируются и не перегружаются заново каждый раз. Меняется только динамический контент. 

Вопрос в том, что когда WP перестанет справляться придется переделывать весь проект, совсем прям весь.

Еще раз объясняю, есть SPA приложения, когда весь роутинг на клиенте, весь рендер в браузере, а любой запрос страницы это просто вызов где то на бэкенде api которые вернет json, но в такой парадигме первый запрос сайта возвращает просто JS без контента, что негативно сказывается на сео, для этого придумали SSR чтобы тот же самый JS код который делает запросы на бэк и генерирует страницы в браузере смог при первом запросе отработать на сервере и вернуть сразу контент, а после этого уже стартовала SPA.

Смотрите по классике вы делаете запрос каталога интернет магазина, подгружается шапка, там не знаю в ней акции, какие то блоки маркетинговые, корзина, избранное, футер, менюшки всякие, фильтра, дальше клиент переходит на страницу номер 2 по пагинации, в WP надо будет все это снова загрузить, в SPA придет просто json с новой партией товара и перерендерится только блок со списком товаров, в этом и достигается скорость работы.

При чем тут сказки, я выше описал как работает технология, SPA это просто js, а чтобы SPA приложения могли индексировать (вообще физически имели такую возможность) боты, то придумали SSR, это не то что какая то улучшался для сео, я так понимаю вы воспринимаете SSR как какую то инфоциганскую пилюлю которая любой сайт ставит в топы, но нет, это технология для возможности отрендерить JSом контент на сервере чтобы боты его в принципе получили

Зависимости от технологии, а не от бэкенда. Например у меня есть проект, там витрина работает на go, а пользовательское окружение на битриксе, а все дело в том что SPA работает с неким контрактом API которое на выходе выдает данные в JSON, а вот кто эти данные ему отдает, приложению полностью фиолетово, и масштабировать сильно проще, когда у тебя есть какой то нагруженный микросервис за апишкой, то масштабировать проще его одного чем целый монолит. Например на том же проекте если посмотреть статистику, то на каталог прилетает примерно 10-12 запросов в секунду, а на корзину всего 0.4

Поэтому для каталога используется другая технология, а уж корзину и битрикс свободно вытянет

Ложь то в чем хоть? Примеров то много, так работает например сайт эльдорадо, диван ру или например фабрика пуше у них пошустрее проект, можно зайти на проект открыть вкладку Network там выбрать таб Doc и увидеть что при переходе по страницам запросов на сервер не будет вообще

Это понятно, для больших сайтов и товарок. И вместо ajax использование SPA проще. Вкурил, что запросов ajax больше, если сравнивать с PHP)

Но вопрос у ТС вопрос школьный:
в SPA придет просто json с новым контентом и перерендерится только блок с новым контентом, в этом и достигается скорость работы.
Как понимаю, для ясности - Это скорость доставки контента, например с бесголового WP или любого другого PHP?

Дальше - SSR это технология для возможности отрендерить JSом контент на сервере чтобы боты его в принципе получили
Вопрос: В чем выражается результат после SSR рендеринга?

1. Нет, не то

2. Выигрыш очень сомнительный на расстоянии

В целом да, так как апи проектируется согласно каких то правил, то запросы сильно упрощаются, бэкенд начинает генерировать меньше запросов в БД, эффективнее работает кэш. Например статья не меняется раз в сутки в кеше, а комментарии в кеше например всего 15 минут и так далее или при добавлении комментария можно скинуть кеш только для запросов комментария, а для все страницы кэш не скидывать ну и так далее.

Просто верстка с контентом, проблема SPA в том, что результат без SSR это просто пустой div и пачка стилей и скриптов, без контента совсем. В общем SSR это необходимость для SPA приложений если хочется еще и с сео работать, если на сео пофигу, например это какой то личный кабинет, то SSR обычно отключают чтоб не нагружать сервер и не ловить ошибки ненужные

Это не обязательно для больших, на самом деле в этот то и фишка что инструменты уже взрослые что можно это использовать для всего, можно в целом взять nuxt там есть nitro как сервер и в целом запустить простой проект просто с нодой на бэкенде в рамках одного языка и асинхронного подхода, все это будет работать в целом быстрее чем на php и создавать меньше нагрузки, а дальше уже можно часть запросов перевести на какой то другой бэк, так как SPA приложению в целом пофигу куда отправлять запросы за данными. Есть сейчас много ноукод решений прикольных в виде БД, вот она и хранилка всяких статей, комментариев и прочее, в рамках одной системы можно держать бэк для нескольких сайтов не открывая админку в целом в мир. Там можно много для себя плюсов найти, технологии то не стоят на месте, хотя есть проекты которым и WP за глаза и за уши хватает, я ничего против не имею так то. Мне в целом вот такая штука понравилась https://www.contentful.com/ но и в целом безголовых cms сейчас достаточно много, когда все таки фронт не зависит от бэкенда это дает достаточно много преимуществ

Т.е результат SSR - верстка с контентом, т.е HTML файл, точно такой же как и после кэширования ( или самого PHP).
Т.е никакого улучшения SEO нет - файл один и тот же при прочих равных данных и условиях.
То, что изначально и написал для ТС

Спасибо за штуку, поизучаю, а то лень достала🤣
Все само работает, есть желание ...сломать один из сайтов🤣

Со SPA как раз то, что надо, чтобы проект переделать, но партнера никак не уломать (там все скрипты еще с нулевых).

Для развития мозгов подойдет🤣