Hono + Cloudflare Pages で挑む最速ポートフォリオ構築：なぜNext.jsではないのか

はじめに：「ポートフォリオを作るなら Next.js」という空気

エンジニアのポートフォリオサイトといえば「Next.js + Vercel」が定番だ。
Reactの学習コストを払ってまで、この構成がポートフォリオに必要かを、私は疑った。

クラウドインフラエンジニアである私がポートフォリオサイトに求めたのは、速さ・軽さ・シンプルな運用だ。記事を増やすたびにビルドを待ち、Reactコンポーネントの設計に頭を使う必要はない。

その問いに答えてくれたのが Hono + Cloudflare Pages だった。

Section 1: 技術比較 ── Next.js vs Hono の実態

バンドルサイズの差

Next.jsはReact runtime・ルーターのチャンク・ハイドレーション用コードが必ず乗る。静的コンテンツを表示するだけでも「Reactが動く」ためのオーバーヘッドが発生する。

HonoはサーバーサイドでそのままHTMLを生成して返す。クライアント側にJSランタイムは不要で、CDNのエッジノードで直接処理される。

コールドスタートの問題

Vercel Functions（Node.js runtime）はコールドスタートが存在し、初回リクエストで数百ms〜1秒超の遅延が発生することがある。
Cloudflare WorkersはコールドスタートがV8 Isolateアーキテクチャによりほぼゼロだ。全世界300+のPoP（接続点）でエッジ実行される。

# Cloudflare Workers の起動モデル
V8 Isolate（同プロセス内の独立した実行コンテキスト）
→ JIT済みコードを再利用
→ コールドスタートなし
→ リクエストレイテンシ = ネットワーク往復のみ

ポイント： Node.js/Deno/Bun はOSプロセスを起動するモデル。WorkersはV8 Isolateをプール管理しており、起動コストが桁違いに小さい。これがポートフォリオのような「たまにアクセスされるサイト」で特に有効に働く。

Section 2: Hono の設計哲学とポートフォリオへの適合性

Hono とは何か

Hono（炎）は、Cloudflare Workers・Deno・Bun・Node.jsなど複数のランタイムで動作する超軽量 Web フレームワークだ。

import { Hono } from 'hono'

const app = new Hono()

app.get('/', (c) => {
  return c.html(`<h1>Hello from the Edge</h1>`)
})

export default app

Expressに似たルーティングAPIを持ちながら、依存関係がほぼゼロ。ビルド結果もWorkers環境に最適化されたシングルファイルになる。

テンプレートエンジンとしての活用

このポートフォリオでは、HonoのJSXサポートを使ってHTMLをTypeScript関数として記述している。ReactのVirtual DOMとは異なり、サーバーサイドで直接HTML文字列に変換されるため、クライアントJS一切なしでリッチなマークアップが書ける。

// src/routes/about.ts
import { Layout } from '../components/layout'

export const AboutPage = () => {
  return Layout({
    title: 'About | Tono',
    children: `
      <h1>About Me</h1>
      <p>クラウドエンジニアのプロフィール</p>
    `
  })
}

型補完が効き、テンプレートリテラルでHTMLを書くシンプルさがある。Reactのstate管理・effect・hooksの複雑さは一切不要だ。

Section 3: Cloudflare Pages のデプロイ体験

デプロイフロー

git push → Vite build → wrangler deploy → 世界300+ PoP へ反映

# ビルド結果
vite v6.4.1 building SSR bundle for production...
✓ 42 modules transformed.
dist/_worker.js  262.71 kB   ← 全ページ含めてこのサイズ
✓ built in 722ms

プッシュからグローバル反映まで約30秒。Vercelも高速だが、Cloudflare PagesはWorkersの実行モデルそのものが異なるため、レスポンスの均一性が高い。

コスト構造

ポートフォリオ用途ではCloudflare Pagesの無料枠が明らかに余裕がある。

Section 4: Next.js が適切な場面とそうでない場面

Next.jsを否定するつもりはない。適材適所だ。

今回のポートフォリオにはインタラクティブなReact Componentが不要だった。必要なのは「情報を速く・正確に届けること」だけ。その要件に対して、Next.jsはオーバースペックだと判断した。

Conclusion: 「最速の配信」はツールではなく設計から来る

フレームワークは目的ではなく手段。要件から逆算した選択が、最終的なパフォーマンスを決める。

Hono + Cloudflare Pagesという選択は、「Next.jsが嫌いだから」ではない。ポートフォリオに求める要件（速度・軽量・シンプルな運用）を満たす最小のスタックがこれだったという結論だ。

クラウドインフラの仕事でも同じ思考が使える。「とりあえずEC2」ではなく、トラフィック特性・コスト・運用負荷を比較してLambdaにする・S3+CloudFrontにする——という判断が価値を生む。技術選定は常に、要件の分析から始まる。