Hugo или Astro: что выгоднее и когда

MAATRIX

Выбор между Hugo и Astro регулярно превращается в холивар в чатах разработчиков, хотя на практике это два инструмента с разной специализацией. Один — минималистичный генератор на Go, который собирает тысячи страниц за секунды и не тянет за собой ничего лишнего. Второй — современный фреймворк с архитектурой «островков», который умеет то, чего Hugo не умеет в принципе: встраивать интерактивные React- или Vue-компоненты прямо в статический HTML. Разберём честно, по каким критериям сравнивать, и в каком сценарии какой инструмент реально выгоднее — с точки зрения времени сборки, ресурсов сервера и денег, которые вы платите за хостинг.

Что это вообще: Go-генератор против фреймворка с островками

Hugo — это один бинарник на Go без внешних зависимостей. Вы пишете контент в Markdown, шаблоны — на языке шаблонов Go ({{ .Title }}, {{ range .Pages }}), и на выходе получаете папку public/ с чистым HTML, CSS и минимумом JS, если вы сами его не добавили. Никакого Node.js на сборочном сервере, никакого node_modules, никаких неожиданных 400 МБ зависимостей после npm install.

Astro устроен принципиально иначе. Это фреймворк на Node.js с архитектурой Islands: страницы по умолчанию рендерятся в статический HTML на этапе сборки, но отдельные интерактивные компоненты («островки») можно писать на React, Vue, Svelte, Solid или Preact — и JS для них подгружается на клиенте только там, где он реально нужен (директивы client:load, client:visible, client:idle). Это даёт гибкость: карточка товара с состоянием, форма с валидацией, интерактивный график — всё это встраивается в статическую страницу без превращения всего сайта в SPA.

Разница философий определяет всё остальное сравнение: Hugo — про скорость и простоту для контента, Astro — про гибкость и композицию UI-компонентов поверх контента.

Скорость сборки: где Hugo рвёт всех

Здесь спорить особо не о чем. Hugo написан на Go, использует параллельную обработку страниц и не тратит время на транспиляцию JSX, обработку бандлов или разрешение зависимостей npm. Сайт на несколько тысяч страниц (документация, каталог, блог с архивом за годы) собирается у Hugo за секунды даже на скромном VPS.

Astro на сопоставимом объёме контента будет заметно медленнее — это плата за Node.js-рантайм, обработку интеграций (@astrojs/react, @astrojs/image и так далее), сборку JS-бандлов для островков и оптимизацию изображений через Sharp. Насколько именно медленнее — зависит от числа интеграций, объёма картинок и настроек кеша сборки, поэтому точные цифры без замера на вашем реальном проекте приводить не стоит: разброс между «голым» Astro-сайтом на Markdown и Astro с десятком React-компонентов и обработкой сотен изображений может быть кратным.

Практический вывод: если у вас чисто контентный сайт (блог, документация, лендинг без сложной интерактивности) и сборка идёт в CI на каждый коммит — с Hugo вы просто не заметите время сборки, с Astro стоит заранее протестировать пайплайн на реальном объёме контента, чтобы не упереться в лимиты CI по времени.

Контент и экосистема: где выигрывает Astro

Hugo силён там, где нужна работа с контентом «из коробки»: таксономии (категории, теги), встроенная многоязычность без плагинов, шорткоды для переиспользуемых блоков в Markdown, генерация RSS и sitemap без настройки. Для чисто контентных сайтов — блог, документация, корпоративный сайт — это экономит часы на самостоятельной реализации того, что в Hugo уже есть.

Astro выигрывает там, где контент нужно комбинировать с интерактивностью и типобезопасностью. Content Collections в Astro позволяют описать схему фронтматтера через Zod и получить проверку типов на этапе сборки — опечатка в дате публикации или пропущенное обязательное поле упадёт с понятной ошибкой, а не тихо сломает вёрстку в проде. Плюс огромная экосистема интеграций (astro add tailwind, astro add react, astro add sitemap) и View Transitions API для плавных переходов между страницами без полного перезагруза.

Если команда уже пишет на React или Vue и хочет переиспользовать компоненты между статическим сайтом и основным приложением — Astro органично встраивается в такой стек. Hugo в этом смысле изолирован: его шаблоны не переиспользуешь нигде, кроме самого Hugo.

Сколько RAM и CPU нужно на сервере

Здесь важно разделить два сценария: сборка сайта и раздача готовых файлов. И Hugo, и Astro на выходе дают статику, которую отдаёт nginx или Caddy без всякого рантайма — эта часть не требует почти ничего, хватит младшего тарифа VPS.

А вот процесс сборки требует разных ресурсов:

Если вы собираете сайт прямо на VPS (git pull → build → reload nginx), для Hugo хватит и самого младшего тарифа с 1 ГБ RAM — процесс сборки почти не создаёт нагрузки. Для Astro с несколькими интеграциями и обработкой изображений через Sharp комфортнее брать конфигурацию от 2 ГБ RAM, особенно если сборка идёт параллельно с другими процессами на том же сервере. Разбор нагрузки по обоим генераторам отдельно — в статьях сколько RAM нужно для Hugo и сколько RAM нужно для Astro.

Более надёжный вариант для обоих случаев — не собирать сайт на проде вообще, а гонять сборку в GitHub Actions или GitLab CI и на VPS только заливать готовую папку public/ или dist/ — тогда требования к серверу минимальны независимо от выбора генератора.

Деплой на VPS: пайплайны и конфиги

И Hugo, и Astro в итоге дают статические файлы, поэтому продакшен-часть у обоих одинаковая — nginx как веб-сервер, Let's Encrypt для SSL, при желании Caddy для более простой конфигурации с автообновлением сертификатов.

Базовый конфиг nginx для раздачи статики (подходит для обоих генераторов, меняется только путь к папке сборки):

server {
    listen 443 ssl http2;
    server_name example.com;

    root /var/www/example.com/public;   # для Hugo: public/, для Astro: dist/
    index index.html;

    location / {
        try_files $uri $uri/ $uri.html =404;
    }

    location ~* \.(css|js|woff2|jpg|png|webp|avif)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
    }

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

Типовой деплой-скрипт для Hugo простой, потому что зависимость всего одна:

git pull
hugo --minify
rsync -a --delete public/ /var/www/example.com/public/
systemctl reload nginx

Для Astro шаг сборки требует Node.js на машине, где идёт astro build (не обязательно на самом продакшен-сервере):

git pull
npm ci
npm run build
rsync -a --delete dist/ /var/www/example.com/public/
systemctl reload nginx

Подробные пошаговые инструкции с нуля — в статьях про установку Hugo на VPS и Astro на VPS: там разобраны и systemd-сервисы для автосборки по вебхуку, и настройка CI/CD с автодеплоем при пуше в main.

Производительность готового сайта и SEO

С точки зрения поисковой оптимизации оба генератора в равных условиях: статический HTML индексируется быстро и полностью, время ответа сервера минимально, потому что nginx отдаёт готовый файл без обращения к базе или бэкенду.

Разница появляется в объёме JavaScript, который получает браузер пользователя. Чистый Hugo-сайт без ручных добавлений JS — это HTML и CSS, ничего больше, и метрики Core Web Vitals (особенно TBT и INP) у него практически недостижимо хороши без дополнительных усилий. Astro-сайт с несколькими интерактивными островками отправит браузеру ровно тот JS, что нужен этим островкам — заметно меньше, чем у классического SPA на чистом React, но всё же больше нуля. Для лендинга с формой обратной связи или каталога с фильтрами это несущественно; для сайта, где важна каждая миллисекунда First Contentful Paint (например, новостной портал с высокой посещаемостью), разница может быть заметна.

В обоих случаях имеет смысл поставить CDN перед сервером — статика хорошо кешируется на edge-нодах, и это снимает нагрузку с исходного VPS при пиках трафика. Как это настроить — в статье про CDN для сайта, а общие приёмы ускорения — в материале как ускорить загрузку сайта на VPS.

Когда выбирать Hugo, а когда Astro: практические сценарии

Сведём в таблицу, чтобы не растягивать на абстрактные рассуждения:

Отдельно стоит сказать про миграцию: переход с Hugo на Astro (или обратно) — это не смена одной строчки конфига, а по сути переписывание шаблонов и, если использовались шорткоды, ручной перенос логики в компоненты. Если сайт уже работает и стабильно собирается — смена генератора ради самой смены редко окупается. Меняйте инструмент, когда упираетесь в конкретное ограничение текущего: не хватает интерактивности в Hugo или сборка Astro стала неприемлемо долгой на вашем объёме контента.

Частые вопросы