Сравниваем Server Side Rendering и Static Site Generators

В этой статье поговорим о SSR и SSG, а также узнаем, в каком случае лучше всего применять эти технологии. Начнем с небольшого экскурса в историю, а потом изучим, где в реальном мире применяются такие технологии, как Next.js и Gatsby.

Термины

Кратко опишу используемые в статье термины:

• SPA - Single Page Application. Одностраничное приложение - это веб-приложение или веб-сайт, использующий единственный HTML-документ как оболочку для всех веб-страниц и организующий взаимодействие с пользователем через динамически подгружаемые HTML, CSS, JavaScript, обычно посредством AJAX.
• CSR - Client Side Rendering. Рендеринг на клиенте - это рендеринг приложения в браузере с помощью DOM.
• SSR - Server Side Rendering. Рендеринг на сервере - это рендеринг клиентской части приложения на сервере.
• SSG - Static Site Generator. Статическая генерация сайтов - это генерация всех HTML страниц приложения в момент сборки.

Каждый разберем более подробно по ходу статьи.

Статические сайты в начале веба

На заре веба были только статические страницы, ничего динамически не генерировалось. Обычные, заранее созданные, статические HTML документы отправлялись клиенту.

Когда пользователь заходил на веб-сайт, то простой HTTP запрос уходил на сервер и далее он отвечал разметкой, которая отображалась в браузере.

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

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

Это и был первоначальный Server Side Rendering. Клиент (браузер) запрашивал у сервера, необходимый для отображения, HTML, который был сгенерирован именно на сервере и далее отображался в браузере.

AJAX

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

С точки зрения UX, это было огромным улучшением - больше никаких надоедливых мерцаний страниц, но тем самым мы начали двигаться в сторону Client Side Rendering.

Для упрощения работы с фронтендом, стали появляться различные библиотеки и фреймворки. Одной из самых популярных библиотек стала JQuery, но тем не менее она еще не был полноценным инструментом для CSR.

SPA

Затем на смену пришли React, Angular и Vue, благодаря которым подавляющее большинство разработчиков, наконец-то, познакомилось с полноценным рендерингом на клиенте. Эти три технологии используют компонентный подход и позволяют разбивать разметку на мелкие и переиспользуемые части, теперь вся генерация HTML происходит именно на фронтенде. Бэкенд используется только для сложных вычислений, работы с базами данных, насыщения фронтенда данными и для многого другого.

Благодаря возможности легко генерировать разметку на клиентской стороне, SPA завоевали огромную популярность.

Если немного углубиться в детали, то теперь сервер стал отправлять клиенту практически пустой HTML, который содержит всего лишь базовую разметку, с каким-нибудь пустым <div class='root'></div> и единственный файл со скриптом <script src='bundle.js'></script>, внутри которого будет написан весь код для генерации разметки, стилей и логики с помощью JavaScript.

К сожалению, такой подход также привел к целому ряду потенциальных проблем.

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

Сейчас ситуация несколько улучшилась, так как многие поисковые роботы научились выполнять, необходимый для Client Side Рендеринга, Javascript. Тем не менее результат такой индексации все равно оставляет желать лучшего.

Во-вторых, потенциальной проблемой является производительность. Поскольку для отображения страницы в браузере требуется выполнение большого количества JavaScript, то приложение может изрядно "тормозить". Особенно это заметно на старых мобильных устройствах.

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

Возврат к Server Side Rendering

Однако, в отличие от старого подхода, когда разметка генерировалась на сервере с помощью серверных языков программирования, например PHP, теперь в Server Side Рендеринге, как и в CSR, будут использоваться современные JavaScript библиотеки, например React.

Разница только в том, что приложение будет генерировать разметку с помощью React не на клиентской стороне, а на серверной.

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

Теперь, когда в разработке упоминают термин Server Side Rendering, то ссылаются именно на этот сценарий.

Более подробно о Server Side Rendering (SSR)

Итак, рассмотрим плюсы и минусы SSR, действительно ли он настолько хорош?

Плюсы

• SEO. Возможность настроить поисковую оптимизацию.
• First Contentful Paint. Благодаря Server Side Rendering, страницы вашего сайта быстрее становятся доступными для взаимодействия. Имея производительный сервер, SSR может дать вам отличную оценку First Contentful Paint, что улучшает UX и, возможно, также SEO страницы.

На самом деле это все плюсы, давайте теперь рассмотрим минусы.

Минусы

• Замедляется время перехода между страницами. Да, для первоначального рендера SSR быстрее, чем CSR, но далее при работе с приложением вам приходится отрисовывать данные дважды, один раз на сервере и один раз на клиенте.
• Более сложная разработка. Написать приложение только на React в связке, например, с Redux значительно проще, чем добавить к этому стэку еще и технологию для SSR. Соответственно увеличивается количество кода, сложность разработки и появляются дополнительные библиотеки.
• Кэширование. Для частичного закрытия первого минуса и в дополнение ко второму, добавляется более сложное кэширование данных.
• Стоимость. В отличие от CSR, теперь нам 100% нужен сервер, да еще и более производительный, это стоит дороже.

Оказывается, у SSR огромное количество минусов, так что же делать? Рассмотрим еще один подход - SSG, может быть он окажется лучше?

Static Site Generator

SSG - это новый подход для веб-разработки, который позволяет вам создавать веб-сайты, страницы которых генерируются в статические файлы в момент сборки. Тем самым, когда браузер делает запрос, то сервер не генерирует разметку, как в случае SSR, а отдает уже готовую. Стоп, похоже мы вернулись к тому, с чего начинали, сервер снова отдает нам простой HTML и CSS, в чем же тогда отличия?

Разница в том, что вместо использования HTML и CSS, теперь мы используем современные инструменты, такие как React, Vue и Angular. То есть приложение, написанное на современных инструментах преобразуется в HTML, CSS и JavaScript с помощью транспиляторов, сборщиков пакетов и т.д.

Звучит отлично, но в чем же тогда подвох? Проблема в том, что SSG не подразумевает динамическую работу с сервером, т.е. вы не можете создать, например, корзину интернет-магазина при помощи SSG, т.к. отображаемая в корзине информация должна быть уникальна для каждого пользователя. В таком случае мы можем применить только SSR или CSR. А статическая генерация сайтов удобна, например, для страницы "Доставка" или для карточки товара, т.е. для той информации, которая идентична для каждого пользователя.

Чтобы более детально понять инструмент, рассмотрим его плюсы и минусы.

Плюсы:

• SEO. Как и в случае с SSR, поисковый робот получает всю необходимую информацию.
• Производительность. SSG обладает самой большой производительностью по сравнению с SSR и CSR, т.к. все данные уже сгенерированы при сборке.
• Очень дешево. Используя статическую генерацию сайтов, вам не нужен сервер, достаточно загрузить код своего сайта на github и собрать его, например, с помощью Netlify. В таком случае вам придется заплатить только за доменное имя.
• Простота разработки. Если сравнивать с CSR, то SSG несколько сложнее, т.к. требуется разобраться в тонкостях, но в целом, картинка слабо отличается от обычной разработки.
• Безопасность. У вашего статического сайта нет сервера, а значит у злоумышленников нет возможности получить доступ к вашей базе данных или панели администратора.

Минусы:

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

Хорошо, SSG звучит частично лучше чем SSR, но как же тогда разработать сложное веб-приложение с динамическими данными, используя современные инструменты и не потеряв в SEO?

SSG + SSR, как универсальный рендеринг

К счастью, есть метод под названием универсальный рендеринг, с помощью которого вы можете получить лучшее из всех подходов:

• Быстрые и плавные переходы между страницами, как у CSR.
• Возможность работы с SEO.
• Невероятно быстрый First Contentful Paint.
• Работу с динамическими данными.
• Уменьшение затрат, связанных с содержанием сервера.

Все эти возможности предоставляет такой фреймворк, как Next.JS.

GatsbyJS и Next.JS

Теперь поговорим о двух самых популярных фреймвоках для React.

GatsbyJS

GatsbyJS - это статический генератор сайтов, основанный на React и использующий GraphQL для передачи данных. Его особенность в том, что у него есть собственная экосистема, включающая огромный набор плагинов и тем. Так же GatsbyJS предоставляет огромное количество инструментов для создания невероятно быстрых веб-сайтов.

Лучшим применением для этого фреймворка будет:

• Простые статичные сайты
• Индивидуальные блоги

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

Next.JS

Next.JS - это фреймворк для React, идея которого заключается в том, что вы можете создавать React-приложения, с поддержкой SSG, SSR, CSR, Typescript, предзагрузкой роутов и многого другого, минимально настраивая конфигурацию.

Лучшим применением для этого фреймвока будет:

• Сложные веб-приложения с динамическим контентом
• Крупные новостные сайты

Примеры крупных компаний, которые используют Next.JS - Netflix, Twitch, Docker, GitHub, Hulu и многие другие.

Заключение

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

Ссылки

Мой канал о javascript и веб-разработке в целом: https://t.me/js_web_development