Теперь пусть кто-то пояснит, чем SSR лучше пререндинга?

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

я делал кастомный пререндеринг, без библиотек все данные пункты не верны третий вообще не понял - причем тут UX?

Без библиотек - это прям с webdriver/chrome-devtools-protocol?) Нагрузка на сервер от renderToString(vue) меньше, чем от рендеринга страницы в хромиуме. Если не учитывать кэширование, но с ним вопрос, как много надо кэшировать и как долго можно держать. С чего неверный пункт, что "SSR можно делать частичный" - не понял. А последний пункт ты не понял, но он всё равно не верный?)

UX - с LCP (TTC)

Нет сразу видно чистого фронта ) У меня был новостной сайт Каждый раз когда добавлялась/менялась статья, на сервере появлялся статичный файл с ее текстом для поисковых ботов по соответствующему пути 20 строчек PHP кода Индексация для ботов была только нужных страниц (статьи и меню главной страницы с категориями новостей). Вот частичная индексация Затраты работ на бэке уверен были на порядок ниже мучений с SSR или headless браузерами Ну и причем тут UX и медленность? У юзера в браузере обычный SPA сайт Они все это SEO замуты не видят и не чувствуют Как и фронтэнд девелоперы

"сразу видно чистого фронта" Ну тут не знаю чем помочь. Если на таком уровне вести дискуссию, то тут к окулисту :) Описание новостного сайта - пример слабо динамического контента. А при добавлении каждого коммента тоже генерилась заново страничка? А если автор статьи поменял свое имя? И под пререндером обычно (и по картинке от тебя же) имеют в виду рендер именно того контента, что получает юзер, а не иного с содержимым. Про затраты на разработку я ничего не писал, SSR понятно сложнее. Я писал только про инфраструктуру. Про сравнения быстрого рендера в строку компонента без реактивности в сравнении с запуском VDOM в браузере. Причем тут UX - это вопрос про то, как WebVitals с UX связан?

а чо, "чистый фронт" уже оскорбление? А при добавлении каждого коммента тоже генерилась заново страничка? А если автор статьи поменял свое имя? И под пререндером обычно (и по картинке от тебя же) имеют в виду рендер именно того контента, что получает юзер, а не иного с содержимым.

ничем, это разные инструменты. выбирайте тот, который лучше подходит под ваши требования и задачи. не вижу смысла в дискуссии

А что, "чистый фронт" уже чем-то оскорбление? А при добавлении каждого коммента тоже генерилась заново страничка? А если автор статьи поменял свое имя? И под пререндером обычно (и по картинке от тебя же) имеют в виду рендер именно того контента, что получает юзер, а не иного с содержимым. Все эти задачи решаются по мере поступления, и опять же намного проще чем с SSR Комменты? они свои или какой-нибудь Disguis? Решается и то и то, по-разному Автор статьи должен иметь возможность менять имя? Очень редко и вряд ли на новостных сайтах, где надо отвечать за себя Но если очень хочется, то можно написать 20 строчек кода, которые будут брать из базы статью с актуальными данными и отдавать ее боту. Поначалу у меня так и было, но при 10К+ статьях боты стали ощутимо грузить сервер, а хостер - меня. Пришлось переписать на статику. Ботов реально много, не только поисковики и вебаркайверы. Повторю - всё решается, и намного проще чем с SSR. По крайней мере, для новостных сайтов, магазинов и прочих с подобной структурой контента Насчет рендера того же контента - контент это текст, а не дом структура. Рекомендации гугла - https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering?hl=ru. Кошечки != собачки. Текст был тот же у меня в статике. Небольшие изменения роли не играли. Всё работало на практике.

"Чистый фронт" - не оскорбление. "Сразу видно чистого фронта" - оценочное суждение (на основе ощущения в голове, без аргументов, ещё и ложное) - токсичненькое оценочное суждение. Использование его в аппеляции - ошибка аргументации. Но простительно для фуллстека самоучки :) (Отзеркалил для демонстрации) Про простоту решения повторю ещё раз - ничего не говорил. SSR реализовать сложнее, чем pretender за минуты подключить. Я писал только про производительность и нагрузку на инфраструктуру, если все не лежит в итоге в кэше. Оба варианта - и prerendering, и ssr подразумевают рендеринг того контента, который непосредственно видит конечный пользователь. prerendering работаете буквально в браузере как юзер. SSR отдает поисковику и юзеру один контент. Какое отношение имеет твой пример к одному из этих вариантов - не понятно. Пример в статье, которую ты скидываешь - про рендеринг в браузере на сервере, а не про генерацию отдельных особых страниц для роботов. Котики не собачки :)

Это разные инструменты для одной цели, значит их можно сравнивать Тем более тут так много прямой и косвенной рекламы Nuxt, почему нельзя порекламировать другие способы? И "сразу видно чистого фронта" - это да, оценочное суждение о разрабе, который выбирает сложные навязываемые решения, когда вполне есть проверенные, уже несколько десятилетий используемые, но не связанные с фронтом, которые позволяют писать чистый SPA, чистый концентрированный user friendly SPA на Vue или React или JS безо всяких ограничений, без Node.js на сервере, и без всяких прочих мучений со ssr-анными заморочками ssr-анного фреймворка

а че случилось?

ничо ) дискуссия вроде по архитектурам фронтенда

забей тогда, главное что бы работало :3

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

Какой смысл обсуждать разницу без оценки "лучше" (с точки зрения DX естественно)?

без контекста задачи и требований - никакой