Drive your career as React Developer with Symphony Solutions!
×Закрыть

CSR, SSR, SSG: типы рендеринга и какой из них лучше использовать

Привет! Я — Игорь Ищенко, фронтенд-разработчик Beetroot Житомир. Фронтендом занимаюсь около 4 лет, основной стек — React + Angular.

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

Если смотреть на начало истории веба, то единственный способ отобразить ваш сайт на экране, это был вариант рендеринга на стороне сервера. Первым делом вам нужно было загрузить наш HTML, наши стили на сервер, далее все компилировалось и только потом вы могли видеть веб-страничку. Ранее все страницы были наполнены текстом и какими-то картинками (на примере ниже — первая веб-страница в истории).

Сейчас люди хотят большего, технологии развиваются и можем видеть такие приложения, как Facebook, Twitter и так далее. Мир веба разросся и помимо просто чтения информации, люди хотят взаимодействовать с сайтом: принимать и отправлять сообщения в реальном времени, просматривать видео, комментировать.

От чего зависит скорость загрузки сайта?

Первым делом, всегда когда мы открываем веб-сайт, браузер делает запрос к серверу, чтобы взять весь контент нужный для отрисовки нашей страницы (HTML, картинки, видео, стили и куча другой информации). На самом деле скорость запроса и ответа сервера зависит от нескольких причин:

  1. Скорость интернета, стабильность соединения. Думаю, каждый из нас, когда был 3G на телефонах сталкивался с этой проблемой.
  2. Дистанция между вами и сервером. Те, кто пользовался сервисами по типу AliExpress, у которых серверы вообще непонятно где расположены, меня поймут.
  3. CDN оптимизация. Если CDN будет плохо настроен, запрос и ответ от сервера будет идти долго.
  4. Количество пользователей в один момент. Чем больше пользователей у вас на сайте находится и чем больше они делают запросов, тем больше делают запросов, тем больше страница начинает тупить.
  5. Насколько вы, как разработчик, оптимизировали ваш сайт для загрузки (банально, действия для улучшения перформанса или та же SEO-оптимизация).

Виды отрисовки данных

Я выделю два основных вида — отрисовка на стороне сервера (SSR) и отрисовка на стороне клиента (CSR). Отмечу еще статическую генерация сайтов (SSG) — давняя технология, которая сейчас переживает реинкарнацию благодаря фреймворкам и библиотекам как React, Angular, Vue, появляется все больше методов для статической генерации.

Не менее слабыми, а иногда и более сильными методами отрисовки выше, будут Universal Rendering и Pre-Rendering. Universal Rendering берет всего по чуть-чуть и от SSR, и от CSR, возможно вскоре в некоторых моментах будут добавлять уже и статическую генерацию.

Какой из них лучше выбрать?

Исходите из того, чего вы хотите добиться. Может вы хотите подучить React, создать single-page application, может вам нужно улучшить SEO или сделать навигацию быстрее.

CSR

В этом случае, когда пользователь открывает веб-страницу, его браузер делает запрос на сервер, после чего сервер начинает возвращать данные — нам идет ответ. Далее браузер начинает загружать весь JavaScript, который был пролинкован в том же практически пустом HTML, где есть просто илинки на JavaScript третий шаг — браузер начинает все собирать (в нашем случае — это React). Пока выполняются эти три пункта, пользователь будет видеть белый экран.

Facebook, Gmail, Trello, Quora, Slack и много других используют Client Side Rendering. Почему они выбрали именно CSR?

Плюсы CSR:

  • Быстрая отрисовка после первой загрузки
  • Быстрая навигация
  • Меньше нагрузка на сервер
  • Отлично подходит для веб-приложений

Я бы даже объединил первые два пункта. Когда мы рисуем на стороне клиента и загружаем наш HTML, т.е. уже получили ответ от сервера, и у нас тогда грузятся все скрипты, все бандлы, и после того, как это все загрузилось, не нужно будет делать лишних запросов, чтобы перейти на другую страничку. То есть навигация будет работать гораздо быстрее, чем при отрисовке на стороне сервера.

Что до минусов CSR:

  • Медленная первая загрузка. «Медленная» — относительное описание, но иногда и 2-3 секунды белого экрана уже критичны для пользователя.
  • Решение с маршрутизацией в отрисовке на стороне клиента может отложить работу веб-краулера. Веб-скреперам будет сложнее считывать вашу страницу, т.к. им нужно будет запускать определенные скрипты и не все поисковые системы имеют такую способность даже запускать тот же JavaScript, чтобы проиндексировать и считать вашу страничку.
  • SEO, но только в том случае, если вы, как разработчик, плохо реализовали оптимизацию сайта — если не понимали до конца, что вы делаете (из негативных последствий — вплоть до неправильной индексации, неправильной информации в браузере, поисковые системы не будут понимать ваш сайт и они его просто не будут выставлять в топ поисковика).
  • Запрос при инициализации загружает страницы, стили, шаблоны и т.д., сильно нагружая технику пользователя.

Плюсы SSR:

  1. SEO-friendly — такой вариант отрисовки гарантирует отличную индексацию страниц и чтение поисковыми механизмами, это будет происходить гораздо чаще, т.к. поисковым механизмам не нужно будет запускать JS, он будет просто считывать вашу страничку с мета-тегами;
  2. Улучшение производительности для пользователя — пользователь будет видеть контент на страничке быстрее, т.к. от сервера придет ответ в виде HTML и нам придется только отрисовать его в браузере;
  3. Оптимизация под социальные сети — шеринг в соцсетях, например, в Facebook или Twitter будут отображаться красивые превьюшки с заглавием, картинкой, описанием, это не будет просто ссылкой без ничего (из-за правильно подобранных мета-тегов);
  4. Девайс пользователя будет меньше нагружен — поскольку нам уже приходит ответ от сервера и нам нужно будет только вывести эту информацию, ничего не нужно будет рендерить на стороне клиента, браузере или железе пользователя.

Минусы SSR:

  1. TTFB (time to first byte) будет медленнее. Это одна из метрик производительности веб-страницы, которая описывает время, которое прошло с момента отправления браузером запроса страницей до получения первого байта информации от сервера. Вместо того чтобы отправить практически пустой HTML документ со ссылками на JavaScript (как в случае с отрисовкой на стороне клиента), серверу нужно будет какое-то время для подготовки HTML для вашей страницы.
  2. Сервер будет более занят и будет обрабатывать меньше запросов в секунду. Когда мы добавляем отрисовку контента на сторону сервера, пропускная способность сервера уменьшится.
  3. HTML-документ будет больше по размеру, т.к. в нем уже будет полностью вся структура в нем (в случае с React, там же будут стили).
  4. Несмотря на то, что страница загружается быстрее, она будет неюзабельна (пользоваться ею можно будет только после компиляции) — пользователю надо будет подождать, пока тот же React все загрузит.

Как это правильно сделать?

Сегодня будем все рассматривать на примере React, Angular и Vue. В случае отрисовки на стороне клиента, вам не нужно будет долго искать как правильно это сделать, потому как когда вы учились создавать какое-либо Angular-приложение, оно уже отрисовывалось на стороне клиента. То есть все, что нам нужно будет сделать — это build, после чего получаем нашу папочку disk и ее успешно заливаем на сервер. Там есть файл index со всем пролинкованным JavaScript-ом и все бандлы также сохраняются в эту папку.

  • на React это можно сделать через обычный Create-React-App;
  • на Angular — NG NEW;
  • на VUE — VUE Create.

SSR

Процесс рендеринга на стороне сервера кардинально отличается от рендеринга на стороне клиента. Первый шаг будет аналогичным предыдущему методу — браузер делает запрос на сервер, но после этого сервер отправляет нам уже готовую к рендеру HTML-страницу. То есть уже есть все мета-теги, все блоки, которые нам нужны — все отправляется в браузер, где страничка рендерится и становится видной пользователю. Когда пользователь увидел какой-то базовый контент, браузер начинает загружать JavaScript, после чего выполняет React и только после всего этого мы можем взаимодействовать со страницей.

SSR используют YouTube, Rozetka, Airbnb, Netflix, Uber, Upwork и другие.

Как это правильно сделать?

Начнем с React. Есть два отличных способа: использовать фреймворки NEXT.js и RAZZLE. У NEXT.js, например, очень хорошая поддержка со стороны коммьюнити и вам не придется запариваться с разными сборками, очень много разных фич есть прямо из коробки — можно брать и использовать, а не искать на стороне. Что до RAZZLE, это инструмент, который превратит все ваши сложные настройки для отрисовки на сервере в одну большую зависимость. В свою очередь, то же самое позволит вам сделать Create React App, только уже не затрагивая глобальных изменений в архитектуре вашего приложения, он также не затронет ваши роутинги и фетчинг данных.

Если говорить про Angular, у него есть прекрасная вещь — Angular Universal, который отлично подойдет для рендеринга на стороне сервера. Отличная поддержка комьюнити, множество статей и информации.

Для Vue нужно брать NUXT.js — он очень похож на то, как реализован и как работает NEXT.js. Как и в других методах, в принципе нет ничего сложного для минимального приложения, и очень много информации и живое комьюнити.

Что выбрать: SSR или CSR?

Отличие № 1: скорость загрузки страницы

Рассмотрим два варианта загрузки страницы. Первый сценарий — initial load, т.е. среднее время на загрузку страницы, когда пользователь открывает ее впервые.

При первой загрузке при рендеринге на стороне клиента браузер будет грузить все HTML стили и скрипты одновременно, и только тогда будет компилироваться HTML в стабильную юзабельную версию. В свою очередь, на стороне сервера это займет меньше времени (см. пример — загрузка простенького приложения, потому и цифры небольшие).

Второй сценарий — когда загружаемая страница открывалась не впервые (навигация между страницами). В таком случае отрисовка на стороне клиента подгружает все скрипты заранее, это сэкономит время на загрузку страницы. А в случае с отрисовкой на стороне сервера, то каждый раз при навигации придется делать запрос на сервер, что займет больше времени.

Отличие № 2: влияние на кеширование

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

Но тут есть свои нюансы: это работает только в том случае, если нам не нужно брать данные из какой-то API-шки и если мы не используем lazy loading каких-то модулей. Если делаем запрос, то о плюсах этого кеширования и такого вида рендеринга не идет речи.

Если все же не использовали API-шки, чтобы подтянуть данные, и обошлись без lazy loading, то настроив кэширование, это можно превратить в своего рода десктопное приложение (если у вас не будет часто меняться контент — дашборд со статической информацией).

Отличие № 3: влияние на SEO

Эта картинка (с Гомером) идеально иллюстрирует рендеринг приложения на стороне клиента, т.к. изначально оно не имеет никакой SEO-оптимизации, поисковые механизмы будут его пропускать. Выйти из этой ситуации можно, добавив React Helmet (что до Angular, то мы просто возьмем работу с мета-тегами, будем отображать все мета-данные в браузере). И после того, как мы добавляем мета-теги в приложение или используем React Helmet, оно становится умнее и считывается поисковыми механизмами.

С другой стороны, у нас есть отрисовка на стороне сервера. Если мы будем использовать метод без React и без Angular, от сервера вы сразу будете получать готовую HTML и в ней будут прописаны все мета-теги, что позволит сделать индексирование страниц, считывание страниц и поисковым системам не надо будет запускать JavaScript. Но в случае с библиотеками и фреймворками, как React, Angular и Vue, вам придется использовать что-то дополнительно (например, то же React Helmet) чтобы прописать мета-данные. В последующем, поисковому механизму будет чаще проходиться по вашей странице, поисковому механизму и краулеру будет проще пройти по ней, т.к. уже есть готовая структура, которую можно считать и не запускать JavaScript.

Если вам нужно постоянно генерировать трафик, вам обязательно нужно использовать отрисовку на стороне сервера. Не зря такие приложения как YouTube, Upwork, Rozetka и прочие, зависящие от трафика, выбирают именно SSR.

Когда лучше использовать CSR и SSR?

Динамическая загрузка контента. Лучше взять отрисовку на стороне сервера — у него больше вычислительной памяти, больше скорость интернета, есть стабильное соединение и он может обрабатывать много запросов на получение данных и контента. Подтягивание контента с сервера будет работать намного быстрее, чем при рендеринге на стороне клиента.

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

Так же, чтобы создать отрисовку на стороне сервера с React-приложением, нужно иметь понимание и опыт, т.е. хорошую экспертизу в том, что вы делаете. Если вы никогда с таким не работали, то нужно прочитать много информации — порог входа тут довольно высокий, особенно если говорить о старых приложениях. Не нужно забывать и о стоимости: вашему клиенту будет дешевле использовать отрисовку на стороне клиента, т.к. при отрисовке на стороне сервера чем больше вы будете его загружать, тем большей станет стоимость.

Не всегда вам придется выбирать между этими двумя методами, можно взять лучший из двух миров — Universal Rendering. Тут мы берем по чуть-чуть от SSR (быструю первую загрузку и улучшение производительности) и CSR (быстрая навигация между страницами). Например, для React есть фреймворки Gatsby.js и Next.js, у Angular есть Universal, для Vue также можно использовать Next.js.

На этом мы могли бы и закончить, но, как я уже говорил, в последнее время набирает популярности статическая отрисовка сайтов — SSG (Static Site Generators).

До того, как интернет захватили CMS-ки и даже когда они уже были, на его просторах господствовали статические сайты. И, казалось бы, они остались в прошлом, но сегодня SSG сейчас успешно воскресают (преимущественно, благодаря React, Vue и Angular). Они позволяют создавать довольно качественные сайты, при этом контент будет уникальным, но от вас не потребуется колоссальных усилий.

Такой вид генерации накидывает контент на готовые шаблоны, после чего шаблон и данные собираются воедино — и получает вьюшку страницы.

Как можно реализовать SSG?

С точки зрения React, можно взять такие методы, как Gatsby, React Static, Next.js, Jekyll, Hugo, Phenomic. Если смотреть на Angular, выбор небольшой — просто берем Scully и работаем. На Vue можно попробовать использовать Nuxt.js, Gridsome и VuePress.

Методология по созданию таких сайтов называется JAMstack (J — JavaScript, A — APIs, M — Markup). JavaScript — для того, чтобы сделать сайт интерактивным, APIs — для получения информации и контента, Markup — что-то по типу контент-генератора, другими словами, обычный шаблонизатор.

Плюсы SSG

  • Быстрая загрузка, т.к. идет преимущественно статический контент.
  • Есть хорошая гибкость и не требуется back-end для реализации.
  • Такой вид приложений будет надежным — безопасность будет выше, чем у «одноклассников».
  • Дешевле в обслуживании, т.к. ничего не нужно будет отрисовывать на стороне сервера.

Минусы SSG

  • Нет контента в реальном времени, потому невозможно использовать в большинстве сайтов
  • Нет авторизации — ее невозможно реализовать.

SSG не может использовать конструктор страниц, так же могут возникнуть проблемы с менеджментом крупных сайтов. Например, на вашем сайте много статей и после каждого обновления или изменения контента (добавления нового материала) вам придется заново пересобирать и передеплоивать весь ваш сайт.

Где в таком случае можно будет использовать SSG? Например, для создания небольшого личного сайта, написания документации, не требующей частых изменений, e-commerce, лендинги с небольшим интерактивом и другие сайты для маркетинга.

Только вам решать, какой метод из трех описанных использовать вам. Если будут вопросы, можете мне писать в Telegram (@igorischenko) или в Linkedin.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Правильный способ: ЧЕЛОВЕКОМ надо рендерить. Тупо взять несколько шаблонов под разные форматы экрана, и отрендерить геометрию базовых блоков так, чтобы при поступлении данных она больше не менялась. По крайней мере нормально не менялась, без непредвиденных ситуаций (которые нужно передать пользователю).

Ключевое правило: Дайте пользователю поля ввода и не суйте в них рыло!
Ничего так не бесит пользователя, как ваши «сверхценные» действия, мешающие ему, например, залогиниться или вбить строку в поиск. Засуньте в жопу свои куки. Не спрашивайте из какого он города — могли бы, скоты, уже запомнить: загляните в свою жопу, там где куки, и подумайте зачем они вам, если хранятся только до конца сессии.

Измерьте сами примерную скорость работы канала данных и интерфейса юзера (всего-то 1 писк телеметрии), и если скорость низкая — да засунет вам тимлид осиновый кол в задницу, если вы запрашиваете контент на каждое нажатие кнопки.

Особый маразм — неумение страницы реагировать на недолёт запроса или ответа. Ну не успел, связь плохая, ваш сервак подавился, CDN захлебнулся — дальше что? На кой мартышкин перец наши «синьйоры» блочат весь контент, поля ввода, поля отправки данных — если не долетел какой-то хинт из очереди?

Бросать в горячий котёл нужно любителей «ускорить» обработку события, добавив бесконечный цикл. Да, встречаются и такие маразматики. Вместо тупого промиса — в бесконечном цикле ждут, когда что-то отрисуется, прилетит, отрендерится, отзовётся на действия пользователя. Что по этой причине на мобильном устройстве может встрять браузер, приложение, а то и интерфейс системы в целом — а зачем знать? Про потребление памяти умолчу благим матом — ведь эти идиоты не забывают неявно рождать новые зоны видимости.

Прекратите онанировать на событие поворота экрана. Да, бывает, что пользователь это сделал, и надо перестроить картинку. Но тогда НЕ НУЖНО её адаптировать, тупо отмасштабируйте и всё. Чаще всего экран вообще поворачивают случайно, потому до масштабирования... подождите хотя бы секунд 5, и убедитесь что экран не продолжают вращать. А после того как отреагировали — следующая реакция не ранее 15 секунд. И чёрт побери, убедитесь сначала что вьюпорт не квадратный!!!

ДАЙТЕ все позиции. Забудьте про дебильную пагинацию. Если пользователь что-то ищет, это не ребёнок из детского сада. Ему не проблема просмотреть 100-200 позиций, а то и 1000 — это вы долб***ы считаете, что ему надо 24 позиции (и каждый раз сбросив выбор в дефолт). Да похеру на нагрузку на CDN — не вы за это платите! Много картинок? Сколько много? 1000 картинок по 50 кб это всего лишь 50мб. Догружайте картинки по мере приближения вьюпорта — и пользователь этого не заметит, и вы от DDOS прикроетесь, особенно если события прокрутки проверите на «человечность» по количеству кликов и прокруток в секунду.

ДАЙТЕ весь текст!! Ровни ничто не мешает выдать сразу все текстовые данные. То что они не влезают — думайте как разворачивать (почему бы и не popup). Но чтобы поиск по странице их видел! И чтобы человеку не приходилось делать 1000 переходов, если ему надо просмотреть 1000 позиций. Да, ***дь, ему бывает надо. Не ваше собачье дело, зачем. Если бы вы не совали рыло с заменой текста на «...» или вообще его удалением из списка — глядишь, ВСЕ бы получали то, зачем пришли.

Повторюсь — сколько это стоит серверу (нисколько, на самом деле) — это не ваше дело, то что заказчик потратит на 0.5% больше вычислительной мощности вас сношать не должно. Вы думайте сколько времени должен потратить ПОСЕТИТЕЛЬ, и не на тестовой нагрузке, а на боевой. Да-да, вы, нетрадиционноориентрированные, хоть раз залили на полигон полный объём боевых данных? Хоть раз прогнали тесты на полных объёмах? Хоть раз оценили длину пути реального пользователя к данным?

НЕ ТОЛЬКО посетителю пользоваться ресурсом. За ним нередко стоят живые люди. Саппорт например. И это не саппорт сайта/приложения — это операторы живого бизнеса. И вы должны адаптировать фронтенд под их работу. БЫСТРУЮ работу. А для этого — вы обязательно подключаете их бета-тестерами, и пусть уже ваш саппорт не ипёт им моск, а внимательно прислушивается к хотелкам и проблемам. Не значит, что все их надо выполнить (там тоже бывают идиоты), но проверить — обязательно. Потому что ваш тестер никогда не увидит проблем скорости, когда то что должно работать 1 секунду — работает 30, а то что должно находиться по ссылке из любо точки — требует зачем-то поиска.

__________________
...и вот в самом конце вот этого списка элементарной ЧЕЛОВЕЧЕСКОЙ логики — уже где-то после 2000-ного пункта, может быть имеет значение где вы рендерите, на сервере или у клиента. Пофигу это по большому счёту. Потому что ваш посетитель читает и смотрит гораздо медленнее, чем вы можете его кормить инфой. А если это не так — у вас руки из жопы.

Шо за потік бугурта? Ти не користувач, ти задрот-прогроміст. Типовим користувачем тобі вже ніколи не бути.

Ти не користувач, ти задрот-прогроміст. Типовим користувачем тобі вже ніколи не бути.

Разница между

задрот-прогроміст

и

Типовим користувачем

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

У них двох різний біль. А визначається все інтерв’ю і тестами, а не суб’єктивною оцінкою людей з технічним бекграундом. Тим мають займатися проектувальники(дизайнери).

У них двох різний біль.

Обычно, один и тот, же. Мои родственики которые очень далеки от программирования жалуются ровно на те вещи которые мне видны с беглого взляда, правда не знают как их правильно назвать и описать. Обычно это ограничивается «а как это сделать» и «почему оно так плохо работает». Оценка не субьективная — а весьма обьективная.

Если смотреть на начало истории веба, то единственный способ отобразить ваш сайт на экране, это был вариант рендеринга на стороне сервера. Первым делом вам нужно было загрузить наш HTML, наши стили на сервер, далее все компилировалось и только потом вы могли видеть веб-страничку.

Статика на вебсервере это не «рендеринг на стороне сервера».

Скорость интернета, стабильность соединения. Думаю, каждый из нас, когда был 3G на телефонах сталкивался с этой проблемой.
Дистанция между вами и сервером. Те, кто пользовался сервисами по типу AliExpress, у которых серверы вообще непонятно где расположены, меня поймут.
CDN оптимизация. Если CDN будет плохо настроен, запрос и ответ от сервера будет идти долго.
Количество пользователей в один момент. Чем больше пользователей у вас на сайте находится и чем больше они делают запросов, тем больше делают запросов, тем больше страница начинает тупить.
Насколько вы, как разработчик, оптимизировали ваш сайт для загрузки (банально, действия для улучшения перформанса или та же SEO-оптимизация).

Тут воды больше чем в Тихом окене.

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

Так рендерится на сервере или в бразуере? Может все таки на сервере, а в браузере отрисовывается уже?

Я выделю два основных вида

Туда же Server-side scripting (php, asp.net, spring mvc etc.).

Колись мав трохи часу і натхнення і вирішив зробити для одного сайту гібридний рендерінг: при першому завантаженні сервер рендерить HTML код і передає готову сторінку, а вже далі завантажується JS та ініціалізує весь необхідний UI. При переході за посиланнями на сайті всі наступні сторінки рендеряться вже в самому браузері, з сервера завантажуються лише шаблон та контролер.
Оскільки бек-енд працював на Ноді, це дозволяло запускати JS-код для рендерінгу сторінки окремим потоком та отримувати вже готовий HTML. Для цього прийшлось симулювати браузерне оточення (додати DOM, fetch, location і т.д.)

Це ви ssr і спа схрестили

І здається тут не було чого схрещувати: на скільки я знаю, Ангуляр в такому форматі вже давно працивати може з коробки.
Нажаль не знаю як там з Реактом ситуйовіна, але думаю приблизно так само.

Просто для общего развития. Термин рендеринг повсеместно используется в веб для замены термина генерация или это находка автора? Всё-таки в компьютерной графике он имеет совсем другое значение и вводит по-началу в заблуждение. В конце-концов страничку можно отрисовать на сервере в картинку и прислать html с одной картинкой, и этот тоже будет SSR, но явно не тот, что имеется в виду в статье

Понятно, спасибо. Значит как всегда слишком мало свободных слов, так что приходится называть разные вещи одними и теми же словами

сначала они извратили понятие «нативный код», теперь взялись за рендеринг

Побуду занудой. В статье это тоже приводит к неоднозначности.

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

Тут «рендерится» всё ещё в смысле генерируется или уже визуализируется? Кажется второе.

Подписаться на комментарии