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

Я вирішив перебудувати все з нуля. Новий стек — це Astro та Sanity. Після певного часу використання ось що саме спрацювало, що ні, і як це виглядає на фоні інструментів, якими я користувався раніше.

Чому Astro для портфоліо?

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

Маршрутизація базується на файлах, тому створення нової сторінки таке ж просте, як перенесення файлу в папку. Компоненти використовують синтаксис, який здасться знайомим, якщо ви працювали з React, Vue або Svelte. Мені не потрібно освоювати нову парадигму щоразу, коли я хочу додати кейс проєкту.

З іншого боку, я б не використовував Astro для створення складного вебдодатка. Якщо ви налаштовуєте автентифікацію, керуєте глобальним станом або працюєте з даними в реальному часі, ви будете боротися з фреймворком. Проте для маркетингових сайтів, блогів та портфоліо він не заважає. Сторінки здаються швидкими, тому що вони справді швидкі. Немає затримок на гідратацію (hydration overhead) у очікуванні рендерингу заголовка чи абзацу.

Перехід з 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-властивості (custom properties) під час збірки, тому мої таблиці стилів посилаються на змінні на кшталт --color-surface-default замість жорстко прописаних hex-кодів.

Ось чому це важливо на практиці. Якщо я зрозумію, що мій фірмовий червоний занадто агресивний на екранах мобільних пристроїв, я змінюю одне значення в JSON-файлі. Бібліотека у Figma оновлюється. CSS оновлюється. Кожен екземпляр на сайті оновлюється. Мені не потрібно робити grep