SSG vs SSR vs ISR: как выбрать стратегию рендеринга для сайта

Я Максим, веб-разработчик. Если вы работаете с Next.js, Nuxt или Astro — вопрос «как рендерить страницы» встаёт на каждом проекте. Static Site Generation, Server-Side Rendering, Incremental Static Regeneration — три подхода с разными плюсами и ограничениями. Выбрать не так просто, как кажется по описанию в документации: у каждого подхода есть подводные камни, о которых узнаёшь только в бою. Давайте разберём это на реальных примерах.

SSG — статическая генерация: когда скорость решает

Суть SSG проста: все страницы генерируются один раз на этапе сборки проекта. Результат — набор готовых HTML-файлов, которые раздаются с CDN без участия сервера. Никакого Node.js в рантайме, никаких баз данных при каждом запросе. Пользователь запрашивает страницу — получает её мгновенно из ближайшего узла CDN.

Я использую SSG для блогов, документации, лендингов, сайтов-визиток, портфолио — словом, для любого контента, который обновляется редко и не зависит от конкретного пользователя. Например, мой собственный блог собирается статически: я пишу статью в Markdown, делаю коммит, CI/CD запускает билд, и через пару минут обновлённый сайт уже на CDN.

Главные плюсы SSG:

• Скорость загрузки — максимально возможная, потому что сервер не тратит время на генерацию
• Минимальная стоимость хостинга: статические файлы можно раздавать хоть с GitHub Pages, хоть с Vercel бесплатно
• Безопасность — атаковать нечего, потому что серверной логики при обслуживании запросов нет
• Отличные показатели Core Web Vitals: TTFB стремится к нулю, LCP и CLS легко контролировать

Но есть реальные ограничения, которые я прочувствовал на практике. Однажды я делал каталог для клиента — около 12 000 товарных страниц. На SSG билд занимал 40 минут. Каждое изменение описания одного товара требовало пересборки всего сайта. Это было неприемлемо: менеджер обновлял цены два-три раза в день, а ему приходилось ждать деплоя почти час. Мы перешли на ISR, и проблема исчезла.

SSG не подходит для страниц с персонализацией (личный кабинет, корзина, рекомендации «для вас»), для контента, который обновляется чаще раза в день, и для проектов с огромным количеством страниц, где билд затягивается.

SSR — серверный рендеринг: актуальность в реальном времени

При SSR каждый запрос пользователя обрабатывается сервером: Node.js-процесс получает данные из базы или API, формирует полноценный HTML и отправляет его клиенту. Контент всегда свежий — никакого кэша, никаких устаревших данных.

Я выбираю SSR, когда проект требует актуальности данных в реальном времени. Типичные сценарии:

• Интернет-магазин с быстро меняющимися остатками и ценами — если клиент видит «В наличии», а на складе товара уже нет, это прямые потери
• Новостные сайты, где свежий материал должен быть доступен мгновенно после публикации
• Дашборды и аналитические панели с персонализированными данными
• Страницы с результатами поиска, фильтрации, сортировки — где контент зависит от параметров запроса

У SSR есть очевидная цена: каждый запрос нагружает сервер. На проекте с трафиком в 50 000 уникальных посетителей в день это ощутимо. Мне приходилось масштабировать серверы, когда один из клиентских интернет-магазинов попал в топ Яндекса по высокочастотным запросам — нагрузка выросла в четыре раза за неделю. Без грамотного кэширования SSR превращается в бутылочное горлышко.

Ещё один момент: для SSR нужен полноценный Node.js-сервер или serverless-функции. Обычный shared-хостинг за 200 рублей в месяц не подойдёт. Это не проблема для серьёзного бизнеса, но для маленького проекта может быть избыточным.

На практике я почти всегда добавляю к SSR слой кэширования: Redis на стороне сервера или stale-while-revalidate на уровне CDN. Это снимает нагрузку, но добавляет сложность в инфраструктуру.

ISR — инкрементальная регенерация: лучшее из двух миров

ISR — это гибрид SSG и SSR, и именно его я использую на большинстве проектов на Next.js. Принцип работы такой: страницы генерируются статически при первом запросе, а затем обновляются в фоне через заданный интервал. Пользователь всегда получает кэшированную версию мгновенно, а через указанное время (например, 60 секунд) при следующем запросе сервер перегенерирует страницу в фоне.

Вот как это выглядит на практике. Допустим, у вас каталог из 5 000 товаров. При первой сборке вы генерируете только 100 самых популярных страниц (это занимает секунды). Остальные 4 900 генерируются «по требованию» — при первом запросе пользователя. После генерации страница кэшируется и отдаётся статически всем последующим посетителям. Через заданный интервал (revalidate) она обновится.

Почему ISR — мой выбор по умолчанию:

• Скорость SSG — страницы раздаются из кэша мгновенно
• Актуальность данных — с допустимой задержкой в минуты, а не часы
• Нет проблемы долгих билдов — не нужно пересобирать весь сайт при каждом изменении
• Масштабируемость — CDN берёт на себя основную нагрузку, сервер обрабатывает только фоновую регенерацию

У меня был проект — сайт сети фитнес-клубов с расписанием занятий. Расписание менялось раз в неделю, но изредка тренер мог перенести занятие за пару часов. SSG не подходил — пришлось бы каждый раз деплоить. SSR — избыточно, нагрузка ни к чему. ISR с интервалом revalidate в 300 секунд (5 минут) оказался идеальным решением: расписание обновлялось достаточно быстро, а нагрузка на сервер была минимальной.

Есть у ISR и ограничение: если контент должен обновляться мгновенно для каждого конкретного пользователя, ISR не спасёт. Корзина, личный кабинет, лента уведомлений — для этого по-прежнему нужен SSR или клиентский рендеринг.

On-Demand Revalidation: точечное обновление

В Next.js есть механизм On-Demand Revalidation — когда вы можете принудительно перегенерировать конкретную страницу через API-вызов. Я активно использую эту возможность: менеджер обновил карточку товара в CMS — вебхук вызывает revalidate для этой конкретной страницы. Обновление происходит за 1–2 секунды, без ожидания интервала.

Это снимает главную претензию к ISR — задержку обновления. С On-Demand Revalidation вы получаете скорость статики, но обновления применяются практически мгновенно, когда это нужно.

Как я комбинирую подходы в реальных проектах

На практике в одном проекте я никогда не использую только один подход. Next.js позволяет выбирать стратегию рендеринга для каждого маршрута отдельно, и я этим активно пользуюсь. Вот типичная архитектура среднего интернет-магазина, которую я выстраиваю:

• Главная страница — ISR с revalidate 300 секунд. Обновляется достаточно часто, чтобы отображать актуальные акции и хиты продаж
• Страницы категорий — ISR с revalidate 600 секунд. Структура каталога меняется нечасто
• Карточки товаров — ISR с On-Demand Revalidation при изменении в CMS. Мгновенное обновление цен и остатков
• Блог и статьи — SSG. Контент обновляется только при деплое, зато максимальная скорость
• Личный кабинет, корзина, оформление заказа — SSR или клиентский рендеринг. Данные персональные, кэшировать нельзя
• Политика конфиденциальности, условия использования — SSG. Статические страницы, которые меняются раз в год

Такой гибридный подход даёт наилучший баланс между скоростью, актуальностью и нагрузкой на инфраструктуру.

SEO-аспект: все три подхода равноценны

Этот вопрос мне задают постоянно, поэтому поставлю точку: для SEO разницы между SSG, SSR и ISR практически нет. Все три подхода отдают поисковому роботу готовый HTML с полным содержимым страницы. Яндекс и Google получают контент без необходимости выполнять JavaScript.

Это принципиальное отличие от чистого SPA (Single Page Application), где React или Vue рендерят контент на стороне клиента. Поисковые роботы могут обработать JavaScript, но делают это медленно, ненадёжно и с задержкой в индексации. Для коммерческих сайтов это неприемлемый риск.

С точки зрения Core Web Vitals (а Яндекс учитывает эти метрики после обновления «Циолковский»), SSG и ISR имеют небольшое преимущество перед SSR за счёт более быстрого TTFB. Но на практике при грамотном кэшировании разница в миллисекундах, и она не влияет на позиции.

Мой совет: выбирайте стратегию рендеринга по бизнес-требованиям, а не по SEO. Если сайт отдаёт готовый HTML — с точки зрения поисковиков всё в порядке.

Частые ошибки, которые я вижу в чужих проектах

За годы практики я регулярно сталкиваюсь с типичными ошибками в выборе стратегии рендеринга:

Всё на SSR «на всякий случай». Разработчик ставит SSR для каждой страницы, включая статические. Результат — повышенная нагрузка на сервер и замедление отклика без какой-либо выгоды. Страница «О компании» не нуждается в серверном рендеринге при каждом запросе.

SSG для динамического каталога. Обратная крайность — пытаются собирать каталог из 10 000 товаров чисто статически. Билд растягивается, менеджеры ждут обновления часами, а на хостинге заканчивается оперативная память при сборке.

ISR с неправильным интервалом. Ставят revalidate: 1 (одну секунду) — и получают, по сути, SSR с дополнительной сложностью. Или наоборот — revalidate: 86400 (сутки) для каталога с ежедневным обновлением цен.

Забывают про fallback-стратегию. В ISR важно определить, что показывать при первом запросе ещё не сгенерированной страницы: loading-состояние (fallback: true) или 404 с последующей генерацией (fallback: 'blocking'). Неверный выбор влияет и на UX, и на индексацию.

Сравнительная таблица для быстрого выбора

Итог: мой алгоритм принятия решения

Когда ко мне приходит клиент с новым проектом, я задаю три вопроса, и ответы на них определяют стратегию:

Контент публичный и одинаковый для всех? Если нет — SSR (или клиентский рендеринг для приватных разделов). Если да — идём дальше.

Контент обновляется чаще раза в день? Если нет — SSG. Если да — ISR.

Допустима ли задержка обновления в 1–10 минут? Если да — ISR. Если нет — SSR с кэшированием.

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