By Mekann
速度は情報の価値を担保する ─ Hugo から Astro へ移行した理由
“高速ビルド”に魅せられた Hugo ユーザーが、“高速表示”という次元で優れる Astro へ移行した経緯を、計測指標と設計思想の観点から考察する。
序論 ─ ビルド速度と表示速度の非対称性
Web コンテンツの価値は、読者が最小の待機時間で内容に到達できるかという一点に大きく依存する。
私は長らく Hugo を用い、Go 言語がもたらす 高速ビルド の恩恵を享受していた。
しかし近年、Astro の掲げる “Ship less JavaScript” という理念に触れ、
ビルド時間ではなく 実際の描画・操作までの時間 ― すなわちユーザ体験の核心にある速度 ― に視点を転換した。
“速さ”の二軸比較
| 指標 | Hugo | Astro |
|---|---|---|
| ビルド時間 | 極めて短い（Go 製） | 短い（Vite ベース） |
| First Contentful Paint (FCP) | 静的 HTML により速い | 通常同等、0-JS 構成時はさらに速い |
| Largest Contentful Paint (LCP) | JS を追加すると悪化しやすい | Island Hydration によりほぼ維持 |
| JS ペイロード | 任意で追加、重量化しやすい | デフォルト 0 kB、島ごとに遅延ロード |
| 保守性 | テンプレート中心 | コンポーネント中心、再利用容易 |
Hugo が提供するのは 開発者の生産性を高める速さ、
Astro が強みとするのは 利用者へ届く速さ である。
Astro における速度最適化の設計原理
-
0-JavaScript 配信
生成物は静的 HTML/CSS のみ。
これにより TTFB とレンダリングパスの短縮が保証される。 -
Island Hydration
ページ全体を SPA 化せず、必要最小限のコンポーネントだけをクライアント側で活性化。
- LCP 後に JS を遅延読み込み
- インタラクティブ領域の範囲を局所化
結果として Core Web Vitals (LCP, CLS, INP) が高得点を維持する。
-
バンドルの自動剪定
Vite のツリーシェイクと Astro のプリレンダリングにより、
未使用コードはビルド成果物に残らない。
ネットワーク負荷を定量的に最小化できる。
結語 ─ 速度はコンテンツの信頼性を高める
Hugo が提供した「ビルド爆速」は開発効率を向上させた。
しかし Astro が示した「表示爆速」は、読者が知識へ到達するまでの摩擦を極限まで削ぎ落とす。
Web における情報伝達は、コンテンツと同様に回路（delivery）そのものが品質を規定する。
私はその原点を再認識し、Astro を主要フレームワークとして採用するに至った。
今後はパフォーマンス計測と最適化の実践を継続し、
得られた知見を共有することで、速度を軸にしたウェブ体験の向上に貢献したい。