1.「速い」の正体を分解する

速度は3層で決まります。

① サーバー処理速度

② HTML生成速度

③ クライアント描画速度

例えばRPSが高くても、JSが重ければLCPは遅くなります。

逆に静的HTMLでも、TTFBが遅ければSEO評価は下がります。

したがってランキングは単一軸では成立しません。

2. Core Web Vitalsとサーバー指標の技術的関係

TTFB（Time To First Byte）

影響要因：

• サーバー処理時間
• DBクエリ時間
• コールドスタート
• CDN距離

バックエンドフレームワークの設計が直接影響します。

LCP（Largest Contentful Paint）

影響要因：

• HTML生成速度
• 画像最適化
• JSブロッキング
• Hydration量

ここはフロントエンドフレームワークの設計が支配的です。

CLS（Cumulative Layout Shift）

影響要因：

• 動的挿入DOM
• サイズ未指定画像
• 遅延読み込み実装

フレームワークより設計品質の問題です。

3. バックエンド実測パフォーマンス比較

ルーティング処理の差

Gin：

• コンパイル済みコード
  
• ツリー構造ルーター
  
• 分岐コストが低い
  

Fastify：

• 軽量ルーター
  
• ルート登録時に最適化
  

Express：

• ミドルウェアを順に評価
  
• マッチングコストがやや高い
  

Hono：

• Web標準ベース
  
• Edge前提のシンプル設計
  

ここで既に差が出ます。特に高並列時はルーティング効率が影響します。

JSONシリアライズの差

APIではJSON変換がボトルネックになりやすい。

Gin：

• 標準ライブラリ最適化
  
  
• コンパイル済み高速処理
  

Fastify：

• スキーマ事前定義により高速化
  

Express：

• 汎用JSON処理
  

FastifyがExpressより速い理由はここにあります。スキーマ定義によって実行時コストを削減しています。

同時接続処理の差

Gin：

• goroutineによる軽量並列
  

Node系：

• イベントループ単一スレッド
  
  
• I/Oには強いがCPU負荷に弱い
  

純CPU負荷テストではGinが優位になります。

4. フロントエンド実測パフォーマンス比較

フロントエンドは以下の流れで描画されます。

差が出るのは主にJS量とHydration方式です。

HTML生成方式の違い

Astro：

• デフォルト静的生成
  
  
• サーバーで完結
  

Next.js：

• SSR/ISR
  
  
• 動的生成可能
  

SvelteKit：静的＋SSR両対応

静的中心ほどLCPは安定します。

Hydration戦略の違い

・Astro：部分Hydration（必要箇所のみ）

・SvelteKit：軽量ランタイム

・Next.js：React全体Hydrationになりやすい

・Nuxt：Vue依存のHydration

JS実行時間がLCPとTBTに影響します。

5. パフォーマンスランキング

ここでは「なぜこの順位になるのか」を明確にします。

APIサーバー性能ランキング

1位：Gin

理由：

• Goランタイムの軽量スレッド（goroutine）
  
• GC効率が高い
  
• ルーティングが軽量
  
• ネイティブコンパイルで実行効率が高い
  

優位点：Node系よりCPU効率が高く、高RPSを安定して出せる。

2位：Fastify

理由：

• スキーマ駆動バリデーション
  
• JSONシリアライズ最適化
  
• ミドルウェア構造が軽量
  

優位点：Expressより内部オーバーヘッドが少ない。

3位：Hono

理由：

• ミニマル設計
  
• Edge実行前提
  
• Web標準API中心
  

優位点：Cloudflare WorkersなどのEdge環境で低レイテンシ。

4位：Express

理由：

• ミドルウェアチェーン型で柔軟
  
• ただし抽象化が厚い
  

劣る点：オーバーヘッドが比較的大きい。

静的・LPパフォーマンスランキング（LCP重視）

1位：Astro

理由：

• アイランドアーキテクチャ
  
• デフォルトでクライアントJS最小
  
• 静的生成前提
  

優位点：JSゼロに近い構成が可能。LCPが非常に安定。

2位：SvelteKit

理由：

• コンパイル時最適化
  
• 仮想DOMなし
  
• 軽量Hydration
  

優位点：React系よりJS量が小さい傾向。

3位：Next.js

理由：

• SSR/ISR柔軟
  
• 画像最適化機能あり
  

弱点：HydrationコストがReact依存で増えやすい。

4位：Nuxt

理由：

• VueベースSSR
  
• 設定次第で軽量化可能
  

弱点：構成が重くなるケースあり。

6. 実践ベンチマーク構成例

実務で測る場合：

• k6で負荷テスト
• LighthouseでLCP測定
• WebPageTestでTTFB確認
• Productionビルド限定

簡易構成例：

API: JSONレスポンス

同一VPS

同一CDNなし

同一圧縮設定

条件を揃えない比較は無意味です。

7. ランディングページ・マーケ用途で本当に効く選択

LPや広告流入ページでは、

重要なのは：

• LCP 2.5秒以内
• CLS 0.1未満
• JS最小化

この条件では、サーバーRPSよりJS量が支配的です。

したがって：

静的中心 → Astro
軽量SSR → SvelteKit
CMS統合＋大規模 → Next.js

ExpressやGinの速度差はLPではほぼ影響しません。

8. 速度が出ない本当の原因

実務で遅い原因の多くは：

• 画像未最適化
• 不要なクライアントJS
• DBインデックス不足
• キャッシュ未設計

フレームワークの差は10〜30%程度でも、設計ミスは数倍の差を生みます。

ランキングより設計品質の方が影響は大きいです。

Web フレームワーク ランキングをパフォーマンス視点で整理すると、API純処理ではGinやFastifyが優位、静的中心フロントではAstroやSvelteKitが有利です。しかし実際の体感速度はTTFB、LCP、CLSの複合結果で決まります。RPSが高いこととユーザー体験が良いことは同義ではありません。用途別に評価軸を分け、ベンチマーク条件を揃えて判断することが重要です。最速を探すより、自分の構成で最もボトルネックを減らせる選択をする。それが現代Web開発における現実的なフレームワーク選定基準です。