SSG или SSR: как не переплатить за скорость и не сломать индексацию

SSG или SSR: как не переплатить за скорость и не сломать индексацию

Давайте разберем под капотом. SSG генерирует HTML заранее: страница отдается быстро, нагрузка на сервер минимальна, а лендинги и контентные страницы получают стабильный TTFB. SSR собирает HTML на каждый запрос: удобнее для персонализации и динамики, но цена — выше требования к серверу и больше точек отказа.

Практически это делится так: • SSG — если контент меняется редко, важны скорость, кеширование и простая доставка; • SSR — если на странице завязаны авторизация, фильтры, состояние пользователя или часто обновляемые данные; • гибрид — когда главная и посадочные статичны, а личный кабинет и каталог рендерятся на сервере.

Что по производительности? У SSG выигрывает первый экран и стабильность под пиками. У SSR быстрее появляются актуальные данные, но при плохом кешировании можно получить лишнюю задержку и просадку на ресурсе. Для лендинга с формой обычно хватает SSG + догрузка динамики после загрузки. Для страниц с персональными ценами и остатками SSR оправдан, но только если кеш продуман заранее.

Вердикт для продакшена: если страницу можно отдать без запроса к базе — делайте SSG. Если без запроса нельзя — используйте SSR, но режьте объем данных и кешируйте все, что не требует персонализации. Сначала определите, что должно быть в HTML, а что может приехать позже; именно это решает спор между быстрым сайтом и удобной системой.