Я не хотел думать о своём маркетинговом сайте.
Три месяца назад я смотрел на пустой репозиторий и решал, на чём строить лендинг и блог. Мне нужно было что-то, что просто работает, не мешает и позволяет сосредоточиться на реальных функциях продукта.
Я перебрал много вариантов. Большинство из них были избыточны для того, что мне действительно нужно. Это история о том, как я в итоге остановился на Astro, и почему это был самый тихий, наименее стрессовый технический выбор.
“Лучший фреймворк — тот, о котором вы не думаете.”
Матрица решений: Выбор между Strapi, кастомным кодом и Astro
У меня было три реальных варианта. Ни один из них не был идеальным, но каждый решал разные части задачи.
Претенденты:
- Настроить Strapi headless CMS
- Написать всё с нуля на чистом коде
- Перейти на Astro
Критерии: Что важно для основателей-одиночек
Я не оптимизировал баллы в бенчмарках или модные функции. Я оптимизировал ровно четыре вещи:
- Я должен забыть о существовании этого стека. Он никогда не должен требовать моего внимания.
- Написание поста в блоге должно быть таким же простым, как сохранение Markdown-файла.
- Изменение текста на лендинге должно занимать меньше 60 секунд.
- Нужно обрабатывать i18n, не доводя меня до желания швырнуть ноутбук.
Всё. Это весь список. Другие критерии не имели значения.
Давайте дадим каждому варианту честный шанс.
Вариант 1: Strapi Headless CMS — Отлично для команд, избыточно для одного
Сначала это казалось разумным выбором. Все говорят, что headless CMS — правильный путь для маркетинговых сайтов. Отделение контента от кода, удобный админ-интерфейс, нетехнические люди могут редактировать контент.
Я его настроил. Ушёл день. Я заставил работать модели контента. Я получил данные через API. И тогда я понял:
Я единственный человек, который когда-либо будет редактировать этот контент.
Нет маркетинговой команды. Нет копирайтера. Есть только я. И для основателя-одиночки админ-интерфейс на самом деле медленнее, чем просто открыть текстовый файл.
Каждый раз, когда я хотел изменить строку текста, мне нужно было:
- Войти в Strapi
- Подождать загрузки дашборда
- Найти нужную запись контента
- Внести изменение
- Опубликовать
- Пересобрать фронтенд
А потом ещё задеплоить. Для одного человека это добавляло накладные расходы, а не убирало их.
Плюс i18n в Strapi? Работает, но тяжело. Нужно настраивать каждое поле для каждого языка, управлять переводами через интерфейс и аккуратно обрабатывать ответы API. Это было как использовать кувалду, чтобы повесить картину.
Вариант 2: Писать всё с нуля — Просто до определённого момента
Это был заманчивый вариант. В конце концов, я же написал с нуля весь свой бэкенд. Почему не сделать то же самое для фронтенда? Просто HTML, немного CSS, может немного ванильного JS. Без фреймворков, без зависимостей.
Я действительно так собрал первую версию. Это было быстро. Это было просто. А потом мне нужно было добавить второй пост в блог.
А потом мне понадобился i18n.
Внезапно я писал всю скучную связующую логику, которую решают фреймворки. Генерация индексных страниц. Создание RSS-лент. Обработка черновиков. Управление языковыми версиями каждой страницы.
Это работало. Но я тратил время на написание CMS-функций вместо построения продукта. Я мог бы продолжать, но это был бы постоянный налог на поддержку. Каждая новая функция на маркетинговом сайте означала бы написание ещё одного шаблона.
Вариант 3: Astro — Фреймворк, который исчезает
Я долго игнорировал Astro. Думал, что это просто ещё один фронтенд-фреймворк, который заменят через 18 месяцев.
Потом я его попробовал.
npm create astro@latest запустился. Через 10 секунд у меня был рабочий сайт.
Я внёс изменение. Браузер обновился, пока я переключался alt-tab’ом.
Я добавил пост в блог. Просто Markdown-файл в src/content/blog. Без конфигурации. Без кода. Оно просто работало.
Я его задеплоил. Сборка заняла 7 секунд. Не 7 минут. 7 секунд.
А потом я забыл о нём. На месяц. Я его не трогал. Не обновлял зависимости. Вообще о нём не думал. И когда вернулся, оно всё ещё работало точно так же.
Вот это и есть фишка. Вот это продающая точка. Никто об этом не говорит.
“Лучшая инфраструктура невидима. Лучший инструмент — тот, о котором забываешь.”
Глубокий взгляд на реализацию в Astro: ноль JS по умолчанию
Самая большая победа была не в производительности. Она была в невидимости.
Вот как выглядит мой стек маркетингового сайта сегодня:
Ноль JavaScript на клиенте по умолчанию
Мой лендинг отправляет ноль JavaScript на клиент. Ноль.
Ни гидратации. Ни рантайма. Ни шаблона фреймворка. Только HTML и CSS. Загружается за 300ms на 3G. Никто не замечает. Но все замечают, как быстро это ощущается.
Когда мне действительно нужна интерактивность? Когда нужен калькулятор цен или форма демо? Я просто добавляю остров:
---
import PricingCalculator from './PricingCalculator.tsx'
---
<div class="pricing-section">
<PricingCalculator client:load />
</div>Всё.
Остальная страница — статический HTML. Только калькулятор загружает React. Только когда нужно. Мне не нужно об этом думать. Оно просто делает правильную вещь.
Контент-коллекции — это киллер-фича
Это функция, которая меня убедила.
Когда я хочу написать пост в блог, я создаю файл: src/content/blog/why-im-using-astro.md
Добавляю frontmatter:
---
title: Why I'm Using Astro For Landings And Blog
publishedAt: 2026-04-09
---И пишу. Всё.
Без CMS. Без базы данных. Без GraphQL-запросов. Без API-вызовов. Просто Markdown-файл. И Astro автоматически:
- Валидирует все поля frontmatter
- Генерирует определения типов
- Создаёт индексную страницу
- Создаёт RSS-ленту
- Обрабатывает черновики
Мне не нужно писать ни строчки кода для всего этого. Оно просто работает.
“Для основателей-одиночек лучшая CMS — текстовый редактор и git.”
i18n оказался на удивление простым
Это было удивлением. Я ожидал, что i18n будет кошмаром. Но не был.
Интеграция i18n в Astro проста. Вы создаёте папки для каждого языка:
src/
pages/
en/
index.astro
about.astro
es/
index.astro
about.astroДобавляете немного конфига:
// astro.config.mjs
export default defineConfig({
i18n: {
defaultLocale: 'en',
locales: ['en', 'es', 'de'],
},
})И в основном всё. Оно автоматически обрабатывает переключение языков, относительные пути и SEO-теги. Без сторонних плагинов. Без странной конфигурации. Просто работает.
Для общего текста я сделал простой объект переводов, который импортирую где нужно. Без модных библиотек. Всего 50 строк кода.
Что я думал, что будет сложным, но оказалось простым
Деплой. Я просто пушу в GitHub. Cloudflare Pages собирает за 7 секунд. Готово. Без конфигурации. Без edge functions. Без холодных стартов. Cloudflare обрабатывает CDN, SSL, всё. Я никогда об этом не думаю.
Оптимизация изображений. npm install @astrojs/image. Готово. Оно просто работает. Генерирует современные форматы. Обрабатывает адаптивные изображения. Без конфигурации.
Интеграция Tailwind. npx astro add tailwind. Готово. Работает идеально. Без PostCSS конфига. Без проблем с purging.
Что я думал, что будет простым, но стало 3-дневным кошмаром
Поиск. Нет хорошего встроенного поиска для Astro. Каждый сторонний плагин поиска — либо заброшенный проект, либо стоит $50/месяц. В итоге я написал крошечный скрипт на 100 строк, который генерирует поисковый индекс при сборке. Работает нормально. Но это должно было быть встроено.
Пагинация. Встроенная пагинация странно привередлива. Если хотите что-то, кроме “10 постов на страницу”, приходится с ней бороться. Я потратил два дня, чтобы заставить её работать так, как хотел.
Цена входа: Компромиссы Astro для основателей-одиночек
У каждого выбора есть компромиссы. Вот что я плачу за использование Astro:
- Оно хорошо только для статического контента. Если попробуете построить полностью динамическое приложение на Astro, у вас будет плохое время. Это не для этого.
- Меньше экосистемы. Шаблонов и примеров гораздо больше для других фреймворков.
- Нет ограничений. Astro позволит вам делать глупости. Оно позволит добавить 17 разных фреймворков на одну страницу, если хотите. Оно не остановит вас.
- Иногда случаются breaking changes. Каждый мажорный релиз ломает что-то мелкое. Обычно мелкое. Обычно хорошо задокументированное. Но они есть.
Но знаете, какой была альтернатива? Либо поддерживать целый экземпляр CMS, который мне не нужен, либо писать всю скучную связующую логику самому.
Математика сходится.
Вердикт: Astro для маркетинговых сайтов основателей-одиночек
Для меня, прямо сейчас, это идеальный инструмент для этой задачи.
Я могу написать и опубликовать пост в блоге за 5 минут.
Я могу изменить любой текст на лендинге за 30 секунд.
Я могу добавить новый язык за полдня.
Мне не приходилось трогать основной код сайта уже 6 недель. Оно просто работает. Собирается. Деплоится. Никогда не ломается.
Это то, что никто не говорит о выборе инструментов. Лучший инструмент — не тот, у которого больше функций. Он тот, о котором забываешь.
Лучшая инфраструктура невидима. Лучший фреймворк — тот, о котором не думаешь.
Astro не хочет, чтобы я был частью его сообщества. Оно не хочет, чтобы я твитил о нём. Оно не хочет, чтобы я писал посты о том, какой оно классное. Оно просто хочет делать свою работу и уйти с дороги.
Именно это мне и нужно.
Если вы строите лендинг. Если вы строите блог. Если вы строите маркетинговый контент. Если вы основатель-одиночка, которому нужно что-то, что работает и не мешает.
Не думайте слишком много. Используйте Astro.
Вы поблагодарите меня, когда забудете о нём на 3 месяца.
Часто задаваемые вопросы
Почему стоит выбрать Astro вместо Next.js или Remix для маркетинговых сайтов?
Next.js и Remix — отличные фреймворки для динамических приложений, но они отправляют ненужный JavaScript на клиент для статического контента. Astro по умолчанию отдаёт чистый HTML, что приводит к более быстрой загрузке и нулевым накладным расходам рантайма для контента, которому не нужна интерактивность. Для маркетинговых сайтов и блогов эта разница в производительности напрямую влияет на пользовательский опыт и SEO.
Могу ли я использовать React-компоненты с Astro?
Да! Astro поддерживает частичную гидратацию через архитектуру Islands. Вы можете писать интерактивные компоненты на React, Vue, Svelte или любом другом фреймворке и загружать их только когда нужно. Остальная часть вашей страницы остаётся статическим HTML. Это даёт лучшее из двух миров — статическую производительность с динамическими возможностями там, где требуется.
Насколько сложно перенести существующий сайт на Astro?
Сложность миграции зависит от вашего текущего стека. Для статических сайтов на HTML/CSS можно скопировать существующий код прямо в компоненты Astro. Для React/Vue сайтов можно постепенно мигрировать компоненты, сохраняя существующую функциональность. Документация Astro предоставляет отличные гайды по миграции для большинства популярных фреймворков.
Внешние ссылки
- Официальная документация Astro — Полные руководства и API-справочники
- Контент-коллекции Astro — Официальная документация по управлению контентом
- Руководство по i18n в Astro — Полная инструкция по настройке интернационализации
- Интеграция Cloudflare Pages — Гайд по деплою на Cloudflare