For a working designer, a portfolio site sits in an awkward middle ground. It needs to look sharp, load instantly, and s

現役のデザイナーにとって、ポートフォリオサイトは扱いにくい中間領域に位置しています。見た目が洗練されており、瞬時に読み込まれ、かつ請求可能な稼働時間を削ることなく最新の状態を保つ必要があります。以前はWebflowを使っていました。これは、ドラッグ＆ドロップのビルダーとプロフェッショナルなアウトプットの間のギャップを、他の多くのツールよりもうまく埋めてくれるものでした。しかし、年額300ポンドの更新通知が届いたとき、厳しい問いを突きつけられました。「自分は価値に対して対価を払っているのか、それとも単に利便性に払っているだけなのか？」

ゼロからの再構築を決めました。新しいスタックはAstroとSanityです。しばらく運用してみた結果、何がうまくいき、何がうまくいかなかったのか、そして以前使っていたツールと比べてどうなのかを詳しくお伝えします。

なぜポートフォリオにAstroなのか？

ほとんどのモダンなウェブフレームワークは、まずJavaScriptを送り込み、必要かどうかは後回しにします。Astroはその前提を覆します。ビルド時にプレーンな静的HTMLを生成し、特定のコンポーネントが実際に必要とする場合にのみ、JavaScriptをブラウザに送信します。これを「アイランド・アーキテクチャ（islands architecture）」と呼びますが、実用的な結果はもっとシンプルです。私のポートフォリオのページは、重さがほとんどゼロなのです。

ルーティングはファイルベースなので、新しいページを作成するのは、フォルダにファイルをドロップするのと同じくらい簡単です。コンポーネントは、React、Vue、Svelteに触れたことがあれば馴染みのある構文を使用しています。プロジェクトのケーススタディを追加したいときに、毎回新しいパラダイムを模索する必要はありません。

とは言え、複雑なウェブアプリケーションを構築するためにAstroを使うことはしません。認証を組み込んだり、グローバルな状態を管理したり、リアルタイムデータを扱ったりする場合、フレームワークと格闘することになるでしょう。しかし、マーケティングサイト、ブログ、ポートフォリオに関しては、邪魔をすることなく機能してくれます。ページが速く感じるのは、実際に速いからです。見出しや段落のレンダリングを待つための「ハイドレーション（hydration）」のオーバーヘッドもありません。

WordPressからSanityへの移行

今回の再構築の前は、常にWordPressとAdvanced Custom Fields（ACF）が選択肢でした。ACFはWordPressに強力な機能を与えてくれますが、それでも結局は「誰かが作った家」の設定をしているに過ぎません。Sanityはその逆です。コードでコンテンツモデルの形を正確に定義するスキーマを記述すると、Sanityがその決定に基づいて編集インターフェースを構築してくれます。

私はそのコントロール機能を利用して、再利用可能なブロックによるシンプルなページビルダーを構築しました。ヒーローセクションを一度定義し、お客様の声のカルーセルを一度定義し、カードグリッドを一度定義しました。これにより、新しいコードを書いたりページテンプレートをいじったりすることなく、それらのブロックを好きな順序で積み重ねるだけで、新しいページを組み立てることができます。

マインドセットの違いが重要です。WordPressを使っているときは、ブログになりたがっているツールと格闘しているような感覚に陥ることがよくありました。Sanityを使っているときは、ソフトウェアを構築している感覚があります。コンテンツは、ショートコードが混ざったスタイリング済みのHTMLではなく、クリーンな構造化データになります。プロジェクトの説明はポータブルなオブジェクトとして存在するため、必要であればモバイルアプリやニュースレターに流し込むことも可能です。

クリーンなデプロイ・ワークフロー

以前のWordPressのワークフローは、FTPアップロード、ステージング用のサブドメイン、そして常に最悪なタイミングで壊れるプラグインのアップデートが入り混じった、混沌としたものでした。単なるタイポの修正を公開するためだけに、頭の中でチェックリストを回さなければなりませんでした。

新しいワークフローはシンプルです：

• ローカルで変更を行い、即座に確認する。
• コードが整ったらGitHubにコミットする。
• Vercelがプッシュを検知し、サイトを自動的にデプロイする。

FTPクライアントも、同期させるためのステージング用データベースも必要ありません。リポジトリが「信頼できる唯一の情報源（source of truth）」となります。

コンテンツも同様です。Sanity内で投稿を公開または更新すると、WebhookがVercelにサイトの再ビルドを指示します。静的ページは新しいコンテンツで再生成され、サーバーに触れることなくCDNが更新されます。手動でのコピーやエクスポート、あるいは「プラグインのデータベース移行が本当に成功したことを祈る」といった作業をすることなく、すべてが同期された状態に保たれます。

トークンでデザインとコードを紐付ける

今回の再構築における、目立たないけれど大きな進歩の一つは、適切なトークンシステムを構築したことでした。サイト内のすべての色、タイポグラフィのスケール、スペーシングの値を管理する単一のJSONファイルを保持しています。そのファイルが「ボス」なのです。

Token Studioを使用して、それらの値を直接Figmaに反映させています。デザインファイルに surface-default とあれば、それはコードが使用しているのと全く同じ数値を指しています。小さなスクリプトがビルド時にJSONをCSSカスタムプロパティに変換するため、スタイルシートはハードコードされた16進数コードではなく、--color-surface-default のような変数を参照します。

これが実務においてなぜ重要なのかを説明します。もしブランドの赤色がモバイル画面では少し強すぎると気づいたら、JSONファイルの値を一つ変えるだけです。Figmaライブラリが更新され、CSSが更新され、サイト全体のすべての箇所が更新されます。grepで検索する必要もありません。