Главная » Статьи » Рендеринг клиентский (CSR) vs рендеринг серверный (SSR) vs статический сайт (SSG)

Рендеринг клиентский (CSR) vs рендеринг серверный (SSR) vs статический сайт (SSG)

От автора: фронтенд-разработчики часто используют эти термины при описании веб-приложений. Однако разработчиков, которые плохо знакомы с вебом, эти термины могут запутать. Если вам непонятна разница между CSR, SSR и SSG, то эта статья для вас!

Рендеринг на стороне клиента (CSR)

CSR приобрел популярность с появлением одностраничных приложений (SPA). JavaScript фреймфорки AngularJS, ReactJS, BackBone.JS используют именно этот подход. Сервер отсылает статические HTML и JavaScript файлы на сторону клиента. Затем клиент выполняет все необходимые вызовы API, чтобы получить исходные данные и затем отрисовывает приложение.

<!DOCTYPE html>
<html lang="en"> <head> <meta charset="utf-8" /> <title>React App</title> </head> <body> <noscript>You need to enable JavaScript to run this app.</noscript> <div id="root"></div> </body>
</html>

Сервером отправляется статический HTML

В отрывке кода выше, HTML файл, отправленный сервером клиенту, является пустой страницей. Если открыть этот HTML без JavaScript, вы увидите пустой экран с noscript предупреждением. Когда клиет получает HTML и загружает JavaScript, он отрисует div со значением id=»root».

Преимущества CSR

1. Дешево

Приложениям, использующих CSR подход, не требуется веб-сервер. Вы можете разместить веб-приложение на любом CDN или статическом файловом хостинге, например Amazon S3. Существует множество способов сделать это бесплатно.

2. Не требуется полная перезагрузка страницы

Пользователи могут перемещаться по страницам без обращения к серверу, что значительно ускоряет работу сайта.

Недостатки CSR

1. Проблемы с SEO

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

2. Низкая производительность на мобильных устройствах

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

3. Медленная загрузка

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

Рендеринг на стороне сервера (SSR)

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

SSR – наиболее распространенный способ создания сайтов. Недостаток такого подхода заключается в том, что при навигации по сайту постоянно требуется обращаться к серверу. С помощью таких инструментов, как NextJS, можно создавать приложения, используя лучшее из методов CSR и SSR. При таком подходе первая загрузка осуществляется на стороне сервера, а затем на стороне клиента.

Преимущества SSR

1. Быстрая загрузка

Приложения, использующие SSR подход, загружаются быстрее, чем похожие приложения с СSR подходом. И поскольку сервер берет на себя всю тяжелую работу, такие приложения работают быстрее на медленных устройствах.

2. Возможность настроить поисковую оптимизацию

Преимущества SEO для SSR подхода подробно описаны. Google присваивает более высокий рейтинг сайтам, которые загружаются быстрее. У Google и других поисковых систем не возникнет проблем с индексированием веб-сайтов с использованием серверного рендеринга.

Недостатки SSR

1. Затраты

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

2. Более сложная разработка

Самостоятельная настройка рендеринга на стороне сервера с помощью React может быть сложной задачей. Однако ее можно упростить, если работать с фреймворком NextJS.

Статическая генерация сайтов (SSG)

SSG генерирует все HTML-файлы во время сборки. Сервер выполняет вызовы API и генерирует статические HTML-файлы для каждой страницы сайта. Когда клиент запрашивает одну из веб-страниц, серверу не нужно выполнять вызов API или отрисовывать HTML, ему нужно только вернуть предварительно обработанный HTML-файл.

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

Gatsby и NextJS — популярные способы создания статических сайтов с помощью React. Hugo — еще один пример популярных статических генераторов сайтов.

Преимущества SSG

1. Быстрота загрузки

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

2. Дешево

При SSG подходе веб-сайт состоит из множества разных HTML-файлов. Вы можете разместить сайт на любой службе статического файлового хостинга, например S3, или использовать CDN.

Недостатки SSG

1. Плохое масштабирование

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

Лучшее решение – NextJS

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

Next.js может создавать гибридные приложения, использующие как SSR, так и SSG подходы.

Автор: Malcolm Laing

Источник: medium.com

Редакция: Команда webformyself.