🤔 Какие есть альтернативы 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.
➖Усложнение архитектуры
Нужно отслеживать запросы и разделять их.
➖Задержки для ботов
Генерация страницы на сервере может занять время.
Ставь 👍 и забирай 📚 Базу знаний
