Почему этот сайт собран на Astro

Сайт работает на Astro 6. Решение заняло две недели обсуждений, и каждый альтернативный вариант я честно проговорил. Этот текст — записанная версия того разговора. Для тех, кому предстоит тот же выбор.

Реальное сравнение шло между тремя категориями

Списки «лучших фреймворков» бесполезны, потому что фреймворки не альтернативы друг другу — каждый отвечает на свой вопрос. Для нас категорий было три:

Контент-первые статические генераторы — Astro, Hugo, Eleventy, современный Jekyll.
React-фреймворки SaaS-формы — Next.js, Remix, TanStack Start.
CMS-платформы — WordPress, Webflow, Framer.

У каждой категории есть реальные сильные стороны. Чтобы не выбрать неправильную, нужно сначала ответить — что мы вообще строим.

Что за сайт у нас на самом деле

Qaynaq.com — это ни воронка лидов, ни работающее приложение. Это:

Редакционный — суть в кейсах и текстах журнала.
Статичный — контент меняется раз-два в месяц.
SEO-чувствительный — три языка, hreflang, JSON-LD, canonical.
Прозрачный — читаемый код, проверяемый, без дорогих рантайм-зависимостей.
На бюджете производительности — JS на главной — до 80 КБ, LCP — до 2.0с.

Когда этот список написан, Next.js и WordPress оба становятся избыточными. Webflow и Framer — наоборот, недостаточны, потому что мы хотим контроль над MDX, кастомным рендером и трёхъязычной структурой URL.

Почему не Next.js

Next.js — отличный фреймворк. Мы используем его в других проектах каждую неделю. Но не для этого сайта:

Серверный рантайм не нужен. Форма аудита и любые другие действия живут в edge-функциях отдельно. Держать открытым Node-рантайм для всего сайта — это накладные расходы без отдачи.
Бюджет React-компонентов слишком высокий. Острова Astro позволяют закрыть React (Svelte, Solid) только мелкими интерактивными фрагментами. Остальные части страницы отдают ноль JS.
Сила экосистемы здесь становится слабостью. У Next.js тысячи шаблонов. Большинство — обобщённые SaaS-лендинги. Я не хочу стартовать с «и так сойдёт».
Привязка к вендору. Next.js всё больше завязан на функции Vercel. Сайт должен оставаться переносимым.

Конкретные числа (показательные, не бенчмарк): большинство страниц этого сайта открываются с 15–25 КБ JS. Тот же сайт на Next.js App Router с RSC-payload, гидратацией и бойлерплейтом — это минимум 80–120 КБ.

Почему не WordPress

WordPress — правильный ответ для очень многих проектов. Просто не для этого.

Не помещается в бюджет производительности. Стандартная тема плюс плагины ставят LCP в диапазон 3–5 секунд. Работа по их вытаскиванию превышает работу по сборке Astro с нуля.
Большая поверхность для атак. Обновления плагинов, база, админка. У статичного сайта ничего из этого нет.
Версионирование контента — не Git. Контент в базе. Наши кейсы и тексты — MDX-файлы, проходят ревью, ветки, итерации.
Опыт письма. Gutenberg вырос, но автору-разработчику в терминале писать в MDX быстрее.

WordPress — это не «CMS, которой пользуются», это система с обязательствами по владению. Нам CMS не нужен, потому что автор один и пишет MDX.

Почему не Webflow / Framer

Оба — хорошие инструменты, особенно для быстрых дизайн-итераций. Но:

Код вроде ваш, но он сгенерирован. Экспортируешь — получаешь HTML, обёрнутый в десятки служебных div.
Привязка к хостингу. Сайт Webflow живёт на Webflow (экспорт есть, но непрактичен).
Процесс письма. Длинные журнальные тексты в Webflow CMS не сравнимы с MDX под версионным контролем.
Анти-шаблонный принцип. Культура Webflow — шаблонная. Наш стандарт (design-quality.md) требует обратного.

Для проектов клиентов мы переоцениваем стек под каждую команду — иногда Webflow остаётся правильным ответом, потому что сайт после сдачи будет вести небольшая нетехническая команда.

Инструмент против позиции

Webflow и Framer дают маленьким командам отличный опыт. Но инструмент — это одно, а позиция — другое. Сайт на Webflow обычно говорит на визуальном языке вебфлоу-шаблонов — не из-за самого инструмента, а из-за культуры использования вокруг него. Писать статический HTML и CSS в Astro не делает нас автоматически «более творческими». Просто старт без дефолтного вида. Всё собирается с чистой поверхности.

Что Astro нам дал по факту

Практические выигрыши:

Ноль-JS-страницы по умолчанию. Гидрируются только компоненты, помеченные как острова.
MDX как первоклассный гражданин — проверяется схемой коллекции (src/content.config.ts) на этапе сборки.
Content collections + Zod — frontmatter типизирован. Опечатка в topic ломает сборку.
Нативная маршрутизация i18n — /az/, /en/, /ru/ поддерживаются из коробки.
Скорость сборки — этот сайт собирается за 3–7 секунд. (Тоже показательно, масштабируется с проектом.)
Острова, агностичные к фреймворку — React и Solid компоненты могут сосуществовать.
Низкий бойлерплейт — добавить страницу — это создать .astro или .mdx. Маршрутизация — по файловой системе.

Для редакционной поверхности каждый из этих пунктов снимает трение. Чтобы написать следующий журнальный текст, не нужен особый процесс — создал файл, написал frontmatter, запушил.

Какие компромиссы мы приняли

Astro решает не всё. Честный список:

Интерактивность из коробки тонкая. Если вы строите сложное приложение — Astro не та история. Острова помогают, но полный SPA-опыт хочет Next, Remix или TanStack Start.
Экосистема плагинов меньше, чем у Next.js. Для нас это плюс (анти-шаблон), для других — реальная цена.
Серверное состояние молодое. Astro Actions и DB-интеграции только формируются. Бэкенд аудитного пайплайна живёт отдельной edge-функцией, не внутри Astro.
Реальное время — не нативно. Чат, живые обновления, сложное состояние формы — каждое требует своей библиотеки.

Три вопроса перед выбором стека

Когда меня спрашивают совета, я прогоняю эти три:

Какой процент страниц у вас по-настоящему интерактивен? Меньше 20% — статические генераторы. Больше 50% — React-фреймворки.
Откуда берётся контент? Один технический автор? MDX. Десяток нетехнических редакторов? CMS (Sanity, Strapi, WordPress).
Насколько жёсткий бюджет производительности? Главная под 80 КБ? Static-first обязателен. 200 КБ допустимо? Открываются другие варианты.

Эти три ответа фиксируют выбор стека на 80%. Остальное — опыт команды и предпочтения по хостингу.

Когда Astro — неправильный ответ

В порядке честности — три случая, в которых я не возьму Astro:

Реалтайм-дашборды. Живые данные, WebSocket, сложное состояние фильтров. Next.js или Remix лучше.
SaaS с авторизацией. Логин, ролевой UI, сложные формы, параллельные потоки данных. Острова Astro справятся, но трение накапливается.
Команда вокруг React-экспертизы. Беглость в инструменте важнее. Учить React-команду Astro — короткая стоимость; если долгосрочная выгода реальна — окей. Если нет — оставайтесь там, где команда быстрая.

Это важно в консультативной работе. Сказать партнёру «этот сайт на Astro, ваш тоже должен быть» — это плохой совет. У его проекта может быть другой ответ.

Что выбор стека выдаёт

Технический выбор — никогда не только технический. Каждое решение отвечает на вопрос зачем этот сайт.

Студия на Next.js говорит, что сайт — воронка конверсии. Студия на WordPress — несколько нетехнических редакторов обновляют контент. Студия на Webflow — дизайнеру нужно править напрямую.

Студия на Astro — в нашем случае Qaynaq — говорит, что сайт это редакционное издание, что код версионируется, что автор технический и что производительность — требование, а не пожелание.

Дайте стеку отражать вашу позицию. Это не мелочь.

Вопросы и обсуждения: salam@qaynaq.com.