シングルページアプリケーション

シングルページ アプリケーション( SPA ) は、新しいページ全体を読み込むデフォルトの方法ではなく、現在のWeb ページをWeb サーバーからの新しいデータで動的に書き換えることでユーザーと対話するWeb アプリケーションまたはWeb サイトです。目標は、Web サイトをネイティブアプリのように感じられるよう、遷移を高速化することです。

SPAでは、ページの更新は行われません。代わりに、必要なHTML、JavaScript、CSSコードはすべて、1回のページの読み込みでブラウザによって取得されるか、^[1]適切なリソースが必要に応じて動的に読み込まれ、ページに追加されます（通常はユーザーのアクションに応じて）。

シングルページアプリケーションという用語の起源ははっきりしていませんが、この概念は少なくとも2003年にはNetscapeの技術伝道者によって議論されていました。^[2]ウェールズのカーディフ大学のプログラミング学生であるスチュアート・モリスは、 2002年4月に同じ目標と機能を備えた自己完結型のWebサイトをslashdotslash.comに作成し、^[3]同年後半にはルーカス・バード、ケビン・ハクマン、マイケル・ピーチー、クリフォード・イェーが米国特許8,136,109でシングルページアプリケーションの実装を説明しました。^{[4]初期の形式は}リッチウェブアプリケーションと呼ばれていました。

JavaScript は、Web ブラウザーでユーザー インターフェイス(UI) を表示したり、アプリケーション ロジックを実行したり、Web サーバーと通信したりするために使用できます。SPA の構築をサポートする成熟した無料ライブラリが用意されており、開発者が記述する必要がある JavaScript コードの量を削減できます。

アプリケーションがサーバー通信を必要とする場合でも、ブラウザが単一のページを保持できるようにするさまざまなテクニックが利用可能です。

HTML 作成者は、要素 ID を利用して HTML ドキュメントのさまざまなセクションを表示または非表示にすることができます。次に、CSS を使用して、作成者は:target疑似クラス セレクターを使用して、ブラウザーが移動したページのセクションのみを表示することができます。

AngularJS、Ember.js、ExtJS、Knockout.js、Meteor.js、React、Vue.js、Svelteなどの Web ブラウザー JavaScript フレームワークとライブラリはSPA 原則を採用しています。ExtJS を除いて、これらはすべて無料です。

• AngularJS は、完全にクライアント側のフレームワークです。AngularJS のテンプレートは、双方向UI データ バインディングに基づいています。データ バインディングは、モデルが変更されるたびにビューを自動的に更新する方法であり、ビューが変更されるたびにモデルを更新する方法でもあります。HTML テンプレートはブラウザーでコンパイルされます。コンパイル ステップでは純粋な HTML が作成され、ブラウザーはそれをライブ ビューに再レンダリングします。このステップは、後続のページ ビューで繰り返されます。従来のサーバー側 HTML プログラミングでは、コントローラーやモデルなどの概念がサーバー プロセス内で対話して新しい HTML ビューを生成します。AngularJS フレームワークでは、コントローラーとモデルの状態はクライアント ブラウザー内で維持されます。したがって、サーバーと対話することなく新しいページを生成できます。
• Angular 2+は、AngularJS に続いて Google が開発した SPA フレームワークです。Angular より数歩先を進んでおり、このフレームワークを使用する強力な開発者コミュニティがあります。フレームワークは年に 2 回更新されます。現在のバージョンは Angular 18.0.3 (2024 年 6 月現在^{[アップデート]}) で、このフレームワークには新しい機能や修正が頻繁に追加されています。
• Ember.jsは、モデル - ビュー - コントローラ(MVC) ソフトウェア アーキテクチャ パターンに基づくクライアント側 JavaScript Web アプリケーション フレームワークです。これにより、開発者は、豊富なオブジェクト モデル、宣言型の双方向データ バインディング、計算プロパティ、Handlebars.js による自動更新テンプレート、アプリケーション状態を管理するためのルーターを提供するフレームワークに一般的なイディオムとベスト プラクティスを組み込むことで、スケーラブルなシングル ページ アプリケーションを作成できます。
• ExtJSは、MVC アプリケーションを作成できるクライアント サイド フレームワークでもあります。独自のイベント システム、ウィンドウとレイアウトの管理、状態管理 (ストア)、さまざまな UI コンポーネント (グリッド、ダイアログ ウィンドウ、フォーム要素など) を備えています。動的または静的ローダーを備えた独自のクラス システムを備えています。ExtJS で構築されたアプリケーションは、単独で存在することも (ブラウザーに状態がある)、サーバーと共に存在することもできます (たとえば、内部ストアを埋めるために使用されるREST API を使用)。ExtJS には localStorage を使用する機能のみが組み込まれているため、大規模なアプリケーションでは状態を保存するためにサーバーが必要です。
• Knockout.jsは、Model-View-ViewModelパターンに基づくテンプレートを使用するクライアント側フレームワークです。
• Meteor.jsは、SPA 専用に設計されたフルスタック (クライアント サーバー) JavaScript フレームワークです。Angular、Ember、ReactJS ^[5]よりもシンプルなデータ バインディングを特徴とし、分散データ プロトコル^[6]とパブリッシュ サブスクライブ パターンを使用して、開発者が同期コードを記述しなくても、データの変更をリアルタイムでクライアントに自動的に伝播します。フル スタックの反応性により、データベースからテンプレートまで、すべてのレイヤーが必要に応じて自動的に更新されます。サーバー サイド レンダリング^[7]などのエコシステム パッケージは、検索エンジン最適化の問題に対処します。
• Reactは、ユーザーインターフェースを構築するためのJavaScriptライブラリです。Facebook 、Instagram、および個人の開発者や企業のコミュニティによって管理されています。Reactは、JSとHTML（HTMLのサブセット）を組み合わせたJSXというJavaScriptの構文拡張を使用します。いくつかの企業は、状態管理機能を追加するRedux（JavaScriptライブラリ）とReactを使用しており、これにより（他のいくつかのライブラリと併せて）開発者は複雑なアプリケーションを作成できます。^[8]
• Vue.jsは、ユーザー インターフェイスを構築するための JavaScript フレームワークです。Vue 開発者は、状態管理用の Pinia も提供しています。
• Svelte は、Svelte コードを JavaScript DOM (Document Object Model) 操作にコンパイルするユーザー インターフェイスを構築するためのフレームワークです。これにより、フレームワークをクライアントにバンドルする必要がなくなり、アプリケーション開発構文が簡素化されます。

2006年の時点で、最もよく使われていた技術はAjaxでした。^[1] Ajaxでは、JavaScriptのXMLHttpRequestや、より新しいもの（2017年以降）、または非推奨のActiveX Objectなどを使用して、サーバーにXMLまたはJSONデータを非同期で要求します。ほとんどのSPAフレームワークの宣言型アプローチとは対照的に、Ajaxでは、WebサイトはJavaScriptまたはjQueryなどのJavaScriptライブラリを直接使用してDOMを操作し、HTML要素を編集します。Ajaxは、より単純な構文を提供し、歴史的に動作が異なっていた異なるブラウザ間でのAjaxの動作を標準化するjQueryなどのライブラリによってさらに普及しました。 fetch()

WebSocketはHTML仕様の一部である双方向リアルタイムクライアントサーバ通信技術です。リアルタイム通信の場合、パフォーマンス^[9]とシンプルさの点でAjaxよりも優れています。

サーバー送信イベント(SSE) は、サーバーがブラウザ クライアントへのデータ送信を開始できる技術です。最初の接続が確立されると、イベント ストリームはクライアントによって閉じられるまで開いたままになります。SSE は従来の HTTP 経由で送信され、自動再接続、イベント ID、任意のイベントを送信する機能など、WebSocket には設計上欠けているさまざまな機能があります。^[10]

この方法は時代遅れですが、 Silverlight、Flash、Java アプレットなどのブラウザ プラグイン テクノロジを使用して、サーバーへの非同期呼び出しを実現することもできます。

サーバーへのリクエストは通常​​、生データ (例: XMLまたはJSON ) または新しいHTMLが返されます。サーバーから HTML が返される場合、クライアントの JavaScript は DOM (ドキュメント オブジェクト モデル) の一部を更新します。生データが返される場合、多くの場合、クライアント側の JavaScript XML /( XSL ) プロセス (JSON の場合はテンプレート) を使用して生データが HTML に変換され、その後 DOM の一部が更新されます。

SPA はロジックをサーバーからクライアントに移動し、Web サーバーの役割は純粋なデータ API または Web サービスへと進化します。このアーキテクチャの変化は、複雑さがサーバーからクライアントに移動したことを強調し、最終的にはシステム全体の複雑さが軽減されるという主張から、一部の分野では「シン サーバー アーキテクチャ」と呼ばれています。

サーバーは、ページのクライアント状態のメモリに必要な状態を保持します。このように、サーバーにリクエストが届くと (通常はユーザー アクション)、サーバーは具体的な変更を含む適切な HTML や JavaScript を送信し、クライアントを新しい望ましい状態にします (通常はクライアント DOM の一部を追加/削除/更新します)。同時に、サーバーの状態が更新されます。ロジックのほとんどはサーバー上で実行され、HTML も通常はサーバー上でレンダリングされます。サーバーはいくつかの方法で Web ブラウザーをシミュレートし、イベントを受信して​​サーバー状態の差分変更を実行し、それが自動的にクライアントに伝播されます。

このアプローチでは、より多くのサーバー メモリとサーバー処理が必要になりますが、a) アプリケーションは通常サーバー内で完全にコーディングされ、b) サーバー内のデータと UI 状態は同じメモリ空間で共有され、カスタムのクライアント/サーバー通信ブリッジが不要なため、開発モデルが簡素化されるという利点があります。

これは、ステートフル サーバー アプローチのバリエーションです。クライアント ページは、通常、Ajax リクエストを通じて、現在の状態を表すデータをサーバーに送信します。このデータを使用して、サーバーは、変更する必要があるページの一部のクライアント状態を再構築し、必要なデータまたはコード (たとえば、JSON または JavaScript) を生成できます。このデータは、クライアントに返されて新しい状態になり、通常は、リクエストのきっかけとなったクライアント アクションに従ってページの DOM ツリーが変更されます。

このアプローチでは、サーバーに送信されるデータ量が増え、サーバーでクライアント ページの状態を部分的または完全に再構築するために、リクエストごとにより多くの計算リソースが必要になる場合があります。同時に、このアプローチは、クライアントごとのページ データがサーバーに保持されないため、より簡単にスケーラブルになり、セッション データの共有やサーバー アフィニティを必要とせずに、Ajax リクエストを異なるサーバー ノードにディスパッチできます。

一部のSPAは、ファイルURIスキームを使用してローカルファイルから実行される場合があります。これにより、ユーザーはサーバー接続に依存せずに、サーバーからSPAをダウンロードし、ローカルストレージデバイスからファイルを実行できるようになります。このようなSPAがデータを保存および更新する場合は、ブラウザベースのWebストレージを使用する必要があります。これらのアプリケーションは、 HTMLで利用できる高度な機能の恩恵を受けています。^[11]

SPAは、ブラウザが元々設計されていたステートレスなページ再描画モデルからの進化であるため、いくつかの新しい課題が浮上しています。考えられる解決策（複雑さ、包括性、作者のコントロールはさまざま）には以下が含まれます。^[12]

• クライアントサイド JavaScript ライブラリ
• SPAモデルに特化したサーバーサイドウェブフレームワーク^{[13] [14] [15]}
• ブラウザの進化とHTML仕様^[16]はSPAモデル向けに設計された

いくつかの一般的なウェブ検索エンジンのクローラーではJavaScriptが実行されないため、^[17] SEO（検索エンジン最適化）は歴史的にSPAモデルの採用を希望する一般向けウェブサイトにとって問題となってきました。^[18]

2009年から2015年にかけて、Google Webmaster Centralは、ステートフルAJAXページのフラグメント識別子の先頭に感嘆符を使用する「AJAXクロールスキーム」^{[19] [20]}を提案し、その後推奨しました（ ）。検索エンジンのクローラーが関連メタデータを抽出できるようにするには、SPAサイトで特別な動作を実装する必要があります。このURLハッシュスキームをサポートしていない検索エンジンでは、SPAのハッシュされたURLは表示されません。これらの「ハッシュバン」URIは、ブラウザでJavaScriptを有効にしていないユーザーがページにアクセスできなくなるため、W3CのJeni Tennisonを含む多くのライターによって問題があると考えられてきました。また、ブラウザはRefererヘッダーでフラグメント識別子を送信できないため、HTTPリファラーヘッダーも壊れます。 ^[21] 2015年に、GoogleはハッシュバンAJAXクロール提案を非推奨にしました。^[22]#!

あるいは、アプリケーションは最初のページの読み込みをサーバー上でレンダリングし、その後のページの更新をクライアント上でレンダリングする場合があります。これは、レンダリング コードをサーバーとクライアントで異なる言語またはフレームワークで記述する必要がある場合があるため、従来は困難でした。ロジックのないテンプレートを使用したり、ある言語から別の言語にクロスコンパイルしたり、サーバーとクライアントで同じ言語を使用したりすることで、共有できるコードの量を増やすことができます。

2018年、Googleは、インデックス作成の目的でJavaScriptを多用しないバージョンのページをクローラーに提供したいサイト向けの別のオプションとして、ダイナミックレンダリングを導入しました。^[23]ダイナミックレンダリングは、クライアント側でレンダリングされるページのバージョンと、特定のユーザーエージェント用に事前にレンダリングされたバージョンを切り替えます。このアプローチでは、Webサーバーが（ユーザーエージェント経由で）クローラーを検出し、レンダラーにルーティングし、そこからよりシンプルなバージョンのHTMLコンテンツが提供されます。2024年現在、Googleはダイナミックレンダリングを推奨しなくなり、^[24]代わりに「サーバー側レンダリング、静的レンダリング、またはハイドレーション」を提案しています。

SEO 互換性は SPA では重要ではないため、検索エンジンのインデックス作成が必須または望ましいコンテキストでは、SPA は一般的に使用されないことに注意してください。使用例には、認証システムの背後に隠されたプライベート データを表示するアプリケーションが含まれます。これらのアプリケーションが消費者向け製品である場合、アプリケーションのランディング ページとマーケティング サイトには、従来の「ページ再描画」モデルが使用されることが多く、これにより、アプリケーションが検索エンジンのクエリでヒットとして表示されるのに十分なメタデータが提供されます。ブログ、サポート フォーラム、およびその他の従来のページ再描画アーティファクトは、多くの場合、検索エンジンに関連する用語をシードする可能性のある SPA の周囲に配置されます。

2021年現在、特にGoogleでは、プレーンSPAのSEO互換性は簡単で、いくつかの簡単な条件を満たすだけで済みます。^[25]

サーバーとクライアント間で共有できるコードの量を増やす方法の 1 つは、MustacheやHandlebarsなどのロジックのないテンプレート言語を使用することです。このようなテンプレートは、サーバー上のRubyやクライアント上のJavaScriptなど、異なるホスト言語からレンダリングできます。ただし、テンプレートを共有するだけでは、通常、適切なテンプレートを選択してデータを設定するために使用されるビジネス ロジックの重複が必要になります。テンプレートからのレンダリングは、大きなテンプレート内のテキスト入力の値など、ページの小さな部分のみを更新する場合、パフォーマンスに悪影響を与える可能性があります。テンプレート全体を置き換えると、ユーザーの選択やカーソルの位置が乱れる可能性がありますが、変更された値のみを更新すると乱れることはありません。これらの問題を回避するために、アプリケーションはUI データ バインディングまたは詳細なDOM操作を使用して、テンプレート全体を再レンダリングするのではなく、ページの適切な部分のみを更新できます。^[26]

SPA は定義上「単一ページ」であるため、このモデルは「進む」または「戻る」ボタンを使用したページ履歴ナビゲーションのブラウザ設計を破壊します。これにより、ユーザーが SPA 内の前の画面状態を期待して戻るボタンを押したときに、アプリケーションの単一ページがアンロードされ、ブラウザの履歴内の前のページが表示されるという、ユーザビリティの障害が発生します。

SPA の従来のソリューションは、現在の画面状態に応じてブラウザ URL のハッシュフラグメント識別子を変更することでした。これは JavaScript で実現でき、ブラウザ内に URL 履歴イベントが蓄積されます。SPA が URL ハッシュ内に含まれる情報から同じ画面状態を復元できる限り、期待される [戻る] ボタンの動作は保持されます。

この問題をさらに解決するために、HTML 仕様では、実際の URL とブラウザ履歴へのプログラムによるアクセスを提供する pushState と replaceState が導入されました。

Google Analyticsなどの分析ツールは、新しいページの読み込みによって開始される、ブラウザでの新規ページ全体の読み込みに大きく依存しています。SPA はこのようには動作しません。

最初のページが読み込まれた後、後続のページとコンテンツの変更はすべてアプリケーションによって内部的に処理されます。アプリケーションは、分析パッケージを更新する関数を呼び出すだけで済みます。このような関数を呼び出さないと、ブラウザは新しいページの読み込みをトリガーせず、ブラウザの履歴には何も追加されず、分析パッケージはサイト上で誰が何をしているかを把握できません。

検索エンジンのクローラーで発生する問題と同様に、DAST ツールはこれらの JavaScript を多用したアプリケーションで苦労する可能性があります。問題には、ハイパーテキスト リンクの欠如、メモリ使用量の懸念、SPA によって読み込まれるリソースが通常アプリケーション プログラミング インターフェイス(API) によって利用可能になることが含まれます。シングル ページ アプリケーションは、クロスサイト スクリプティング (XSS)などの従来の Web ページと同じセキュリティ リスクにさらされていますが、API やクライアント側ロジックを介したデータ漏洩、サーバー側セキュリティのクライアント側での強制など、他の多くの固有の脆弱性も抱えています。^[27]シングル ページ アプリケーションを効果的にスキャンするには、DAST スキャナーがクライアント側アプリケーションを信頼性が高く繰り返し可能な方法でナビゲートして、アプリケーションのすべての領域を検出し、アプリケーションがリモート サーバーに送信するすべての要求 (API 要求など) を傍受できる必要があります。

HTML History API を使用すると、SPA にページ読み込みイベントを追加できます。これにより、分析を統合できます。難しいのは、これを管理し、すべてが正確に追跡されていることを確認することです。これには、レポートの欠落や重複エントリのチェックが含まれます。一部のフレームワークでは、主要な分析プロバイダーのほとんどに対応する無料の分析統合を提供しています。開発者はそれらをアプリケーションに統合し、すべてが正しく機能していることを確認できますが、すべてをゼロから行う必要はありません。^[26]

SPA の初期読み込みを高速化する方法には、SPA ランディング/インデックス ページの選択的な事前レンダリング、キャッシュ、必要に応じてモジュールを遅延読み込みするなどのさまざまなコード分割手法などがあります。ただし、フレームワーク、少なくとも一部のアプリケーション コードをダウンロードする必要があるという事実から逃れることはできません。また、ページが動的な場合は、データのために API にアクセスします。^[26]これは、「今支払うか、後で支払うか」というトレードオフ シナリオです。パフォーマンスと待機時間の問題は、開発者が決定しなければならない問題です。

SPA は最初のページ読み込み時に完全に読み込まれ、その後、ページ領域は、オンデマンドでサーバーから読み込まれた新しいページ フラグメントで置き換えられたり更新されたりします。使用されていない機能の過剰なダウンロードを回避するために、SPA は、必要になるにつれて、ページの小さなフラグメントまたは完全な画面モジュールのいずれかの機能を徐々にダウンロードすることがよくあります。

このように、SPA の「状態」と従来の Web サイトの「ページ」の間には類似点があります。同じページ内の「状態ナビゲーション」はページ ナビゲーションに類似しているため、理論的には、ページベースの Web サイトは、同じページ内で変更された部分のみを置き換えることで単一ページに変換できます。

Web 上の SPA アプローチは、ネイティブデスクトップ アプリケーションで一般的なシングル ドキュメント インターフェイス(SDI) プレゼンテーション手法に似ています。

• プログレッシブ ウェブ アプリケーション (PWA)
• サーバーサイドスクリプト

• マルチページ Web アプリケーションからシングルページ Ajax インターフェイスへの移行 (デルフト工科大学)
• シングルページインターフェース宣言
• ダイナミックレンダリング