Для практикующего дизайнера сайт-портфолио находится в неудобном промежуточном положении. Он должен выглядеть стильно, загружаться мгновенно и оставаться актуальным, не отнимая при этом оплачиваемые часы работы. Мой старый сетап работал на Webflow, который справлялся с задачей поиска баланса между drag-and-drop конструкторами и профессиональным результатом лучше большинства инструментов. Но когда пришло уведомление о продлении с ежегодным счетом в £300, мне пришлось задать себе жесткий вопрос: плачу ли я за ценность или просто за удобство?

Я решил пересобрать всё с нуля. Новый стек — это Astro и Sanity. Пожив с ним некоторое время, я готов рассказать, что сработало, что нет и как он соотносится с инструментами, которые я использовал раньше.

Почему Astro подходит для портфолио?

Большинство современных веб-фреймворков сначала загружают JavaScript, а уже потом разбираются с остальным. Astro меняет это правило. Он генерирует обычный статический HTML на этапе сборки и отправляет JavaScript в браузер только тогда, когда это действительно нужно конкретному компоненту. Это называют архитектурой островов (islands architecture), но практический результат проще: мои страницы портфолио весят почти ничего.

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

Тем не менее, я бы не стал использовать Astro для создания сложных веб-приложений. Если вы настраиваете аутентификацию, управляете глобальным состоянием или работаете с данными в реальном времени, вы будете бороться с фреймворком. Но для маркетинговых сайтов, блогов и портфолио он не мешает. Страницы ощущаются быстрыми, потому что они и есть быстрые. Нет никаких издержек на гидратацию в ожидании рендеринга заголовка или абзаца.

Переход с WordPress на Sanity

До этой пересборки моим основным инструментом всегда был WordPress с Advanced Custom Fields. ACF наделяет WordPress суперспособностями, но вы всё равно настраиваете «чужой дом». Sanity работает иначе. Вы пишете схему в коде, которая точно определяет, как выглядит ваша модель контента, а Sanity выстраивает интерфейс редактирования вокруг ваших решений.

Я использовал этот контроль, чтобы создать простой конструктор страниц из переиспользуемых блоков. Я один раз определил hero-секцию. Один раз — карусель отзывов. Один раз — сетку карточек. Теперь я могу собирать новые страницы, просто складывая эти блоки в любом порядке, не написав ни строчки нового кода и не трогая шаблоны страниц.

Разница в подходе имеет значение. С WordPress я часто чувствовал, что борюсь с инструментом, который хочет быть блогом. С Sanity я чувствую, что создаю программное обеспечение. Контент превращается в чистые структурированные данные, а не в стилизованный HTML, перемешанный с шорткодами. Описания моих проектов становятся переносимыми объектами, которые я мог бы отправить в мобильное приложение или рассылку, если бы захотел.

Чистый процесс развертывания

Мой старый рабочий процесс в WordPress представлял собой хаос из загрузок по FTP, стейджинг-поддоменов и обновлений плагинов, которые всегда ломались в самый неподходящий момент. У меня был целый ментальный чек-лист только для того, чтобы исправить опечатку.

Новый процесс короток:

  • Я вношу изменения локально и сразу вижу результат.
  • Я делаю коммит в GitHub, когда код готов.
  • Vercel подхватывает пуш и автоматически развертывает сайт.

Никаких FTP-клиентов. Никаких баз данных стейджинга, которые нужно синхронизировать. Репозиторий — это единственный источник истины.

С контентом всё работает так же. Когда я публикую или обновляю пост в Sanity, вебхук сообщает Vercel, что сайт нужно пересобрать. Статические страницы генерируются заново с новым контентом, а CDN обновляется без моего участия. Всё остается синхронизированным без ручного копирования, экспорта или молитв о том, что миграция базы данных плагина действительно прошла успешно.

Связывание дизайна и кода с помощью токенов

Одним из тихих прорывов в этой пересборке стало создание правильной системы токенов. Я веду один JSON-файл, который управляет каждым цветом, шкалой шрифтов и значением отступов на сайте. Этот файл — главный.

Я использую Token Studio, чтобы переносить эти же значения прямиком в Figma. Когда в моем дизайн-файле указано surface-default, он ссылается на то же самое число, которое использует код. Небольшой скрипт преобразует JSON в пользовательские свойства CSS во время сборки, поэтому мои таблицы стилей ссылаются на переменные вроде --color-surface-default вместо жестко прописанных hex-кодов.

Вот почему это важно на практике. Если я пойму, что мой фирменный красный слишком агрессивен на экранах мобильных устройств, я изменю одно значение в JSON-файле. Библиотека в Figma обновится. CSS обновится. Все вхождения на сайте обновятся. Мне не нужно использовать grep