この記事は GAOGAO Advent Calendar 2025 3日目の記事です。
SPAでは、画面遷移ごとにページを再読み込み(MPA)せず、APIを使用して必要なデータを取得します。したがって、HTTP通信の理解と最適化はSPAの質に繋がります。
ここでは、SPAに関わるHTTPの最適化について整理します。
1. HTTP通信の基本構造
SPAが行う通信はシンプルに言えば以下の繰り返しです(初回にHTML, jsの読み込みが入ります)
- ブラウザがAPIリクエストを送る
- APIサーバーがレスポンスを返す
- SPA(Reactアプリなど)がそのデータを画面描画に使う
2. HTTPリクエストに関するポイント
2-1. リクエストは「回数が多いほど遅くなる」
HTTP通信には「1リクエストあたりの固定コスト(オーバーヘッド)」があります。
- DNS lookup
- 接続確立（TLSハンドシェイク）
- リクエストヘッダの送信
- サーバー処理
- レスポンスの受信
そのため、APIの回数を減らすだけで体感速度が大きく変わリます。
HTTP3に至ってはTLSハンドシェイクが短くなったり性能が上がっていますが、それでもAPIの回数を減らすことは重要です。
よくあるボトルネックの例
- 様々な場所で多くのAPIを呼んでいる
- 重複してデータを取得する
- タイピング毎にリクエストが飛ぶ検索フォーム
2-2. リクエストヘッダ・Cookieは意外と重い
特にSPAのAPIでは、以下が毎回付くことが多いです：
- Authorization(JWTやBearer Token)
- Cookie(認証情報)
- メタデータ
→ 小さなAPIでもヘッダが大きいと通信時間が無視できなくなる
→ GraphQLやRESTの最適化時にも重要になってくる
2-3. HTTPメソッドは最低限覚える
何を最適化の対象にすべきか、どのように最適化すべきか判断しやすくなるためです。
| メソッド | 意味 |
|---|---|
| GET | データ取得（キャッシュしやすい） |
| POST | 新規作成（キャッシュされない） |
| PUT/PATCH | 更新 |
| DELETE | 削除 |
SPAではGETの最適化（キャッシュ） が最も効きます。
3. HTTPレスポンスの重要ポイント
3-1. JSONはサイズが大きいと遅い
SPAはAPIからJSONを取得しますが、JSONは読みやすい代わりに重いです。
- 不要なフィールド
- 過剰にネストした構造
- 使わないデータを全部返す
→ レスポンス約10KB→50KBでも体感速度に差
→ モバイルや低速ネットワークではさらに顕著です。
3-2. 圧縮（gzip / brotli）は必須
圧縮されていればレスポンスサイズは大幅に減ります。
3-3. Cache-Control / ETag による効率化
SPAでは「毎回同じデータを取りに行く」ことが多いため、キャッシュ戦略が重要です。
- Cache-Control
- ETag（If-None-Match）
を使えば、
- 再利用（高速）
- 差分のみ取得（軽量）
が可能になります。
React Query などのライブラリを使うとさらに効率的です。
4. HTTP/1.1, HTTP/2, HTTP/3 の違いとSPAへの影響
4-1. HTTP/2 の重要ポイント
HTTP/1.1は同時接続数に限りがあり、リクエストが詰まりやすいです
それに対してHTTP/2には以下のメリットがあります：
- 一つの接続で複数リクエストを同時送信可能
- ヘッダ圧縮
→ APIを大量に叩くSPAはHTTP/2で非常に恩恵が大きいです。
CDNやAPI GatewayがHTTP/2対応だと体感速度が上がりやすいです。
4-2. HTTP/3
HTTP/1.1 の問題で一つの接続で1リクエストが基本です。
→ 同時通信が遅い
HTTP/2の改善
一つの接続で複数リクエストを同時送信可能
→ しかし「TCPの仕組み」がボトルネックになる
ここで登場するのがHTTP/3です。
→ HTTP/3はTCPを廃止し、UDP上でQUICプロトコルを使用します。
HTTP/3は他と比べてWebサービスの表示が速くなり、特に SPA・PWA・API通信の多いアプリで効果が大きいです。
5. SPA通信最適化の実践ポイント
5-1. リクエスト数を減らす
- APIをまとめる（Batch / Bulk API）
- 検索フォームにデバウンス
- 連続通信はスロットリング
- 同じデータはキャッシュから返す
5-2. キャッシュを積極的に使う
SPAではデータが再利用されるケースが多いため、キャッシュ戦略は重要です。
- React Query / SWR の自動キャッシュ
- Stale-While-Revalidate
- LocalStorage / IndexedDB
- Service Worker キャッシュ
→ ネットワークに行かない方が最速
5-3. レスポンスの軽量化
- 必要なフィールドだけ返す
- ページング
- Lazy loading
- gzip/brotli の有効化
- GraphQLでフィールドを選択
5-4. 通信前提のUI設計
SPAでは通信時間をゼロにはできないため、UIも重要です。
- ローディング（スケルトンUI）
- エラー時リトライ
- 楽観的更新（Optimistic UI）
- Strictなローディングチェーンを避ける（依存関係の工夫）
6. まとめ
- SPAにとって通信はコアの部分。アプリの質に紐づいてくる
- HTTP通信のコストは「回数」と「サイズ」で決まる
- GETはキャッシュで速くできる
- HTTP/3対応の環境はSPA向けに有利
- キャッシュ・リクエスト削減・レスポンス最適化が最重要
Discussion