spa ssr что это
Рендеринг на стороне сервера против статической генерации сайта
В техническом пространстве разбрасывается много модных слов. Два из них — статическая генерация сайтов (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? Рассмотрим несколько плюсов и минусов.
Рендеринг на стороне сервера
Статическая генерация сайта
Это равнозначное сравнение?
Важно понимать, что SSR и SSG не являются прямыми конкурентами. Есть определенные варианты использования, когда один или другой будет более подходящим.
Если у вас личный сайт или сайт бренда с блогом и некоторыми редко меняющимися данными — лучше использовать статическую генерацию сайтов.
Сайт, уникальный для пользователя с личными данными, приборной панелью? Подойдет рендеринг на стороне сервера.
Гибридный подход
Часто с большим продуктом вы обнаружите, что некоторые страницы действительно могут быть статически визуализированы, в то время как другие лучше работают с серверной визуализацией.
Это нормально — Next.js и подобные технологии автоматически статически визуализируют страницы, которые нуждаются в данных о времени сборки (или вообще в них не нуждаются), и страниц на стороне сервера, которые нуждаются в данных по запросу.
При обоих подходах извлечение данных на стороне клиента все еще остается проблемой.
Вы можете сделать простой AJAX-запрос для повторной выборки потенциально устаревших данных, но в остальном иметь статический сайт. Пусть творческие способности и контекст управляют вашими решениями.
Рендеринг в веб
о переводе
Наше понимание в этой области основано на нашей работе с Chrome, и контактировании с большими сайтами в течение последних нескольких лет. В общем, мы хотим вдохновить разработчиков рассмотреть использование серверного рендеринга или статического рендеринга с полноценной регидратацией.
Чтобы лучше понимать архитектуры, из которых мы выбираем, когда принимаем решение, нам необходимо иметь четкое понимание каждого подхода и последовательную терминологию, которую мы будем использовать, когда говорим о них. Различия между этими подходами помогают проиллюстрировать компромиссы при рендеринге в вебе через призму производительности.
Терминология
Рендеринг
Rehydration (регидратация): «загрузка» JavaScript отображениий на клиенте таким образом, чтобы они повторно использовали отрендеренное на сервере DOM-дерево и данные HTML-а
Prerendering (пре-рендеринг): выполнение клиентского приложения во время сборки для захвата его начального состояния в виде статического HTML.
Performance
Server Rendering (Серверный рендеринг)
Серверный рендеринг генерирует полный HTML страницы на сервере в ответ на навигацию. Это позволяет избежать дополнительных проходов для получения данных и шаблонов на клиенте, так как это выполняется до того, как браузер получает ответ..
Серверный рендеринг обычно даёт быстрый First Paint (FP) и First Contentful Paint (FCP). Выполнение логики страницы и её рендеринг на сервере позволяют избежать отправки большого количества JavaScript клиенту, что помогает достичь быстрого Time to Interactive (TTI). Это имеет смысл потому, что при серверном рендеринге вы на самом деле просто посылаете текст и ссылки в браузер пользователя. Такой подход может хорошо работать для широкого спектра устройств и сетевых условий и открывает интересные возможности для оптимизации браузера, например можно выполнять разбор потоковых (streaming) документов.
При серверном рендеринге пользователи вряд ли будут вынуждены ждать, пока CPU-зависимый JavaScript будет выполнен, прежде чем они смогут использовать ваш сайт. Даже когда стороннего JS не избежать, использование серверного рендеринга для уменьшения собственных JS costs (JS затрат) может дать вам больше «budget» (бюжета) для остального. Однако, есть один основной недостаток такого подхода: генерация страниц на сервере занимает время, что часто может привести к замедлению Time to First Byte (TTFB).
Достаточно ли серверного рендеринга для вашего приложения, во многом зависит от того, какое приложение вы строите. Существует давняя дискуссия о правильности применения серверного рендеринга вместо клиентского рендеринга, но важно помнить, что вы можете использовать серверный рендеринг для одних страниц, а для других нет. Некоторые сайты с успехом переняли гибридный рендеринг. Netflix делает серверный рендеринг своих относительно статических страниц, в то время как делает prefetching JS для страниц с тяжелым взаимодействием, давая этим более тяжелым отрендеренным на клиенте страницам больше шансов на быструю загрузку.
Многие современные фреймворки, библиотеки и архитектуры позволяют отрисовывать одно и то же приложение как на клиенте, так и на сервере. Эти инструменты могут быть использованы для Server Rendering, однако важно отметить, что архитектуры, где рендеринг происходит как на сервере, так и на клиенте, являются собственным классом решений с очень различными характеристиками производительности и компромисами. React пользователи могут использовать для серверного рендеринга renderToString() или решения, построенные на нем, такие как Next.js. Пользователи Vue могут ознакомиться с руководством по серверному рендерингу Vue или познакомиться с Nuxt. В Angular есть Universal. Однако большинство популярных решений используют ту или иную форму гидратации (hydration), поэтому перед выбором инструмента следует ознакомиться с используемыми подходами.
Static Rendering (Статический рендеринг)
Решения для статического рендеринга бывают разных форм и размеров. Такие инструменты как Gatsby разработаны для того, чтобы разработчики чувствовали, что их приложение отрисовывается динамически, а не генерируется на этапе сборки. Другие, такие как Jekyll и Metalsmith, принимают их статическую природу, предоставляя подход более заточенный на шаблоны.
Одним из недостатков статического рендеринга является то, что отдельные HTML-файлы должны быть сгенерированы для каждого возможного URL. Это может быть сложно или даже невозможно, когда вы не можете предсказать, какими будут эти URL заранее, или если на сайте большое количество уникальных страниц.
Если вы не уверены, является ли решение статическим рендерингом или пре-рендерингом, попробуйте такой тест: отключите JavaScript и загрузите созданные веб-страницы. У статически отрендеренных страниц бОльшая часть функционала все равно будет существовать и без включённого JavaScript. У пре-рендеренных страниц все еще может быть некоторая базовая функциональность, такая как ссылки, но бОльшая часть страницы будет неживой.
Серверный рендеринг против статического
Серверный рендеринг генерирует HTML по требованию для каждого URL, но это может быть медленнее, чем просто обслуживание статически отрендереного контента. Если вы готовы сделать дополнительные усилия, то серверный рендеринг + [HTML кеширование] (https://freecontent.manning.com/caching-in-react/) может значительно сократить время серверного рендеринга. Положительной стороной серверного рендеринга является возможность получать более «живые» данные и отвечать на более полный набор запросов, чем это возможно при статическом рендеринге. Страницы, требующие персонализации, являются хорошим примером типа запроса, который плохо работает со статическим рендерингом.
Серверный рендеринг также может представлять интересные решения при построении PWA. Лучше ли использовать full-page service worker кеширование, или просто рендерить на сервере отдельные фрагменты контента?
Client-Side Rendering (CSR)
Рендеринг на стороне клиента (CSR) означает рендеринг страниц непосредственно в браузере с использованием JavaScript. Вся логика, сбор данных, шаблонирование и маршрутизация обрабатываются на клиенте, а не на сервере.
Для тех, кто создает одностраничное приложение, определение основных частей пользовательского интерфейса, разделяемого большинством страниц, означает возможность применить технику Application Shell caching. В сочетании с service workers это может драматически повысить воспринимаемую производительность при повторных визитах.
Комбинация серверного рендеринга и клиентского через регидратацию
Часто называемый Universal Rendering или просто «SSR», этот подход пытается сгладить компромиссы клиентского и серверного редеринга, делая и то, и другое. Навигационные запросы, такие как полная загрузка страницы или перезагрузка, обрабатываются сервером, который рендерит приложение в HTML, затем JavaScript и данные, используемые для рендеринга, встраиваются в результирующий документ. При тщательной реализации, это даёт быстрый FCP (First Contentful Paint) такой же, как Server Rendering, а далее «усиливает это» путем рендеринга опять же на клиенте с помощью техники, называемой (re)hydration ((ре)гидратация). Это новое решение, но оно может иметь некоторые существенные недостатки в производительности.
Основной недостаток SSR с регидратацией (rehydration) заключается в том, что она может оказать значительное негативное влияние на TTI (Time To Interactive), даже если она улучшает FP (First Paint). SSR-страницы часто выглядят обманчиво полностью загруженными и интерактивными, но на самом деле не могут реагировать на ввод, пока не будет выполнен JS на стороне клиента и не будут прикреплены обработчики событий. Это может занять секунды или даже минуты на мобильном устройстве.
= Проблема регидратации: Одно приложение по цене двух
Проблемы с регидратацией часто могут быть хуже, чем задержка интерактивности из-за JS. Для того, чтобы JavaScript на стороне клиента мог точно «определить» («pick up») то место, где остановился сервер, без необходимости повторно запрашивать все данные, использованные сервером для рендеринга этого HTML, текущие SSR решения обычно сериализуют ответ из зависимых данных UI в документ в виде тегов script. Полученный HTML-документ содержит высокий уровень дублирования:
Как вы видите, сервер возвращает описание пользовательского интерфейса приложения в ответ на навигационный запрос, но также возвращает исходные данные, использованные для составления этого интерфейса, и полную копию реализации интерфейса, которая затем загружается на клиенте. Только после того, как bundle.js завершит загрузку и выполнение, этот пользовательский интерфейс станет интерактивным.
Показатели производительности, собранные с реальных веб-сайтов, использующих SSR регидратацию, указывают на то, что их использование должно приводить в уныние. В конце концов, причина сводится к Пользовательскому Опыту: очень легко оставить пользователей в «жуткой долине».
Но всё же надежда на SSR с регидратацией есть. В краткосрочной перспективе, только использование SSR для высоко кешируемого содержимого может уменьшить задержку TTFB (Time to First Byte), давая результаты, схожие с пре-рендерингом. Регидратация инкрементальная, прогрессивная или частичная, может быть ключом к тому, чтобы сделать эту технику более жизнеспособной в будущем.
Потоковый серверный рендеринг и прогрессивная регидратация
Серверный рендеринг за последние несколько лет претерпел ряд изменений.
= Частичная регидратация
Частичная регидратация оказалась трудной для осуществления. Этот подход является продолжением идеи прогрессивной регидратации, когда отдельные части (компоненты / виджеты / деревья), подлежащие прогрессивной регидратации, анализируются, а те, которые обладают низкой интерактивностью или не обладают реактивностью помечаются. Для каждой из этих наиболее статических частей соответствующий код JavaScript затем трансформируется в инертные ссылки и декоративную функциональность, уменьшая их влияние на стороне клиента до почти нулевого уровня. Подход, основанный на частичной гидратации, имеет свои собственные проблемы и компромиссы. Он создает некоторые интересные вызовы для кеширования, а навигация на стороне клиента означает, что мы не можем иметь HTML рендерящийся на сервере для инертных частей приложения и доступный без полной загрузки страницы.
= Трисоморфный рендеринг (Trisomorphic Rendering)
Если service workers, являются подходящим вариантом для вас, то «трисоморфный» рендеринг также может быть вам интересен. Это метод, при котором вы можете использовать потоковый серверный рендеринг для начальных/не-JS навигаций, а затем попросить ваш service worker взять на себя рендеринг HTML для навигации после того как он будет смонтирован. Это может поддерживать кешированные компоненты и шаблоны в актуальном состоянии и позволяет использовать навигацию в стиле SPA для рендеринга новых UI-частей в той же сессии. Такой подход лучше всего работает, когда вы можете поделиться одним и тем же шаблоном и кодом маршрутизации между сервером, клиентской страницей и service worker.
SEO соображения
Команды часто учитывают влияние SEO при выборе стратегии для рендеринга в вебе. Серверный рендеринг часто выбирается для обеспечения поисковым роботам возможности лёгкого «полного поиска». Поисковые роботы могут понимать JavaScript, но часто существуют ограничения, о которых стоит знать в части того как они рендерят. Рендеринг на стороне клиента может работать, но часто не без дополнительного тестирования и трудной работы. В последнее время динамический рендеринг также стал вариантом, заслуживающим внимания, если ваша архитектура в значительной степени ориентирована на клиентский JavaScript.
В случае сомнений, инструмент Mobile Friendly Test бесценен для проверки, что выбранный вами подход делает то, что бы вы хотели. Он показывает визуальный предварительный просмотр того, как какую-либо страницу видет поисковый робот Google, сериализованный HTML контент, найденный (после выполнения JavaScript), и любые ошибки, обнаруженные во время рендеринга.
Заключение.
При принятии решения о подходе к рендерингу, измеряйте и понимайте, каковы ваши «узкие места». Подумайте, может ли статический рендеринг или серверный рендеринг дать вам хотя бы 90% возможностей. Совершенно нормально обычно отправлять HTML с минимальным количеством JS, чтобы получить интерактивный опыт. Вот удобная инфографика, показывающая спектр возможностей в разрезе сервер-клиент:
Благодарности
Спасибо всем этим людям за отзывы и вдохновение:
Jeffrey Posnick, Houssein Djirdeh, Shubhie Panicker, Chris Harrelson, and Sebastian Markbåge