Ssr и ssg разница

SSR и SSG — два совершенно разных подхода к рендеринга, которые определяют стоимость и скорость вашего приложения. SSR (server-side rendering) означает серверный рендеринг: при каждом запросе пользователя сервер генерирует готовые HTML-страницы и отправляет их в браузер. SSG (static site generation) работает радикально иначе, и в этом ssr и ssg разница: все страницы сайта генерируются один раз при сборке проекта и сохраняются как статические файлы. На практике это создаёт разные издержки. При SSR каждый запрос обрабатывается на сервере, требует вычислений, растёт нагрузка с трафиком. SSG хранит контент на CDN — быстро загружается в браузере, не зависит от количества пользователей. Реальный пример: компания выбрала SSR для своего блога вместо SSG и переплатила в 3 раза на серверных ресурсах. На стороне сервера выполняется весь рендеринг контента, на стороне клиента работает JavaScript. Next.js поддерживает оба подхода разработки, но выбор должен быть правильным для архитектуры вашего приложения.

Теперь давайте разберемся в деталях. На каждом запросе пользователя к приложению с SSR происходит вот что: браузер отправляет HTTP запрос на сервер, сервер получает этот запрос и начинает работу. При server-side rendering сервер выполняет весь рендеринга контента прямо сейчас — запрашивает данные из API, обращается к базе данных, выполняет бизнес логику, генерирует готовый HTML файл с полным содержимым, и отправляет этот HTML в браузер. Браузер получает уже отрендеренный контент и начинает его отображать. После этого JavaScript код выполняется и гидрирует компоненты React или Vue, добавляя интерактивность. На стороне клиента работает фреймворк, но большая часть работы уже сделана на сервере.

Механика SSR с примерами кода

Вот как это выглядит в Next.js с getServerSideProps:

javascript // SSR с getServerSideProps export async function getServerSideProps(context) { const { id } = context.params; const response = await fetch(https://api.shop.com/products/${id}); const product = await response.json();

return { props: { product: product, timestamp: new Date().toISOString() } } }

export default function ProductPage({ product, timestamp }) { return ( <div> <h1>{product.name}</h1> <p>Цена: {product.price}

Данные актуальны на: {timestamp}

) }

Каждый запрос к этой странице вызывает getServerSideProps. Сервер генерирует HTML с актуальной ценой и наличием товара. Это идеально для интернет магазина, где каталог постоянно меняется. Пользователь всегда видит свежий контент, но сервер должен выполнить все эти вычисления для каждого визитера. При 1000 одновременных запросов сервер создаёт 1000 копий этого процесса. Нагрузка на сервер растёт линейно с трафиком.

На Nuxt это работает с использованием middleware и ssr при конфигурации:

javascript // nuxt.config.ts export default defineNuxtConfig({ ssr: true, // сервер выполняет рендеринга на каждом запросе })

В Nuxt getServerSideProps заменяется на useAsyncData с опциями сервера, но суть остаётся той же.

Как работает SSG в реальном проекте

Static site generation работает совершенно по-другому. При сборке проекта getStaticProps вызывается один раз для каждой страницы, данные генерируются статические HTML-страницы, сохраняются как готовые файлы, и эти файлы загружаются на CDN. При static site generation нет необходимости в выполнении рендеринга на стороне сервера. Браузер просто получает готовый HTML файл из CDN — это происходит за миллисекунды.

javascript // SSG с getStaticProps export async function getStaticProps() { const response = await fetch('https://api.blog.com/articles'); const articles = await response.json();

return { props: { articles: articles }, revalidate: 86400 // пересборка раз в день } }

export async function getStaticPaths() { const articles = await fetch('https://api.blog.com/articles').then(r => r.json());

return { paths: articles.map(article => ({ params: { slug: article.slug } })), fallback: false } }

export default function ArticlePage({ articles }) { return ( <div> {articles.map(article => ( <article key={article.id}> <h2>{article.title}</h2> <p>{article.excerpt}

Здесь getStaticProps выполнится один раз при сборке проекта. Next.js обойдёт все маршруты (благодаря getStaticPaths), загрузит все статьи и создаст готовые HTML-файлы для каждого поста блога. Когда пользователь откроет страницу, сервер просто отдаст уже готовый файл. First contentful paint происходит на 50-70% быстрее, чем при server-side rendering, потому что нет ожидания вычислений на сервере. Time to first byte минимален.

Сравнение SSR vs SSG на практике

Давайте посмотрим на ключевые различия. SSR генерирует контент при каждом запросе пользователя. Это означает свежий контент в реальном времени. Но разработка сложнее, требуется управление кэшированием, обработка ошибок сервера, и скорость загрузки зависит от производительности вашего сервера, базы данных и сетевого подключения.

SSG генерирует все страницы заранее, статические страницы лежат на CDN. Разработка проще, нагрузка на сервер нулевая, производительность браузера лучше, потому что там нет JavaScript выполнения во время загрузки. Но требует пересборку при обновлении контента. Если вам нужно выпустить новую статью в блог, требует запустить build и переразвернуть приложение.

SSR (server-side rendering): - Динамический контент, который меняется часто - Каждый запрос требует выполнения на стороне сервера - Нагрузка на сервер растёт с трафиком - Медленнее first byte (требует время на рендеринга) - Стоимость серверных ресурсов выше - Сложнее в разработке и тестировании

SSG (static site generation): - Молниеносная загрузка при помощи CDN - Нулевая нагрузка на сервер (отдача готовых файлов) - First contentful paint и time to interactive в разы лучше - Требует пересборка проекта при обновлении контента - Меньше операционных затрат - SEO-дружелюбнее, потому что поисковые системы видят полный контент сразу - Подходит для контента, который меняется редко

На практике выбор зависит от типа приложения. Интернет магазина обычно требует SSR, потому что каталог продуктов постоянно обновляется. Блог отлично работает с SSG, потому что статьи публикуются несколько раз в неделю, а не каждую секунду. Документация использует SSG, потому что контент статичен и важна скорость загрузки. Новостной портал может использовать ISR — о нём ниже.

Гибридный подход: ISR (Incremental Static Regeneration)

Что делать, если нужна скорость SSG с динамичностью SSR? Вот где появляется ISR — incremental static regeneration. Это гибридный подход в Next.js и других фреймворках.

При ISR страницы генерируются один раз при сборке (как в SSG), но затем они автоматически стараются через заданный интервал времени. Вот как это работает:

javascript export async function getStaticProps() { const data = await fetch('https://api.news.com/latest').then(r => r.json());

return { props: { data }, revalidate: 60 // переосборка через 60 секунд } }

Параметр revalidate говорит: «Генерируй эту страницу при сборке, но через 60 секунд обновляй её в фоновом режиме». Первый пользователь видит быструю загрузку благодаря статике. Контент остаётся свежим благодаря фоновой регенерации. Система работает так: запрос получает кэшированный HTML, затем (если прошло время) запускает регенерацию в фоне, но пока страница генерируется, старая версия всё ещё отдаётся остальным пользователям.

ISR требует настройка, но результат стоит того. Нагрузка на сервер остаётся низкой, потому что просто генерируются файлы по расписанию, а не по требованию каждого визитера.

На Nuxt этот процесс происходит через routeRules:

javascript // nuxt.config.ts export default defineNuxtConfig({ routeRules: { '/blog/': { swr: 3600 }, '/products/': { cache: { maxAge: 300 } }, '/news/**': { swr: 60 } } })

Здесь swr означает stale-while-revalidate — генерируй статично, но обновляй в фоне через заданное время. cache работает как обычное кэширование.

Когда выбирать SSR, SSG или ISR

Вот практическое правило. Для интернет магазина с частыми обновлениями каталога — SSR или ISR, потому что пользователи должны видеть актуальные цены и наличие. Для блога с редкими публикациями — SSG, потому что статьи выходят несколько раз в месяц, и можно пересобрать сайт раз в день. Для корпоративного сайта или портфолио разработчика — SSG, потому что контент статичен. Для новостного портала, где важна скорость, но можно подождать пару минут до обновления — ISR, потому что он даёт лучшее из обоих подходов.

Помни: выбор рендеринга влияет на стоимость инфраструктуры. SSR требует постоянного содержания серверов. SSG и ISR позволяют запустить приложение на статических хостингах с минимальными затратами. Для стартапов это серьёзный аргумент.

Разработчик также должен учитывать сложность разработки. SSR требует больше внимания к обработке ошибок, кэшированию и оптимизации базы данных. SSG проще в поддержке, потому что это просто статические файлы. ISR требует найти правильный баланс между revalidate временем и свежестью контента.