В техническом пространстве разбрасывается много модных слов. Два из них — статическая генерация сайтов (SSG) и рендеринг на стороне сервера (SSR).
В этой статье я попытаюсь демистифицировать SSR и SSG и узнать, где они могут нам помочь. Начнем с истории, а затем перейдем к некоторым реальным примерам и технологиям, таким как Next.js и Gatsby.
В начале…
В самом начале были только статичные веб-страницы. Ничего динамичного. Клиенту отправлялись только статические HTML-документы.
Когда мы заходили на сайт, на сервер отправлялся простой HTTP-запрос, в ответ приходил фактический HTML-код, который браузер выводил на экран.
Затем появились движки динамического рендеринга и шаблонизации. Привет, PHP и все остальное!
Эти серверные технологии позволяли динамически создавать HTML-код, который отправлялся клиенту. Каждый HTTP-запрос, исходящий от него, проходил через сервер приложений. Это добавляло небольшие динамические фрагменты, такие как имена пользователей, текущая дата, данные из БД и т.д.
Это традиционный рендеринг на стороне сервера. Клиент (браузер) извлекал фактический HTML-код для отображения.
AJAX и начало хаоса во фронтенде
С AJAX мы получили возможность получать данные асинхронно, без необходимости полного обновления страницы.
Это сильно улучшило пользовательский опыт — больше никаких раздражающих вспышек экрана. Но задумайтесь об этом на секунду….
Асинхронные данные, новые данные, новые страницы, новые интерфейсные компоненты. Интерфейс теперь отвечает за генерацию HTML-кода, который он должен визуализировать. Привет, рендеринг на стороне клиента!
С необходимостью рендеринга визуальной разметки на стороне клиента начали появляться различные библиотеки и фреймворки. Одним из самых известных членов этой банды является, конечно же, jQuery. В наши дни мы в основном используем более современные технологии — React, Vue и Angular.
С новыми инструментами начала становиться реальной так называемая фронтенд усталость. К счастью, есть несколько популярных победителей — React и Vue.
Одностраничные приложения и проблемы
Имея возможность легко генерировать визуальную разметку на стороне клиента, мы каким-то образом полностью отказались от любимых серверов для рендеринга.
Теперь весь HTML-код генерируется на стороне клиента. Сервер посылает браузеру пустой HTML и некоторые данные в JSON или XML через AJAX, а мы используем предпочтительную библиотеку/фреймворк, чтобы заполнить страницы значимыми тегами и стилями. Это возможно, конечно, с помощью клиентского JavaScript.
Начали появляться одностраничные приложения (SPA) — страницы, которые были полностью визуализированы на стороне клиента и не нуждались в каких-либо круговых обходах к серверу для получения данных через AJAX.
К сожалению, рендеринг всей клиентской части веб-страницы принес целый ряд других потенциальных проблем. Во-первых, люди начали беспокоиться о SEO — поисковой оптимизации.
Поскольку поисковые роботы Google читают и индексируют веб-сайты, чтобы ваша страница отображалась в Google, мы обеспокоились тем, что “роботы” не будут воспринимать HTML, который еще не был отрендерен. Мы боялись, что Google или другие <вставьте название поискового движка сюда> увидят только корневой HTML-тег, в котором в конечном итоге мы будем отображать весь контент с помощью JavaScript. В принципе, роботы увидят пустую веб-страницу.
Теперь мы расслабились, так как большинство поисковых роботов и индексаторов выполняют JavaScript, необходимый для рендеринга на стороне клиента.
Вторая потенциальная проблема — это производительность. Выполнение (большого количества) JavaScript необходимо в браузере для визуализации страницы, но все может замедлиться, так как большой процент серфинга происходит на мобильных устройствах со слабыми процессорами.
Итак, давайте использовать серверы. Снова.
Вернемся к истокам
Рендеринг на стороне сервера снова начал входить в моду. Однако мы не будем использовать механизмы шаблонов или серверные языки программирования для создания разметки. Вместо этого — современные библиотеки JavaScript и фреймворки, такие как React. Разница между этим подходом и рендерингом на стороне клиента (как в SPA) заключается в том, что генерация разметки будет выполняться не на клиентском устройстве, а на серверах.
Это должно быть быстрее, но также направлено на решение потенциальных проблем SEO. Всякий раз, когда поисковый робот запрашивал нашу страницу, он получал ее полностью визуализированной — больше не требовалось выполнять JavaScript на стороне клиента для рендеринга. Сервер делает это для каждого запроса страницы.
Когда мы говорим о рендеринге на стороне сервера, имеем в виду именно этот сценарий. Генерация веб-страницы на стороне сервера для каждого сетевого запроса с применением современных библиотек JavaScript и фреймворков.
Рендеринг на стороне сервера (SSR)
Очень важно понимать, что для того, чтобы иметь серверный рендеринг пользовательского интерфейса, мы должны располагать сервером.
Для рендеринга на стороне клиента (SPA) это ненужно. Такие проекты можно дешево кэшировать и хранить в CDN (сетях доставки контента). Не нужно запускать виртуальную машину или модули Kubernetes для размещения полностью отрендеренного клиентского фронтенд-проекта. А для SSR это необходимо.
Это потенциальный негативный аспект рендеринга на стороне сервера, поскольку серверы могут стать довольно дорогими.
Подведем итоги. SSR работает следующим образом:
1. Агент пользователя (браузер) запрашивает страницу.
2. Сервер генерирует HTML-страницу для вывода и отправляет ее обратно.
3. Браузер отображает HTML.
Вопрос: если выходные данные сервера для страницы всегда одинаковы, зачем генерировать их при каждом запросе?
Отличный вопрос! Это на самом деле то, что отличает рендеринг на стороне сервера от статической генерации сайта.
Динамический контент в SSR
Если генерируемая страница содержит динамические разделы, такие как пользовательский контент, имеет смысл использовать рендеринг на стороне сервера и повторно генерировать страницу для каждого пользователя (каждого запроса).
Однако, если выходные данные всегда одни и те же (например, страница “О нас”), то нет смысла всегда их восстанавливать. Они могут быть сохранены (читай: кэшированы) где-нибудь, на CDN, как статический (неизменяемый) ресурс, который быстро обслуживается в любой точке мира.
Статические веб-сайты
Мы вернулись туда, откуда начали!
Обслуживание статических страниц было первым подходом в мире интернета. Хранение на сервере и возвращение клиенту при запросе в виде “как есть”.
Это точно такая же идея, лежащая в основе статической генерации сайтов. Однако, вместо старого HTML и CSS, мы применяем современные инструменты, как React, Vue и Angular, которые генерируют статический вывод с помощью HTML, JSX, CSS и JavaScript, транспайлеров, пакетов и так далее.
Нужно выбирать статическую генерацию сайта всякий раз, когда вам не хватает высокодинамичных данных, которые должны быть уникальны для каждого пользователя.
Процесс настройки статической страницы:
1. Получение статического вывода сборки из фронтенд библиотеки, например React, в паре с Next.js или Gatsby. Он будет содержать все статические активы.
2. Размещение его на CDN (дорогих серверов не требуется).
3. Вы получаете быстрый и устойчивый фронтенд. Можно продолжать!
Подумайте о портфолио, которое вы редко, если вообще когда-либо, обновляете — например, страница для ресторана или блога.
Допустим, это блог. Нужно добавить к нему сообщения. Это должно проходить динамично, не так ли? На помощь приходит рендеринг на стороне сервера!
Нет, не так быстро.
С помощью современных технологий статические веб-страницы можно легко перестраивать и перераспределять, когда что-то меняется. Это основной принцип современной статической генерации сайтов.
Современные статические сайты
С использованием передовых технологий статические сайты на самом деле не так уж статичны. В чем-то они могут быть динамичны.
Пионерами в этой области являются такие компании, как Vercel (ранее Zeit) с Next.js, NuxtJS (для поклонников Vue), Netlify, Gatsby, Jekyll и Hugo.
Используя такие фреймворки, как Next.js или Gatsby, можно написать веб-приложение в React, которое извлекает все необходимые данные для сайта во время сборки.
Важно подчеркнуть следующее: вы можете получать любые данные из нескольких источников (например, продукты для сайта электронной коммерции, сообщения в блогах и т. д.), но они извлекаются только во время сборки (т. е. при развертывании или размещении приложения на CDN).
Как следствие данные, которые статический сайт показывает своим пользователям — это данные, которые вы извлекли при развертывании/сборке своего приложения. Всякий раз, когда информация для показа меняется (новая запись в блоге), вы должны пересобрать проект.
Это может показаться сложным, но на самом деле это не так. Современные инструменты позволяют сделать процесс чрезвычайно легким.
Jamstack
Еще одно модное слово, относящееся к области технологий и веб-разработки. Но оно действительно крутое!
Jam в jamstack означает JavaScript, API, Markup.
В основном это движение поощряет людей использовать статические сайты, которым вообще не нужны сервера, что делает хостинг дешевле, а приложение более устойчивым без простоев. Извлечение данных для визуализации страниц во время сборки является существенной характеристикой сайта Jamstack.
Есть несколько технологий, которые делают Jamstack возможным.
Headless CMS набирают огромную популярность. В основном эти системы управления контентом помогают хранить и извлекать данные во время сборки. Netlify CMS и Contentful — это два примера headless CMS.
Например, когда вы отправляете новую запись в блог через headless CMS, она запускает новую сборку статического фронтенд проекта. Изящно! Вы по-прежнему не платите за сервера, а данные, которое приложение отображает, являются квази-динамическими.
Платформы, на которых вы можете размещать статические сайты и которые являются пионерами Jamstack, такие как Netlify и Vercel, делают интеграцию между headless CMS и фактическим статическим сайтом бесшовной.
Просто нажмите кнопку, чтобы добавить сообщение в блог, и вуаля, статический сайт восстановлен и готов к доступу с совершенно новым контентом. И все еще невероятно быстро через CDN.
Рендеринг на стороне сервера (SSR) против статической генерации сайта (SSG)
Было очень много информации!
Когда же следует использовать SSR и когда SSG? Рассмотрим несколько плюсов и минусов.
Рендеринг на стороне сервера
Плюсы:
- Все показанные данные всегда актуальны.
- Вы можете отображать пользовательские и динамические данные, которые могут часто меняться.
Минусы:
- Нужен сервер для запуска рендеринга — это может стоить дорого.
- Нельзя использовать CDN, которые помогают приложению загружаться намного быстрее (вы можете поместить слой кэширования перед SSR-приложением, но тогда рискуете показать устаревшие данные).
Статическая генерация сайта
Плюсы:
- Очень быстрый сайт (так как он может быть развернут в CDN).
- Нет необходимости ждать логики на стороне сервера.
- Не имеет значения, если сервер не работает (так как он не нужен!).
Минусы:
- Неидеально, если контент очень динамичен или специфичен для пользователя.
- Требуется пересборка, когда нужно показать иные, либо новые данные.
Это равнозначное сравнение?
Важно понимать, что SSR и SSG не являются прямыми конкурентами. Есть определенные варианты использования, когда один или другой будет более подходящим.
Если у вас личный сайт или сайт бренда с блогом и некоторыми редко меняющимися данными — лучше использовать статическую генерацию сайтов.
Сайт, уникальный для пользователя с личными данными, приборной панелью? Подойдет рендеринг на стороне сервера.
Гибридный подход
Часто с большим продуктом вы обнаружите, что некоторые страницы действительно могут быть статически визуализированы, в то время как другие лучше работают с серверной визуализацией.
Это нормально — Next.js и подобные технологии автоматически статически визуализируют страницы, которые нуждаются в данных о времени сборки (или вообще в них не нуждаются), и страниц на стороне сервера, которые нуждаются в данных по запросу.
При обоих подходах извлечение данных на стороне клиента все еще остается проблемой.
Вы можете сделать простой AJAX-запрос для повторной выборки потенциально устаревших данных, но в остальном иметь статический сайт. Пусть творческие способности и контекст управляют вашими решениями.
Читайте также:
- 4 секрета читаемого и производительного кода JavaScript
- Современное приложение выбирает… Redux, Context или Recoil?
- Три точки (…) в Javascript
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Adam Kiss: Server-Side Rendering vs. Static Site Generation
