Comments 42
Это конечно такой сюр, старательно отобрать рендер у бэка переведя в фронт говоря что «это долго, быстрее собрать страницу на фронте без перезагрузок дергая апи», что бы потом вернуть рендер на бэк с точно такими же оправданиями. Смешно.
"Тут всё не так однозначно"
Началось всё это "асинхронное" достаточно бодро - с фреймов (помнит интересно их еще кто-то? имхо, незаслуженно убитая технология), потом с развитием интернета на нормальных скоростях фреймы благополучно почили и люди стали делать "нормальные" страницы (хотя баннеры в iframe вроде до сих пор живы кое-где), потом "фреймы" возродились в виде асинхронных подзагрузок нужного контента во время навигации и это было хорошо и вот тут и надо было остановиться, но потом....
потом что-то пошло не так и абсолютно весь контент стало модно грузить асинхронно, даже первую страницу, где подгружаемый контент изначально однозначен. При этом лозунг "грузим меньше что бы быстрее" как-то потерялся, потому что для асинхронной подгрузки стали использовать такие фреймворки, размер которых больше сотни отрендеренных заранее страниц, а грузится каждый раз не крошечный кусок контента, а какая-то гора мусора. И вишенкой на торте идет тот факт, что собственно говоря при переходе на какую-нибудь другую страницу - один черт перезагружается вся страница, просто асинхронными кусками.
И вот это как говорится уже batshit crazy, потому что сейчас вот даже на хабре иногда открываешь страницу и .... пялишься на 2-3 серых квадрата. Которые до кучи еще не всегда с первого раза загружаются и приходится тыкать кнопу перезагрузить страницу, что бы они наконец отобразились. А при тыкании на ссылке где-то - всё равно все грузится заново, уроки подзагрузки только нужного контента во время навигации забыты напрочь.
Так что "шаг назад" на самом деле во многих случаях был бы полезен. Реально на кучи сайтах постоянно сидишь и пялишься на эти "серые квадраты", которые зачастую так никогда не дозагружаются, а открыв дебаг сетевых подключений и видя при каждом клике "асинхроннй загрузки" несколько десяток коннектов - перестаешь понимать как мы вообще дошли до жизни такой.
что бы потом вернуть рендер на бэк с точно такими же оправданиями
Назад возвращают потому, что поисковые системы не слишком хорошо могут в индексацию динамических сайтов. Гугл формально умеет, но с кучей нюансов. Остальные вообще нет. А это не только траффик, это ещё и такие вещи как привью при шэринге ссылок и т.д.
А они что, когда-то хорошо индексировали, а потом перестали? Это был второй пункт. А с первого Я вообще впал в ступор. Главным плюсом AJAX при его появлении считалась возможность разгрузить сервер. Потому что он один, а клиентов много. А сейчас мы делаем ровно наоборот и объявляем это преимуществом, да? На 99,9% сайтов даже картинки никто не оптимизирует. О какой производительности мы вообще говорим?
"Отобрать рендер" – что это вообще значит значит? :)
Рендер — это исполнение js-кода, предназначенного для клиента (если отбросить SSR). До массового создания SPA, кто-то так же массово запускал клиентский js для преобразования статического html? Или бэк просто отдавал странички, сгенеренные по шаблону, при обращении к определённому эндпоинту?
Мы предлагаем, прежде всего, руководствоваться здравым смыслом и рендерить на фронте то, что допустимо в конкретном кейсе.
Мне кажется, что вместо особого внимания к SSR можно просто не использовать фреймворк для разработки одностраничных клиентских приложений там, где требуется контент, SEO и производительность. А взять для этого что-то другое.
Vue хороший и удобный фреймворк для фронта который может закрыть основную массу потребностей. Что бы не плодить лишние библиотеки и поддерживать между ними связи, проще все таки использовать SSR
Так а всегда можно столкнуться с тем,что пользователю нужны сложные элементы интерфейса или ux-паттерны на фронте: будь то выпадающие списки, модальное окно с корзиной или бесконечная подгрузка. А лучший способ все это организовать - компонентный подход. Отсюда и фремворки. Но это плохо для SEO. Поэтому идея SSR и возникла.
Во-первых, производительность этого метода сильно выше — мощности сервера сильно превосходят мощности принимающей стороны, а, значит не нужно будет рендерить страницу на стороне клиента перед отображением
Но клиент не один, их много. Да и вообще это не факт, продают же виртуалки по одному ядру и 512 мегабайт RAM.
Во-вторых, у такого контента более качественная SEO-оптимизация. Страница, сгенерированная на сервере, уже содержит весь текст, и поисковые машины сразу могут корректно индексировать его и поднять в топ релевантной выдачи. Если сайт генерируется на стороне пользователя, то поисковый робот не увидит этот контент.
Только ради SEO переходить на SSR довольно болезненно, а в больших проектах практически нереально.
Да уж правильнее отдать страницу уродца поисковому роботу с контентом, правда вроде за это бьют по рукам поисковики…
Зависит от сайта. Если блоги/форумы/е-ком, то в принципе не стоило делать SPA, классические MVC-фреймворки, например, Laravel и Ruby on Rails прекрасно делают серверный рендеринг и без JS-фреймворков. А если без регистрации к продукту доступа нет, то вообще ноль смысла всё это рендерить на сервере, достаточно парочку статичных лэндингов сделать и их уже оптимизировать под поиск.
Абсолютно согласен
vue это реактивный фреймворк (поддержка SSR появляется только после подключение сервера на nodejs), а laravel это fullstack php. Чувствуешь разницу? Прости, но как laravel сделает серверный рендер реактивного компонента? Как ты думаешь зачем вообще используем nodejs?
Nuxt это фулстэк фреймворк, он не для фронта только. В режиме SSR, SSG, ISR мы используем на бэкенде nodejs, потому что передать данные от nodejs к бразерному проще, чем это делать в связке php + browser js
Во-первых, производительность этого метода сильно выше — мощности сервера сильно превосходят мощности принимающей стороны, а, значит не нужно будет рендерить страницу на стороне клиента перед отображением.
В этом утверждении неправда ну просто всё. Производительность 1 потока сервера не сильно отличается от производительности одного потока клиента, а частл и несколько ниже, потому что серверные CPU с 96 ядрами пока еще не бегают на частотах рлояжка 5-6GHz, а клиентские очень даже и бОльший кеш и остальные ресурсы не спасают потому что -- и это во вторых -- сервер разделяет все свои ядра между всеми клиентами, а клиенту не нужно разделять свою производительность на тысячи коннектов. От силы у клиента открыта пара десятков коннектов и из них рендерится от силы 2-3. Т.е. серверная производительность, хоть и выше суммарно, но поделенная на клиентов ниже, чем доступная у клиентов.
Всё что вы достигаете рендерингом на стороне сервера - это превращаете IO-bound приложение в CPU-bound. Проверьте с 1000 клиентами и убедитесь. А если у вас их меньше - ну тогда так и надо говорить - я проверил одинм клиентом и у меня получилось отрендерить на севере быстрее. Я тогда спрошу - а какие метрики свидетельствуют об этом и как они работают при увеличении нагрузки.
Вы немножко не правы, а автор немножко не договорил. SSR нужно использовать в связке с CDN (например, Cloudlfront или Cloudflare). Это значительно повышает скорость загрузки страниц по всему миру, уменьшает нагрузку на SSR и API. Мы мощные DDOS-атаки на такой схеме выдерживали, конечный пользователь новостного сайта практически не замечал (разве что переставали лайки работать, ибо были привязаны к аутентификации).
5-6GHz, а клиентские очень даже и бОльший кеш
в каких смартфонах такие мощные можно встретить?
как отметил @WondeRu 1 раз сгенерировать страницу с нужным контентом и раздавать кэш не так затратно
Сервер рендерит контент и кладет его в кеш. Да, клиенты бывают разные и некоторые могут превосходить по мощности сервер, но так же есть устройства менее производительные. Используя SSR можно быть уверенным что таким способом первая страница отобразиться быстрее. Последующие запросы с клиента уже будут рендериться на стороне клиента.
А на сколько ssr вообще необходим?
Для поисковых ботов, можно сегодня специально в шаблоне нужные части сайта показать.
Равномерная загрузка сайте это с помошью темплейтов делается.
А если надо что бы быстро сервер отдавал, ssg намного интереснее. Создал шаблоны на бэкенде и отдаешь на фрон без лишних выстрелов в голову
Отдельно на сервере делать роутинг и прочее очень не хочется. Поэтому делается один раз, а дальше распределяется, в какой момент какой кусок будет рендериться. К сожалению, поисковики очень плохо с spa работают, поэтому приходится для них делать ssr
К счастью, spa для поисковиков давно не проблема.
А в чем проблем то ? Почему они плохо работают ?
Вы видимо не совсем понимаете, почему они не видят сайт.
Даже без технологий которые nin-jin дал ссылку.
Почему боты не видели сайты ? Потому что сайт динамически в спа создается.
Вот решение проблемы.
<custom-component>
<div>Для бота, он это сразу увидит</div>
<template>
А это не для бота, он это не увидит потому что будет динамически добавляться
</template>
</custom-component>
Для поисковых ботов, можно сегодня специально в шаблоне нужные части сайта показать.
Cloaking? За него разве ПС по шапке не дают?
Каким способом рендерить контент, каждый может выбрать для себя сам, с учетом потребностей и возможностей. SSR закрывает основные требования для отображения страницы, при этом проект находится в относительно едином стиле
Попробую обосновать противоположное мнение: рендеринг — это затраты ресурсов. Раз уж пользователь зашел на сайт, раз ему нужна информация, пусть он свои ресурсы и тратит, он этого даже не заметит. А компания, владелец сервера, сэкономит немного на электричестве. ;-) Или при тех же аппаратных ресурсах обслужит больше пользователей.
при наличии альтернативы пользователь выберет для себя более удобный сайт, то есть более быстрым(меньше который ест ресурсов)
Результат работы SSR можно положить в кеш и уже оттуда отдавать клиентам. Отдав первую страницу мы сократим время отображения пустой страницы, в основной массе клиентов это будет не заметно. а вот при медленном интернете это может иногда может помочь не потерять пользователя. Последующий запросы уже будут генерироваться на стороне пользователя
Т.е. сначала вас не устроил статический html. Вы наплодили фреймворков, всяких там fetch-оберток, даже затащили js на серверы. А теперь вам не угодила скорость того франкенштейна, который вы нагородили. И теперь давайте отдавать все же на клиента статический html.
Есть нюанс – этот статический html превращается на клиенте в интерактивное приложение.
Еще нюанс – статика отдается только при первом заходе, а дальше только данные по API.
Супер, всё так и есть. Конечно "дно этого болота" в самой глобальной индустрии, нужно привлекать финансы и внимание, нужно придумывать "новое", да же там где это не нужно, чтобы отличаться от других.
Vue фреймворк который закрывает основные потребности. Как раз для того, что бы не использовать другие решения можно использовать SSR
Нормальный сайт, который не какая-нибудь корпоративная система учёта и не веб-приложение с кучей функций, должен выглядеть примерно вот так, я считаю:
А то наплодили технологий, а потом сами с ними борются.
Когда появился ChatGPT в Google схватились за голову и срочно начали пилить свой. А всё почему? Потому что народ начал искать информацию по-другому. А вы говорите SEO, SSR...
а еще SSR добавляет нотку бэкенда, поэтому формально это уже не фронтенд, а фулстэк разработка, а это снижает уровень входа в проект. Автор написал про хуки на фронте, но к этому еще добавляются хуки на бэкенде (к примеру nuxt). Технология на nodejs еще сырая и слишком рано стали использовать по дефолту. Если контент не слишком часто обновляется стоит использовать prerender (SSG, ISR)
сразу по диалогу можно распознать бэкэндеров и фронтов :)
SSR или CSR - всё зависит от типа приложения
К примеру: поисковики ну никак нормально при помощи CSR не реализуешь и напротив - приложение с интенсивной работой с данными и большим деревом роутинга реализованное на SSR - будет кошмаром для пользователя - ждать при каждом нажатии перерисовки страницы по секунде а то и более на мобильном соединении у любого пользователя не хватит терпения.
Как всегда истина где-то по середине - нужно искать баланс
Например, если по ошибке обратиться к обьекту window в хуке, в котором он не доступен, например mounted, то это приведет к развалу vue‑файла приложения, что в итоге развалит и весь SSR.
Как раз наоборот: к window можно обращаться только в mounted, SSR там не обрабатывается
SSR: ключевой элемент сайта, который требует особого внимания