Статические генераторы сайтов

Присмотритесь к сайту Доки. Для такого сайта нет смысла заново генерировать страницы при каждом запросе, потому что все посетители получают один и тот же контент. Таких сайтов очень много — блоги, документация, лендинги, портфолио. Гораздо эффективнее подготовить все страницы заранее и отказаться от их генерации на бэкенде при каждом открытии.

Именно для таких случаев существуют статические генераторы сайтов (Static Site Generators, SSG). Во время сборки проекта они преобразуют исходные файлы — Markdown, шаблоны и данные — в готовые HTML-страницы. Затем эти файлы можно разместить на CDN или обычном веб-сервере, и посетители будут получать уже готовый HTML без выполнения серверной логики. Никаких запросов к базе данных, никакого серверного рендеринга и практически никакого клиентского рендеринга — такой подход обеспечивает высокую производительность и отлично подходит для SEO.

Сам подход не новый. Для него даже существует отдельное название — JAMstack (JavaScript, APIs, Markup). Пик его популярности пришёлся на конец 2010-х годов, однако в 2024–2026 годах интерес к SSG снова вырос благодаря развитию островной архитектуры (Islands Architecture). Она устранила одно из главных ограничений классических SSG: вместо повторного выполнения JavaScript всего приложения в браузере (гидратации) браузер загружает код только для действительно интерактивных частей страницы — например, поиска, меню или формы.

В этой статье разберём, как устроена статическая генерация, в каких случаях она действительно оправдана, а когда лучше выбрать другой подход. Затем познакомимся с Islands Architecture, посмотрим, как её реализует Astro, и в завершение сравним более десяти современных SSG фреймворков — от проверенных временем Hugo и Jekyll до относительно новых решений вроде Qwik City.

Есть три основных способа рендеринга веб-страниц:

• На этапе сборки (build time): HTML собирается один раз, заранее, и сохраняется как файл. Это и есть SSG — статическая генерация;
• На каждый запрос (request time): сервер собирает HTML заново для каждого посещения. Это серверный рендеринг или SSR;
• В браузере: сервер отдаёт почти пустой HTML, а всю разметку строит JavaScript уже на клиенте. Это клиентский рендеринг — CSR.

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

Производительность. HTML генерируется заранее, поэтому серверу не нужно собирать страницу при каждом запросе. Это уменьшает метрику «время до первого байта» TTFB, а благодаря размещению файлов на CDN контент доставляется пользователю с ближайшего узла сети, а не из одного дата-центра. Как правило, это положительно влияет и на LCP. Подробнее о связи этих метрик — в разделе о Web Vitals.

Безопасность. Статический сайт не выполняет серверный код при обработке запросов, поэтому целый класс уязвимостей просто отсутствует. Здесь не возникает SQL-инъекций, ошибок в серверной логике или других атак, связанных с обработкой пользовательских запросов. Злоумышленник получает только готовые статические файлы, а не доступ к работающему приложению.

Простой и дешёвый хостинг. Статику можно раздавать буквально с любого CDN, часто бесплатно или почти бесплатно (GitHub Pages, Netlify, Vercel). Не нужно платить за работающий сервер.

SEO. Хотя современные поисковые роботы умеют рендерить клиентский Javascript, но более быстрая загрузка напрямую влияет на ранжирование через сигнал Page Experience (снова отсылка к Core Web Vitals). А поскольку HTML полностью готов уже при первом ответе, поисковым роботам не нужно ждать выполнения JavaScript, чтобы увидеть контент.

Время сборки растёт вместе с сайтом. Если у вас десятки тысяч страниц, пересборка всего сайта на каждое изменение может занимать до нескольких часов, в зависимости от инструмента. Здесь огромная разница между генераторами: Hugo и Zola (написаны на Go и Rust соответственно) собирают тысячи страниц за секунды, а JS-инструменты, которые на каждую страницу делают отдельный запрос к внешнему API, могут работать на порядки медленнее.

Контент устаревает между сборками. Если контент поменялся, а сайт не пересобрали и не задеплоили заново — посетитель увидит старую версию. Часть инструментов смягчает проблему инкрементальными сборками — у Gatsby это Incremental Builds (сборка только изменённых данных) и Deferred Static Generation (менее приоритетные страницы достраиваются по первому запросу), у Next.js — уже упомянутый ISR.

Персонализация не работает «из коробки». Раз каждый посетитель получает одинаковый заранее собранный HTML. Контент, зависящий от пользователя (корзина, рекомендации, авторизованный кабинет), приходится добавлять поверх, клиентским JavaScript или через промежуточный код на CDN-узлах (edge middleware, например, для куки-баннеров).

Отсюда практический вывод: SSG плохо подходит для e-commerce платформ и сильно динамических интерфейсов. Для них обычно выбирают гибридные режимы, тот же ISR у Next.js и Nuxt.js.

Классический подход рендерит страницу в HTML на этапе сборки, но при загрузке в браузере всё равно гидрирует (hydrate) её целиком через DOM, то есть заново выполняет весь JavaScript фреймворка поверх готовой разметки, чтобы навесить обработчики событий и сделать компоненты рабочими. Даже если из всей страницы интерактивна одна кнопка «Подписаться», браузер всё равно скачивает и выполняет JS всего приложения. Именно эта тяжёлая работа на главном потоке портит INP.

Islands Architecture меняет старый подход: страница по умолчанию — чистый статический HTML без единого байта JavaScript. Интерактивными делаются только явно отмеченные куски HTML, или «острова» — небольшие изолированные компоненты, каждый из которых гидрируется независимо и параллельно остальным, без общего рантайма, блокирующего всю страницу целиком. Разные острова на одной странице могут даже использовать разные UI-фреймворки одновременно.

Самый известный пример такого подхода — фреймворк Astro. В нём набор директив управляет тем, когда остров получит JavaScript:

• client:load — гидрировать сразу при загрузке страницы. Для критичной интерактивности, которая должна работать мгновенно;
• client:idle — гидрировать, когда браузер сообщит о простое главного потока (requestIdleCallback). Подходит для несрочных виджетов;
• client:visible — гидрировать только когда остров попадает в область видимости, через Intersection Observer. Хороший выбор для всего, что находится ниже первого экрана;
• client:media — гидрировать только при совпадении медиазапроса, например, только на мобильных экранах;
• client:only — полностью пропустить серверный рендеринг и рендерить остров исключительно на клиенте, с явным указанием фреймворка.

Astro не единственный фреймворк, кто решает эту задачу, но подходы различаются:

• Fresh (фреймворк для рантайма Deno) реализует Islands Architecture на Preact, с нулевым JS по умолчанию;
• Qwik / Qwik City идёт другим путём — резюмируемостью (resumability): сервер сериализует достаточно состояния в HTML, чтобы браузер мог «возобновить» выполнение вообще без повторной гидрации. Формально это не Islands Architecture, но идею постоянно сравнивают именно с ней, поскольку цель та же — не выполнять лишний JS;
• Marko (изначально написан в eBay) выбирает частичную гидратацию автоматически, на этапе компиляции, без ручных директив вроде client:*;
• Enhance строит острова на нативных Web Components, без виртуального DOM.

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

Next.js — самый популярный React-фреймворк, и статическая генерация в нём — один из нескольких режимов рендеринга наравне с SSR, ISR и клиентским рендерингом. Флаг output: 'export' собирает сайт в полностью статичные файлы, разворачиваемые где угодно, но при этом отключает серверные возможности фреймворка: ISR, ревалидацию по запросу, Server Actions, серверную оптимизацию изображений.

Подходит командам, уже работающим с React/Next.js, которым нужен статический билд без внедрения второго инструмента и с возможностью позже перейти на SSR/ISR внутри того же фреймворка.

Плюсы: один фреймворк закрывает и статику, и динамику, огромная экосистема, частые релизы.

Минусы: в режиме экспорта теряется большая часть фирменных возможностей Next.js. Статические маршруты должны быть полностью перечислены на этапе сборки. По умолчанию гидрирует страницы целиком, без Islands Architecture — хуже значения Core Web Vitals, чем у его конкурентов. Очень часто меняются внутренние инструменты из-за активного развития.

Gatsby — React-генератор, построенный вокруг единого GraphQL-слоя данных: любые источники контента (CMS, файловая система, переводы текстов, API) объединяются в один запрашиваемый граф на этапе сборки. Из полезного здесь же — Incremental Builds (пересборка только изменившихся данных) и Deferred Static Generation (не все страницы создаются во время сборки).

Плюсы: зрелая экосистема плагинов, мощный слой данных, инкрементальные сборки реально помогают на больших существующих сайтах.

Минусы: нет Islands Architecture — гидрируется как обычное React-приложение. После покупки Gatsby компанией Netlify в 2023 году проект перешёл в режим поддержки; только фиксы безопасности и мелкие правки, без заметных новых возможностей и публичного роадмапа больше года. Также существует проблема сборки очень больших проектов (более 100000 страниц) — может занимать несколько часов. В большинстве актуальных сравнений 2026 года Gatsby не рекомендуют для новых проектов: выбирайте Astro или Next.js.

Docusaurus — React-генератор, сделанный специально под документацию. Контент пишется в Markdown/MDX (Markdown с возможностью вставлять React-компоненты прямо в текст).

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

Минусы: как и у Next.js/Gatsby, гидратация полностью на всю страницу, без островов — тяжелее эквивалентных docs-инструментов вроде VitePress при том же объёме контента.

Nuxt — Vue-аналог Next.js по роли в экосистеме. Команда nuxt generate обходит и заранее рендерит все маршруты, включая динамические, в статический HTML. Отдельного внимания заслуживает Nuxt Content — модуль, превращающий Markdown/YAML/JSON в запрашиваемый слой контента, вплоть до встроенной SQLite-базы через WebAssembly для запросов прямо на клиенте.

Плюсы: сильная интеграция с Vue-экосистемой, Nuxt Content — по-настоящему встроенная альтернатива headless CMS, гибкие режимы рендеринга по каждому маршруту отдельно.

Минусы: для статической генерации динамических маршрутов нужно явно настраивать краулинг ссылок или список путей, иначе часть контента может незаметно выпасть из статической сборки. Экосистема меньше, чем у React-стороны рынка.

VitePress — генератор на Vue 3 и Vite, официально поддерживаемый командой Vue как преемник VuePress. Ориентирован специально на документацию: Markdown-контент с возможностью встраивать Vue-компоненты.

Плюсы: очень быстрая сборка и dev-сервер за счёт Vite, официальный статус в экосистеме Vue.

Минусы: нишевый инструмент именно под документацию, не универсальный генератор. Перед использованием стоит свериться с актуальной версией напрямую в документации, поскольку экосистема Vite/Vue развивается довольно активно.

VuePress — предшественник VitePress. Первая версия построена на Vue 2 и Webpack и считается устаревшей. Вторая версия перешла на Vue 3 и поддерживает как Webpack, так и Vite, но теперь развивается силами сообщества, а не основной командой Vue.

Плюсы: гибкость сборщика (в отличие от VitePress, который построен только на Vite), больше возможностей кастомизации через темы и плагины.

Минусы: официальное направление команды Vue — именно VitePress. VuePress стоит выбирать осознанно, когда нужна существующая экосистема плагинов VuePress.

Astro — инструмент, который сделал Islands Architecture популярным. Собственный синтаксис компонентов .astro (HTML с расширениями) сочетается с возможностью встраивать компоненты React, Vue, Svelte, Solid или Preact — каждый из них возможно встроить как отдельный остров, гидрируемый независимо.

Плюсы: нулевой JavaScript по умолчанию, фреймворк-независимость компонентов, Content Collections — механизм хранения контента для типобезопасной работы с Markdown/MDX-контентом. По опросу State of JS 2025 — самый высокий показатель удовлетворённости среди всех мета-фреймворков, с отрывом в 39 процентных пунктов от Next.js.

Минусы: экосистема плагинов намного моложе, чем у Next.js или Gatsby, хотя растёт быстро. SSR-режим (для динамических сценариев) менее развит, чем чисто SSG. API Content Collections всё ещё меняется между версиями.

Fresh — фреймворк на Preact с использованием Deno. Также построен вокруг концепции Islands Architecture. Сейчас проект переехал из-под организации Deno (denoland/fresh) в отдельную организацию freshframework/fresh.

Плюсы: нативная поддержка островов, лёгкий Preact-рантайм, тесная интеграция с экосистемой Deno.

Минусы: меньшая аудитория за пределами Deno-экосистемы по сравнению с Astro. Перед использованием стоит свериться с актуальным статусом проекта на сайте фреймворка.

Qwik City — надстройка-роутер над Qwik, фреймворком, построенном на идее резюмируемости (resumability). Вместо повторного выполнения JS при гидратации браузер «возобновляет» уже отрендеренное на сервере состояние. Поддерживает статическую предгенерацию как один из вариантов деплоя.

Плюсы: теоретически ещё меньше JS на старте, чем у Astro, поскольку сама гидратация не нужна как процесс.

Минусы: на середину 2026 года вторая версия Qwik всё ещё в бета-статусе — инструмент моложе и менее используется в проде, чем Astro, Hugo или Eleventy.

Marko — фреймворк, изначально созданный в eBay, сочетающий потоковый SSR с автоматической частичной гидратацией: компилятор сам определяет, каким компонентам нужен клиентский JS, без ручных директив вроде client:* у Astro.

Плюсы: гидратация «из коробки» без разметки директив, потоковый рендеринг заточен под очень большие страницы.

Минусы: узнаваемость и комьюнити заметно меньше, чем у Astro.

Enhance — HTML-first подход к островам поверх нативных Web Components, без виртуального DOM и без встроенного UI-фреймворка вообще.

Плюсы: минимум зависимостей, философия прогрессивного улучшения, ближе к платформенным стандартам, чем к экосистеме конкретного фреймворка.

Минусы: нишевый инструмент с небольшим сообществом. Прежде чем строить на нём продакшен-проект, стоит оценить риски вокруг доступности плагинов и поддержки.

Hugo написан на Go и собирается в единственный бинарный файл — никакой зависимости от Node.js или другого рантайма для сборки не требуется. Считается одним из самых быстрых генераторов: тысячи страниц собираются за секунды, что делает его популярным выбором именно для очень больших сайтов.

Плюсы: исключительная скорость сборки, ноль рантайм-зависимостей, зрелость и стабильность.

Минусы: собственный синтаксис шаблонов html/template на Go многие считают неудобным по сравнению с шаблонизаторами вроде Jinja, где логика вставляется прямо в разметку через {% %} и {{ }}. Нет компонентной модели для интерактивности — любую динамику приходится писать вручную на чистом JS.
1#### Zola

Zola написан на Rust и, как и Hugo, собирается в единственный бинарный файл, со встроенной обработкой Markdown, компиляцией Sass, обработкой изображений, подсветкой синтаксиса и генерацией поискового индекса, без единой внешней зависимости. Шаблонизатор — Tera, синтаксис в духе Jinja/Django/Liquid. Во многом Zola появилась как реакция на неудобство синтаксиса шаблонов Hugo.

Плюсы: та же скорость сборки, что и у Hugo, но более привычный синтаксис шаблонов, и всё нужное встроено без дополнительных инструментов.

Минусы: экосистема тем и интеграций заметно меньше, чем у Hugo или Jekyll.

Jekyll написан на Ruby и был родным генератором GitHub Pages. Он собирает Jekyll-сайты автоматически, без настройки отдельного CI. Шаблонизатор — Liquid.

Плюсы: нулевая настройка при хостинге на GitHub Pages, простая модель, огромное наследие готовых тем.

Минусы: Ruby-тулчейн — барьер для команд, привыкших к JS-инструментам. Скорость сборки заметно отстаёт от Hugo и Zola на больших объёмах. Версия Jekyll, которую фактически использует GitHub Pages, зафиксирована и отстаёт от последнего релизной версии проекта. Сам проект развивается медленно — последний стабильный релиз вышел больше полутора лет назад, что заметно дольше, чем у любого другого активно рекомендуемого инструмента из списка.

Eleventy — Node.js-инструмент без JS-фреймворка на клиенте: пишете обычные HTML/CSS/JS или любой из поддерживаемых шаблонизаторов (Nunjucks, Liquid, Handlebars, Pug, EJS, Markdown). В частности, Дока использует именно Eleventy.

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

Минусы: здесь стоит отметить важное изменение: весной 2026 года проект объявил о ребрендинге в «Build Awesome» с платным профессиональным тарифом поверх бесплатного ядра. Официальная позиция авторов — открытый исходный код остаётся бесплатным навсегда и полностью совместимым с существующими плагинами и командами сборки, а платные функции — это визуальный редактор, премиум-темы и инструменты для совместной работы поверх ядра фреймворка. Запущенный краудфандинг собрал цель за день, но был приостановлен через несколько дней после неоднозначной реакции сообщества. На момент написания статьи процесс ещё не завершён, стоит свериться с текущим статусом перед тем, как опираться на эту информацию в проекте.

Hexo — генератор на Node.js с экосистемой плагинов, по духу напоминающей WordPress. Регулярно встречается в актуальных подборках как жизнеспособный выбор для личных блогов.

Плюсы: знакомый многим блогерам процесс работы, богатый выбор тем.

Минусы: менее заметен в профессиональных/корпоративных сравнениях по сравнению с остальными инструментами из списка. Стоит оценивать как нишевый выбор именно для личных проектов.

Pelican — генератор на Python, также периодически всплывающий в подборках как вариант для блогов и хронологического контента.

Плюсы: удобен командам, уже работающим на Python.

Минусы: заметно меньшее сообщество и экосистема по сравнению с лидерами этого обзора.

SvelteKit — полноценный фреймворк для Svelte с несколькими режимами рендеринга (SSR, статика, гибрид), а не выделенный SSG. Статический экспорт достигается через adapter-static. Islands Architecture в явном виде здесь нет, но компилятор Svelte и без того производит компактный рантайм по сравнению с React или Vue.

Плюсы: маленький рантайм благодаря компилятору Svelte даже без островной архитектуры, тот же фреймворк закрывает и статические, и динамические сценарии.

Минусы: не специализированный SSG-инструмент — статика здесь один из режимов общего фреймворка, а не основная идея.

Ключевые критерии, которые реально используют при выборе:

1. Стек и язык команды. Команде на React естественно подойдут Next.js, Gatsby или Docusaurus. Команде на Vue — Nuxt, VitePress или VuePress. Если хочется избежать привязки к конкретному UI-фреймворку — Astro, Hugo, Zola, Jekyll или Eleventy.
2. Тип контента. Блог или личный сайт: почти любой инструмент справится, чаще всего берут Eleventy, Hugo, Jekyll, Hexo или Astro. Документация — VitePress (если команда в экосистеме Vue) или Docusaurus (если нужно версионирование и команда на React). Контентный/маркетинговый сайт с редкими интерактивными виджетами — идеальный случай для Astro. E-commerce и сильно динамичный интерфейс: чистый SSG обычно не подходит, нужен гибридный режим.
3. Масштаб сборки. Если счёт страниц идёт на тысячи, а время сборки критично — присмотритесь к Hugo или Zola. JS-инструменты остаются быстрыми на небольшом и среднем масштабе, но на крупных сайтах требуют инкрементальных сборок (Gatsby Incremental Builds, Next.js ISR).
4. Зрелость экосистемы плагинов и тем. У Jekyll, Hugo и Gatsby — самая долгая история готовых тем и плагинов. У Astro экосистема моложе, но растёт быстро. У Zola и Fresh — самая небольшая коллекция.
5. Потребность в интерактивности. Если сайт в основном статичен, но местами нужны насыщенные виджеты, островные инструменты (Astro, Fresh) выигрывают. Если интерактивность минимальна и достаточно чистого JS — подойдёт любой компилятор без UI-фреймворка.
6. Процесс редактирования контента. Git-based Markdown-процесс удобен разработчикам, но плохо подходит нетехническим редакторам. Если контентом занимается не только команда разработки, стоит присмотреться к инструментам с сильной интеграцией headless CMS — слою данных Gatsby, Nuxt Content, или к любому SSG в связке с отдельной headless CMS и вебхуком на пересборку на CI/CD.
7. Модель стоимости хостинга. Чисто статический вывод (Astro, Eleventy, Hugo, Zola, Jekyll) размещается почти бесплатно на любом CDN. Инструменты, которые даже в «статическом» режиме опираются на серверные функции (Next.js с ISR, Nuxt с SSR), тянут за собой постоянные расходы на serverless-вычисления, если принудительно не запретить.

Концепция и рендеринг:

• Islands architecture, patterns.dev.
• Static site generation vs server-side rendering, web.dev — контекст про TTFB/LCP в связке с рендерингом.
• Jamstack — generators directory, Jamstack.org.

Официальная документация генераторов:

• Astro: Islands, Client directives, Framework components.
• Eleventy — документация.
• Gatsby: GraphQL data layer, Incremental Builds, Deferred Static Generation.
• Hugo — документация.
• Jekyll — документация, история релизов.
• Next.js: Static exports.
• Nuxt Content — статический деплой.
• VitePress, VuePress.
• Docusaurus — документация.
• Zola — документация.
• Fresh.
• Qwik City.
• Marko.

Статус проектов и обсуждения сообщества:

• Is GatsbyJS Officially Dead? — обсуждение на GitHub.
• Build Awesome — анонс ребрендинга Eleventy.
• 11ty pauses its rebrand Kickstarter.

Опросы и данные:

• State of JS 2025 — Meta-frameworks.

На практике

Скопировать ссылку "На практике" Скопировано

Дмитрий Шмаков советует

Скопировать ссылку "Дмитрий Шмаков советует" Скопировано

🛠 Чаще всего команда выбирает генератор не по критериям из статьи, а по инерции: «мы же на React, значит, берём что-то на React». Из-за этого немало проектов, которым нужен был чисто контентный сайт без единой строчки клиентской логики, оказываются на Next.js или Gatsby, с гидратацией всего приложения там, где хватило бы пары статических HTML-страниц.

Стоит хотя бы один раз честно спросить: «а нужна ли этой странице интерактивность вообще?» Если ответ «почти нет» — Islands Architecture (Astro, Fresh) или чистый компилятор без фреймворка (Hugo, Eleventy, Zola) почти всегда даст меньше JS и лучший Core Web Vitals при том же уровне удобства разработки, что и привычный React-стек.