🤔 Какие есть альтернативы ssr?

В современном веб-разработке существует несколько подходов к рендерингу веб-страниц, и помимо SSR (Server-Side Rendering), есть альтернативы, каждая из которых имеет свои особенности, преимущества и недостатки.

🚩CSR (Client-Side Rendering)

Вся логика рендеринга страницы осуществляется на стороне клиента (браузера) с помощью JavaScript. Сервер отправляет минимальный HTML (обычно пустой <div> с ID), а приложение загружается, рендерится и управляется на стороне клиента. Сервер отправляет статический HTML (например, через index.html), а JavaScript (чаще всего — библиотека/фреймворк, например React, Vue или Angular) загружает необходимые данные и динамически создает интерфейс.

<div id="app"></div>
<script src="bundle.js"></script>

🚩Плюсы

➕Быстрая работа после загрузки
Приложение становится очень интерактивным после инициализации.
➕Меньшая нагрузка на сервер
Основная работа выполняется на клиентской стороне.
➕Гибкость и модульность
Легко добавлять сложные интерактивные компоненты.

🚩Минусы

➖Медленная первая загрузка (Time to First Byte, TTFB)
Пользователь видит пустую страницу, пока загружается JavaScript и данные.
➕Проблемы с SEO
Поисковым системам сложнее индексировать страницы, так как контент рендерится только в браузере.
➖Требования к устройствам
Больше ресурсов требуется на стороне клиента.

🚩SSG (Static Site Generation)

Сайт полностью генерируется на этапе сборки (build time) и сервер отдает готовые HTML-страницы. Это популярный подход в JAMstack-приложениях (JavaScript, APIs, Markup). HTML генерируется один раз (обычно через фреймворк вроде Next.js, Gatsby, Nuxt.js) во время сборки. Сайт раздается пользователям как готовый статический контент.

npm run build

🚩Плюсы и минусы

➕Молниеносная загрузка
HTML статичен и отдается сервером без обработки.
➕SEO-дружелюбность
Поисковые системы могут легко индексировать готовый HTML.
➕Уменьшение нагрузки на сервер
Все вычисления выполняются заранее (во время сборки).
➖Ограничения при частых обновлениях контента
Для обновления нужно заново пересобирать сайт, что может занимать много времени.
➖Не подходит для динамических данных
Если страница сильно зависит от данных пользователя или часто меняется, SSG становится менее удобным.

🚩ISR (Incremental Static Regeneration)

Это гибрид между SSG и SSR. Вы создаете статический контент во время сборки, но некоторые страницы могут обновляться динамически при запросе, а сервер сохраняет их для следующих пользователей. Фреймворк (например, Next.js) генерирует страницы на этапе сборки, но для определенных страниц вы можете указать интервал обновления (revalidate). После этого сервер пересоберет страницу и кэширует ее.

export async function getStaticProps() {
  return {
    props: {
      data: fetchData(),
    },
    revalidate: 60, // Обновлять страницу каждые 60 секунд
  };
}

🚩Плюсы и минусы

➕Лучшая производительность
Страницы отдаются как статические, но обновляются при необходимости.
➕Гибкость
Удобно для контента, который редко обновляется.
➕SEO
Поисковики видят статические страницы.
➖Сложнее настроить
Нужно управлять кэшированием и интервалами обновления.
➖Не подходит для полностью динамических страниц
Если обновления контента слишком частые, ISR может не подойти.

🚩DPR (Dynamic Rendering / Hybrid Rendering)

Это подход, при котором разные версии страницы рендерятся для разных пользователей. Например, для пользователей с обычными браузерами вы используете CSR, а для поисковых ботов — SSR. Запросы от поисковых ботов обрабатываются сервером, который генерирует готовый HTML. Запросы от обычных пользователей обрабатываются через CSR. Этот подход используется с инструментами, такими как Prerender.io или встроенными решениями фреймворков.

🚩Плюсы и минусы

➕Оптимально для SEO
Боты получают готовый HTML.
➕Гибкость
Пользователи получают интерактивные страницы через CSR.
➖Усложнение архитектуры
Нужно отслеживать запросы и разделять их.
➖Задержки для ботов
Генерация страницы на сервере может занять время.

Ставь 👍 и забирай 📚 Базу знаний