<b>Static site generator — не “просто блог”, а способ урезать поверхность поломок</b>

<b>Static site generator — не “просто блог”, а способ урезать поверхность поломок</b>

За неделю в репах: большинство проблем у SSG-проектов не в генерации, а в границе между статикой и динамикой.

• Если контент меняется редко — выносите его в сборку, а не в рантайм. Это снижает число запросов, упрощает кеширование и делает поведение страницы предсказуемым.
• Если нужен интерактив — изолируйте его в маленькие острова, а не тащите весь UI в клиент.
• Если есть маршруты с разной частотой обновления, разделяйте их по режимам: pre-render для стабильного, SSR/ISR-подобный подход для живого.

Есть наблюдение которое стоит проверить: многие команды переоценивают “полную статичность” и недооценивают стоимость пересборки. Чем больше данных вшито в HTML, тем важнее инкрементальная генерация, отдельные чанки и понятная стратегия invalidate. Иначе быстрый сайт превращается в медленный pipeline.

Проверьте перед запуском: нет ли на странице случайного доступа к window, не тянется ли тяжелый клиентский код без нужды, и не ломает ли hydration то, что можно было отдать как обычную разметку. Если этих ошибок нет, SSG обычно дает лучший баланс скорости, простоты и контроля.