SPAの初回表示が遅い理由をブラウザ解析

Webパフォーマンス SPA フロントエンド ブラウザ処理 JavaScript

SPAはなぜ初回表示が遅くなりやすいのか

SPA（Single Page Application）は「高速なWebアプリ」として語られることが多い一方、初回アクセス時に遅いと感じるケースが頻繁にあります。これは回線速度やサーバ性能の問題ではなく、ブラウザのパース処理の順序が原因です。

特に「真っ白な画面が数秒続いてから突然表示される」現象は、SPA特有の挙動です。ここを理解しないまま最適化を行うと、CDNを導入しても、サーバを増強しても、ほとんど効果が出ません。

結論から言うと、SPAは「通信が遅い」のではなく描画までに必要な準備工程が多いため、初回表示が遅くなりやすい構造を持っています。

ブラウザがページを表示するまでの流れ

URLにアクセスすると、ブラウザは次の順番で処理を行います。

  • HTMLを取得
  • HTMLをパース（DOM構築）
  • CSSを取得
  • CSSOM構築
  • レンダーツリー生成
  • レイアウト計算
  • ペイント（画面描画）

通常のWebサイトでは、HTML内に文章や画像が含まれているため、HTMLのパースが始まった段階で徐々に表示が始まります。

しかしSPAでは事情がまったく異なります。

SPAで実際に起きている処理

典型的なSPAのHTMLは次のようになります。

<body>
  <div id="root"></div>
  <script src="/bundle.js"></script>
</body>

HTMLには表示内容がほとんど含まれていません。つまり、HTMLのパースが完了しても描画する内容が存在しません。

ここからがSPA特有の長い準備工程です。

1. JavaScriptのダウンロード**

bundle.jsは数百KB〜数MBになることがあります。まずこの取得が必要です。

2. JavaScriptのパース**

ブラウザはJSをダウンロードするだけでなく、解析（パース）します。ここでCPUが使われます。ネットワークではなく端末性能に依存します。

3. 実行（評価）**

モジュール解決、依存関係読み込み、フレームワーク初期化が行われます。ReactやVueではここで仮想DOMやコンポーネントツリーが構築されます。

4. API通信**

初期データ取得のためのHTTPリクエストがここで発生します。

fetch("/api/articles")
  .then(r => r.json())
  .then(data => render(data));

5. DOM生成**

データを受け取って初めてHTML要素が作られます。

つまり、SPAは「HTML取得後すぐ表示」ではなく、

HTML → JS取得 → JS解析 → JS実行 → API通信 → DOM生成 → 描画

という段階を踏みます。この処理の連鎖が、初回表示遅延の正体です。

「通信が遅い」のではない

ここで重要なのは、ボトルネックがネットワークとは限らない点です。

実際の性能測定では、次の時間が大きくなります。

  • JS Parse（JavaScript解析時間）
  • Script Evaluation（実行時間）
  • Main Thread Blocking（メインスレッド占有）

つまりSPAの遅さはブラウザのCPU処理時間です。高性能PCでは速く、スマートフォンでは極端に遅くなります。

このため、社内検証で「速い」と判断されたSPAが、本番ユーザから「遅い」と言われる事態が頻繁に起きます。開発者のPCとユーザ端末の性能差が原因です。

なぜSSRは早く見えるのか

SSRでは最初に受け取るHTMLに内容が含まれています。

<h1>記事タイトル</h1>
<p>本文...</p>

ブラウザはHTMLをパースしながら描画できます。JavaScriptを待つ必要がありません。これにより「First Contentful Paint」が早くなります。

つまりSSRが速いのではなく、表示開始が早いのです。

初回表示を悪化させる要因

SPAの初期表示をさらに遅くする代表的な要因があります。

  • 巨大なJavaScriptバンドル
  • 初期APIの多重リクエスト
  • 同期的な初期化処理
  • 不要なライブラリ読み込み

特に起きやすいのが「管理画面向けライブラリの流用」です。リッチUIライブラリをそのまま公開ページに使うと、初期ロードが急激に増加します。

よくある誤った対策

CDN導入だけでは改善しないケースがあります。理由は、JSダウンロード後の処理が支配的だからです。

また画像最適化も初期表示にはあまり効きません。SPAでは画像表示まで到達する前に時間がかかるためです。

実務上の注意点

SPAを採用する場合、次の点を意識しないとユーザ体験が悪化します。

  • コード分割（Code Splitting）
  • 遅延ロード（Lazy Loading）
  • 初期API削減
  • スケルトンスクリーン導入

ただし、スケルトンスクリーンは「速くする」のではなく「遅さを隠す」技術です。UXは改善しますが、性能改善ではありません。

結局どうすればよいか

SPAは「表示が遅い技術」ではありません。起動に時間がかかるアプリケーションです。ネイティブアプリの起動時間に近い性質を持っています。

もし「ページを開いた瞬間に内容を見せたい」のであれば、SPA単体では構造的に不利です。SSR併用やプリレンダリングを検討すべきです。

逆に、ログイン後に長時間操作される管理画面では、初回の数秒を許容することで、その後の操作性が大きく向上します。

重要なのは、SPAの遅さを最適化の問題として扱わないことです。これは性能チューニングではなく、アーキテクチャ特性です。初回表示を最優先するのか、操作体験を優先するのかを先に決めることが、SPA採用で失敗しないための分岐点になります。