CSR и SSR: несколько причин выбрать один из них

Этот документ даст вам обзор плюсов и минусов использования решений CSR и изоморфного рендеринга. Это будет охватывать все подробные исследования / эксперименты, проведенные с использованием различных инструментов с различными параметрами, чтобы оценить преимущества производительности одного над другим. Мы также обсудили типичные сценарии/примеры приложений для обоих подходов, чтобы дать вам четкое представление о правильном использовании обоих подходов.

Как это работает!

CSR: настройка приложения CSR по умолчанию — это «корневой» элемент (элемент HTML) с некоторыми тегами скриптов. Этот корневой элемент расширяется до значимого содержимого после выполнения скриптов.

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>My Application</title>
    <link href="./css/app.css" rel="stylesheet" type="text/css" />
  </head>
  <body>
    <div id="root">
      <!-- place for page content -->
    </div>
    <script src="./scripts/app.js" type="application/javascript">
    </script>
    <script src="./scripts/vendor.js" type="application/javascript">
    </script>
  </body>
</html>

Изоморфный. В изоморфном режиме вы создаете значимое содержимое своей страницы на сервере и отправляете его в виде статического HTML, пока загружается Javascript. Как только JavaScript будет готов, приложение CSR возьмет на себя управление страницей.

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>My Application </title>
    <link href="./css/app.css" rel="stylesheet" type="text/css" />
  </head>
  <body>
    <div id="root">
      <div>
        <nav class="nav">
          <a href="/init">Home</a>
          <a href="/init/search">Search Data</a>
          <a href="/init/about">About</a>
          <a href="/init/randomUser">Random User</a>
        </nav>
        <h1>Welcome to My Application</h1>
      </div>
    </div>
    <script>
      window["redux_state"]={"filter":"","user":{name:"Sujaan"}};
    </script>
    <script src="./scripts/app.js" type="application/javascript"></script>
    <script src="./scripts/vendor.js" type="application/javascript"></script>
  </body>
</html>

Причины предпочесть изоморфную/SSR CSR

Вот несколько причин предпочесть изоморфную CSR:

  1. Улучшите воспринимаемую производительность страницы для лучшего UX
  2. Стабильная эффективность SEO.
  3. Избегайте мерцания пустых страниц.

В следующем разделе я объясню вышеуказанные моменты с помощью точек данных в реальном времени из моих приложений CSR и Isomorphic.

1. Улучшите воспринимаемую производительность страницы для лучшего UX.

В изоморфном приложении пользователь получает первый ответ в виде заполненной данными HTML-страницы. Таким образом, вместо получения пустого контейнера для содержимого (как в случае с CSR), пользователь увидит текстовые заголовки, абзацы, теги привязки, кнопки, поля ввода, раскрывающийся список и т. д. (в случае CSR все они увеличиваются после загрузки и выполнения Javascript)

Этот ранний рендеринг даст ощущение улучшенной производительности, которая лучше UX.

Эксперимент 1:
Чтобы проверить приведенное выше утверждение, мы использовали Маяк, и данные были собраны как для CSR, так и для изоморфного приложения.

Давайте возьмем сначала краткий обзор маяка для сравнения производительности. Lighthouse говорит, что производительность веб-сайта измеряется:

  1. Первая отрисовка содержимого: измеряет время от навигации до момента, когда браузер отображает первый фрагмент контента из DOM.
  2. Первая осмысленная краска. Этот аудит определяет время, когда пользователь чувствует, что основной контент страницы виден.
  3. Индекс скорости.Индекс скорости — это показатель производительности загрузки страницы, который показывает, насколько быстро содержимое страницы визуально заполняется.
  4. Первый простой ЦП:Показатель первого простоя ЦП измеряет, когда страница минимально интерактивна.

КСО:-

Изоморфный:-

Существует поразительная разница между CSR и изоморфным инструментом маяка. Первая содержательная краска, индекс скорости, первая осмысленная краска — все это, кажется, улучшилось с Isomorphic.

Эксперимент 2.
Дальнейшее изучение параметра производительности «Значимый рисунок» мы использовали «Инструмент разработчика Chrome» для расчета фактической производительности. усиление.
КСО:-

Изоморфный:-

Это показывает увеличение производительности на 90 % при рендеринге «Значимый рисунок».

Значимое представление CSR: 2000 мс

Изоморфный смысловой просмотр: 200 мс

2. Эффективность SEO постоянна

Поисковые сканеры теперь могут анализировать и выполнять javascript. В частности, бот Google представляет собой сценарий PhantomJS, который работает как Chrome 41.

Если Google может запускать JavaScript и тем самым отображать представления на стороне клиента, почему для SEO необходима обработка на стороне сервера?

  1. Chrome 41 является более старой версией и потребует много полифилов, например. Обещания не будут поддерживаться и т.д.
  2. Google не единственная поисковая система. Большинство поисковых ботов не способны анализировать Javascript.

Вот почему SSR/Isomorphic имеет смысл, поскольку вы не будете рассылать ненужные полифиллы всем своим пользователям только для того, чтобы бот Google мог отобразить вашу страницу.

3. Избегайте мерцания пустых страниц.

Мерцание пустой страницы, которое происходит с CSR, не происходит с Isomorphic/SSR, потому что мы получаем HTML-контент в первом ответе. (Хотя в CSR эта проблема в основном решается путем показа загрузчика, который передается в начальном ответе)

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

CSR:

Изоморфный:

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

Причины, по которым НЕ следует предпочитать изоморфную/SSR CSR

Изоморфный/SSR имеет несколько предостережений:

  1. Время до первого байта (TTFB) медленнее, хотя воспринимаемое время загрузки страницы быстрее.
  2. Более низкая пропускная способность сервера, поскольку обработка и отображение страницы займет больше времени. (ССР)
  3. Постоянное время до взаимодействия со страницей (TTI)

1. Время до первого байта (TTFB) медленнее

Медленное время до первого байта (TTFB) определяется большим временем ожидания. Рекомендуется, чтобы у вас было это менее 200 мс.

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

КСО || Изоморфный

В случае выборки и рендеринга данных на стороне клиента (CSR) время до первого байта меньше, чем в изоморфном приложении. На страницах SSR отображается определенный контент, для которого сервер выполняет обработку. Это также увеличивает размер загружаемой страницы, таким образом увеличивая TTFB.

(Relative to CSR) Additional TTFB with Isomorphic = Server page processing time + time taken to download additional bits of increased page size

2. Снижение пропускной способности сервера:

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

CSR:

В приложении CSR вы создаете активы во время сборки и загружаете их в CDN. Сервер будет нести ответственность за создание HTML-страницы со встроенными в нее активами.

Изоморфный:

В изоморфном/SSR с React влияние на пропускную способность сервера велико. renderToString — это синхронный вызов с привязкой к ЦП, который содержит цикл обработки событий, а это означает, что сервер не сможет обработать какой-либо другой запрос, пока не завершится вызов функции.

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

Ниже приведена нагрузка на сервер, которую мы испытали при тестировании
The number of concurrent connection = 3000 Duration = 15 minutes
The number of pipelined requests = 1

Есть две таблицы:

  1. Таблица для задержки запроса и
  2. Таблица объема запросов.

В таблице Задержка запроса указано время запроса в процентиле 2,5 %, самые быстрые выбросы; при 50% медиана; 97,5 % — медленные выбросы; на 99%, самые медленные выбросы. Здесь ниже значит быстрее.

160 мс — самый быстрый ответ,

1 секунда 557 мс – это среднее значение,

10 секунд 32 мс — самое медленное.

В таблице Объем запросов (2-я таблица) указано количество отправленных запросов и количество загруженных байтов. Эти значения выбираются один раз в секунду. Более высокие значения означают, что обработано больше запросов.

2,03 МБ с 743 запросами в секунду – наихудший вариант

4,88 МБ при 1776,49 запросов в секунду – это среднее значение

8,19 МБ с 2997 запросов в секунду — лучший вариант

3. Постоянное время до взаимодействия со страницей

В то время как HTML-страница создается на сервере, и пользователь увидит контент раньше, чем приложение CSR, но они не смогут взаимодействовать с ним, пока не завершится загрузка и выполнение javascript. Завершение выполнения Javascript добавит на страницу события, которые отвечают за то, чтобы сделать страницу интерактивной, например нажатие кнопки, навигация, ввод и т. д. Таким образом, если клиент действительно быстр и нажимает кнопку или навигацию по странице, браузер не будет выполняться. это действие, пока выполнение Javascript не будет завершено.

Резюме

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

Часто задаваемые вопросы

Q1. Я создаю новое веб-приложение. Что предпочтительнее среди Isomorphic и CSR?
Это зависит от ваших вариантов использования приложения и целевых клиентов. Если ваше приложение требует лучшей воспринимаемой производительности загрузки страниц, лучшего SEO, тогда вы можете рассмотреть изоморфность.

Для устройств (как мобильных, так и настольных) с низкой вычислительной мощностью изоморфный рендеринг поможет в рендеринге страницы со стороны сервера, что увеличивает воспринимаемое время загрузки страницы. Однако, если ваши пользователи находятся в сети с низкой скоростью, такой как 2G или 3G, лучше выбрать CSR, поскольку ваш рендеринг происходит на стороне клиента, а потребление полосы пропускания для начальной загрузки страницы минимально. Браузеры Opera-mini и UC сжимают браузеры, которые отображают HTML совершенно иначе, чем в Chrome, что может привести к другому пользовательскому опыту для ваших клиентов. Чтобы сохранить единообразие UX во всех браузерах, Isomorphic может быть идеальным выбором.

Q2. Изоморфный — идеальное решение для моего приложения. Но пропускная способность сервера меня беспокоит. Любые рекомендации по преодолению этого?
Пропускная способность сервера с Isomorphic может быть улучшена до определенной степени. Ниже приведены несколько конфигураций, которые вы можете использовать в Isomorphic.

  1. Включить поток узлов в Isomorphic, который использует «renderToNodeStream» вместо «renderToString»
  2. Кэширование потокового HTML
  3. Кэширование компонентов пользовательского интерфейса

Вопрос 3. Производительность пользовательского интерфейса не является моим приоритетом, в отличие от SEO (для поисковых систем). Существуют ли какие-либо альтернативы Isomorphic?
Вы можете использовать UI Sniffing (механизм получения информации о запросителе), чтобы обнаруживать запросы поисковых роботов и отвечать заполненными контентом HTML-страницами (SSR). Вот видео прямо из Google, чтобы продемонстрировать этот подход.

Q4. Можете ли вы предложить типичный сценарий, в котором разработчик должен предпочесть CSR?
Рассмотрите приложение портала администрирования, которое выполняет резервное копирование, восстановление и мониторинг рабочего сервера. Обычно вы больше сосредотачиваетесь на том, чтобы пользовательские данные были доступны как можно раньше, чем на производительном UI/UX. SEO отходит на второй план, поскольку данные являются конфиденциальными, а большинство ваших конечных пользователей используют высокопроизводительные устройства.

  • Пользователь зарегистрируется и авторизуется на портале
  • Пользователь увидит панель инструментов с графиками работоспособности, резервного копирования и восстановления.
  • 95% пользователей будут техническими администраторами
  • большая часть трафика будет исходить от устройств высокого класса, в основном ноутбуков и настольных компьютеров. Незначительно для мобильного Интернета.
  • Большинство целевых пользователей будут использовать Chrome, Firefox и IE.

В5. Можете ли вы предложить типичный сценарий, в котором разработчику следует предпочесть изоморфный вариант?
Рассмотрите веб-приложение, которое вы создали для объединения конференций в вашем городе. Это приложение обычно содержит список всех встреч и конференций в вашем районе, которые вы публикуете для технического сообщества вашего города. Для такого конечного приложения вам может потребоваться отличная производительность UX, более быстрое время загрузки страницы, лучшее SEO, и приложение должно без проблем работать на относительно большом количестве недорогих устройств.

  • Страница списка, чтобы показать все конференции
  • Страница сведений о каждой конференции будет содержать все подробности, связанные с темой и местом проведения.
  • Содержание страницы будет варьироваться в зависимости от текущего местоположения клиента и текущей даты.
  • Вошедшие в систему пользователи увидят предварительно определенные параметры, связанные с интересами.
  • 80% трафика будет приходиться на устройства с низкой вычислительной мощностью (как мобильные, так и десктопные)
  • Большинство целевых пользователей будут использовать браузеры Chrome, Opera Mini и UC.

Ну наконец то

Вы, должно быть, нашли это полезным, «Нажмите хлоп».