シングルページアプリケーションとは？1 つのドキュメント、多数のビュー

シングルページアプリケーション（SPA）は、1 つの HTML ドキュメントを読み込み、その後 JavaScript を使ってページ全体を再読み込みせずにビューを切り替え、データを取得します。

従来の Web サイトは、ページごとに新しい HTML ドキュメントをリクエストします。SPA は一度読み込まれ、その後はブラウザ内でナビゲーションを処理し、JavaScript でビューを書き換え、API からデータを取得します。これは読み込み後にはアプリのように感じられ高速ですが、処理をクライアントに押し付け、ルーティングとホスティングの設定方法を変えます。

SPA のナビゲーションの仕組み

アプリはリンクのクリックをインターセプトし、ブラウザに新しいページをリクエストさせる代わりに History API で URL を更新します。クライアントの router が URL をコンポーネントにマッピングしてレンダリングするため、ナビゲーションがドキュメントを再読み込みすることはありません。

ルーティングの落とし穴

サーバーには実質的に 1 つの HTML ファイルしかないため、deep link を処理する必要があります。ホスティングには、任意のパスに対して app shell を返し、クライアントの router に引き継がせる catch-all のルールが必要です。これが欠けていることは、リロード時の 404 の典型的な原因です。

長所と短所

最初の読み込み後の、スムーズでアプリのようなナビゲーション。
初回の JavaScript ダウンロードが大きく、first paint が遅くなる。
コンテンツがクライアントでレンダリングされるため、SEO には追加の作業が必要。

SPA と SSR

純粋な SPA は完全にブラウザでレンダリングします。SSR は、より速い first paint と SEO のために最初のビューをサーバーでレンダリングし、その後 SPA のような体験へとハイドレートします。多くのフレームワークは現在、この 2 つを組み合わせています。

CI/CD における SPA

SPA の build は静的ファイルを生成するため、CI は他の静的サイトと同様にそれらを build して CDN にアップロードし、すべてのルートに shell を提供するホストの rewrite を設定します。すべてが静的なので deploy はシンプルですが、SPA のペイロードは大きくなりがちなので、pipeline には bundle サイズのチェックを含めるべきです。

重要なポイント

SPA は一度読み込まれ、JavaScript でビューを更新し、ページ全体の再読み込みを避けます。
ホスティングには、deep link が app shell を返すようにするための catch-all の rewrite が必要です。
CI は静的な出力を CDN に deploy します。pipeline では bundle サイズに注意しましょう。