これはno plan inc.の Advent Calendar 2023の２０日目の記事です。
概要
現在フロントエンドエンジニアのWeb開発を勉強中です。
Web開発の際、MPA (Multi Page Application)・SPA (Single Page Application)・SSR (Server-Side Rendering)・SSG (Static Site Generation)などのレンダリング手法用語が出てきます。
これらを１言で言うと、「ウェブページ生成方法」または「レンダリング戦略」などと言うそうです。
これらの概念はフロントエンドエンジニアにとっては重要ですが、初めて開発を行う私にとっては複雑な内容に感じたので、これらの概念のまとめと例を記事にしました。
Web開発初学者ですので誤っている点がありましたら、ご指摘いただけると幸いです。
「概念の例え」
まず初めに、「ウェブページ生成方法」のそれぞれの違いを、一旦超ざっくりイメージしてもらう為に、例え話をします。
ここではわからなくて大丈夫ですので、「ふ〜ん。」と言う感じで聞いてください。
逆にわかりにくくなると申し訳ないのですが、私は何かに例えるとイメージしやすいのでそれぞれのイメージをレストランに例えてみました。
「それぞれの概念をレストランで例えると」
①MPA（Multi Page Application）
伝統的なコース料理のレストランに似ています。ここでは、お客さんが各料理（ウェブページ）を一つずつ注文し、各コースが別々に調理されて提供されます。コース料理は一皿終わるごとにスタッフが次の皿を準備し、それぞれの皿が独立した美味しさ（ページの内容）を提供します。
メリット: 時間がかかりますが、各料理（ページ）が個別に準備されるため、特定の味（コンテンツ）を楽しむことができます。
それぞれの料理が独自の特徴を持つため、多様な体験を提供できます。
②SPA（Single Page Application）
SPAは、オーダーしてから全ての料理が一度にテーブルに運ばれてくるフルコースディナーに似ています。料理がテーブルにある間、あなたは自由に好きな料理を選んで食べることができます（ページのコンテンツの選択）。つまり、最初の一回のオーダーで全ての選択肢がテーブルに提供され、その後は追加のオーダーなしに料理を楽しむことができます。
メリット: １度のオーダーで必要な全てを手に入れるため、迅速に様々な料理（ページコンテンツ）にアクセスできます。
何度もウェイターを呼ぶ必要がなく、スムーズな食事体験を提供します。
③SSR（Server-Side Rendering）
ファーストフードレストランに似ています。お客さんが注文（ページリクエスト）をすると、厨房（サーバー）では既に準備されている料理（ウェブページ）を提供します。注文に応じて瞬時に料理を提供することができるため、サービスが迅速です。
メリット: 注文（リクエスト）に対して迅速に応答できるため、顧客満足度が高まります。
既に準備されている料理を提供するため、待ち時間が短くなります。
④SSG（Static Site Generation）
事前に調理された料理がすでに展示されているビュッフェスタイルのレストランに似ています。来店すると、多様な料理（ウェブページのコンテンツ）がすでに準備され、自由に選んで食べることができます。すべての料理は事前に準備されているため、オーダーを待つ必要がなく、すぐに料理を楽しむことができます。
メリット: 事前に準備された料理により、待ち時間なしに即座に食事を提供できます。
多様な料理を自由に選ぶことができ、迅速なサービスを提供します。
「体系的に解説」
ではここからは体系的に解説していきます。
①【MPA（Multi Page Application）】
MPA（Multi Page Application）は先ほど説明したSPA（Single Page Application）とは対照的な概念です。
「基本概念」
MPAは、従来のウェブサイトの構造で、個々のページが別々に存在します。
ユーザーが新しいページに移動するたびに、ウェブサーバーからそのページの完全なHTML、CSS、JavaScriptをロードします。
「レンダリング方法」
サーバーサイドレンダリング
MPA（Multi Page Application）では、ユーザーが異なるページにアクセスするたびに、サーバー側でそのページのHTMLが生成され、クライアントに送信されます。
各ページのロードはサーバー側で完全に処理されます。
「使用背景」
ウェブの初期段階で最も一般的なアプローチでした。
ウェブサイトは個別のページで構成され、それぞれが独自のURLを持っていました。
目的: MPA（Multi Page Application）は、情報を整理しやすく、各ページが独立していることから、SEOに有利であり、ウェブの基本的な構造を提供するために使用されてきました。
「メリット」
SEOに有利: 個々のページが独立しているため、検索エンジンによるインデックス作成が容易です。
明確なナビゲーション: ユーザーは伝統的なウェブブラウジング体験を享受でき、ページ間での移動が直感的です。
「デメリット」
遅いページ遷移: 新しいページに移動するたびにサーバーから全てのリソースを再度ロードする必要があり、ページのレスポンスが遅くなることがあります。
開発の複雑化: フロントエンドとバックエンドが密接に結びついているため、大規模なアプリケーションでは開発が複雑になる可能性があります。
「実装方法」
MPA（Multi Page Application）は、RailsやASP.NETなどのサーバーサイドフレームワークを使用して構築できます。これらのフレームワークでは、サーバー側でHTMLを生成し、クライアントに送信します。
「補足」
※サーバーサイドフレームワークとは、 サーバー側で動作するアプリケーションの基盤。ページごとにHTMLを生成し、ブラウザに送信する。
※ページ遷移とは、 ユーザーがリンクをクリックするなどして別のページに移動すること。MPA（Multi Page Application）では、この遷移のたびに新しいページのリソースがロードされる。
次に
②【SPA（Single Page Application）】
「基本概念」
SPA（Single Page Application）は、Webサイトが一つのページで構成され、ユーザーの操作に応じて動的に内容が変化するアプローチです。
この方式では、最初のページロードをした時にウェブサイトの見た目などに必要なリソース（HTML、CSS、JavaScript）をWebサーバーからダウンロードします。
以後のUI描画や、ページ遷移をした際のUIの変化はJavaScriptを使って動的に処理されます。
つまり、必要なリソース（HTML、CSS、JavaScript）の全てをサーバーから１度だ取得し、その後のページの変更はJavaScriptで再描画を行うと言う感じです。。
なお、2回目以降のページ遷移を表現するためのリクエスト処理はAjaxで実現しています。
「レンダリング方法」
クライアントサイドレンダリング
SPA（Single Page Application）は、HTML、CSS、JavaScriptが最初のページロードでダウンロードされ、以後のページの更新や遷移はクライアント側（ユーザーのブラウザ）でJavaScriptを用いて動的に行われます。
「使用背景」
伝統的なMPA方式では、ページ遷移ごとに全ページのリロードが必要であり、これがユーザーエクスペリエンスを損ねる要因となっていました。
目的: SPA（Single Page Application）は、この問題を解決するために生み出されました。ウェブアプリケーションのレスポンスを改善し、より滑らかなユーザー体験を提供することを目的としています。ページの一部分だけを更新することで、全ページの再ロードを避けることができます。
「メリット」
ユーザーインターフェースの高速な更新: ページ全体をリロードする代わりに、必要な部分だけを動的に更新するため、ユーザーエクスペリエンスが向上します。
フロントエンドとバックエンドの分離: データ取得とUIの表示が分離されているため、開発が柔軟になります。
「デメリット」
初回ロードの遅延: 最初に必要なすべてのリソースをダウンロードするため、初回ロードが遅くなることがあります。
SEOの最適化が困難: 検索エンジンがJavaScriptをレンダリングするのが難しいため、SEO対策が難しくなります。
「実装方法」
ReactやVue.jsなどのフレームワークを使用してSPAを構築できます。
ReactやVue.jsなどのフレームワークは、コンポーネントベースのアーキテクチャを使用し、データが変更されると自動的にUIを更新します。
「補足」
※コンポーネントとは、１つのページだけではなく、他のページでも何度も再利用するもの（例えばHPのロゴやheaderなど）のこと。
※コンポーネントアーキテクチャとは、再利用可能なコンポーネントに基づいてソフトウェアを構築するためのフレームワークのこと。
※フレームワークとは、枠組み、骨組み、構造などを指す言葉で、ITの世界ではアプリケーションの土台として機能するソフトウェア（ReactやVue.jsなど）のこと。
ちなみに少し脱線しますが、コンポーネントベースアーキテクチャの特徴には下記があります。
再利用性：これらは、変更や特別な調整を必要とせずに、さまざまなアプリケーションにプラグイン（ソフトウェアの機能を拡張するために追加するプログラムを追加）できるように設計されています。
拡張性：コンポーネントを他のコンポーネントと組み合わせて、新しい動作を作成できます。
交換可能性：同様の機能を持つコンポーネントは交換できます。
カプセル化：コンポーネントは自己完結型であり、内部プロセスの詳細を隠しながら、インターフェースを介して機能を公開します。
独立：コンポーネントは他のコンポーネントへの依存関係が最小限であり、さまざまな環境やコンテキストで動作できます。
③【SSR（Server-Side Rendering）】
「基本概念」
SSR（Server-Side Rendering）では、各ページはサーバー上でレンダリングされ、完成したHTMLがクライアントに送信されます。
これにより、ページがより速く表示され、検索エンジンのクローラーが内容をより効率的にインデックスできるようになります。
ページ遷移の際に、Webサーバーへリクエストが送られて、APIと連携しながらレンダリングを行います。その後レンダリングできたものをブラウザに返します。
一見するとMPA（Multi Page Application）に似ていますが、SSR（Server-Side Rendering）は、SPA（Single Page Application）のコンテキストで用いられ、サーバー側でページの初期状態をレンダリングし、その結果をブラウザに送信します。
ページの内容はサーバー側で生成され、クライアント側では追加のJavaScriptによる動的な更新が行われる場合があります。
※SPA（Single Page Application）のコンテキストでのSSRとは、
通常、SPA（Single Page Application）はクライアントサイド（ユーザーのブラウザ）で完全にレンダリングされるため、初回のページロードが遅かったり、SEO（検索エンジン最適化）に不利だったりすることがあります。
ですが、SSR（Server-Side Rendering）をSPA（Single Page Application）に適用することで、これらの問題を解決しようとするのが、ここで言う「SPAのコンテキストでのSSR」です。
SSR（Server-Side Rendering）をSPA（Single Page Application）のコンテキストで使用することで、サーバー側でページの初期状態を生成し、それをクライアントに送信することができます。
これにより、ページの初回ロードが高速化され、SEOが向上します。また、クライアント側での追加のJavaScriptによる動的な更新は、SPA（Single Page Application）の対話的なユーザー体験を維持しつつ行うことができます。
「レンダリング方法」
サーバーサイドレンダリング
SSR(Server-Side Rendering)も、ウェブページの内容がサーバー側で生成され、ブラウザに送信されるアプローチです。
「使用背景」
SPAの普及により、初回ロード時間の遅延やSEOの問題が浮き彫りになりました。
これらはクライアントサイドでのJavaScript処理が主たる原因です。
目的: SSRは、これらの問題を解決するために、サーバー側でページをレンダリングすることで、初回のページロードを高速化し、SEOを向上させることが可能となりました。
「メリット」
高速な初回ページロード: サーバー側でページがレンダリングされるため、初回のコンテンツロードが速くなります。
SEOの向上: 検索エンジンはサーバー側で生成されたHTMLを容易に解析できるため、SEOが向上します。
「デメリット」
サーバーへの負荷増加: すべてのリクエストに対してサーバーでページを生成するため、サーバーの負荷が増加します。
フロントエンドのダイナミズムの制限: ページの一部だけを動的に更新する能力が限られている場合があります。
「実装方法」
Next.jsやNuxt.jsなどのフレームワークを使用してSSRを実現できます。これらはReactやVue.jsの上に構築されており、サーバー側でのレンダリング機能を提供します。
④【SSG（Static Site Generation）】
「基本概念」
SSG（Static Site Generation）では、ウェブサイトのページをビルド時（サイトが作成されるとき）に静的なHTMLとして生成するアプローチです。
簡単に言うと、ビルド（プログラムの元ネタから実際のプログラムを作る作業）の時に、サーバー側でAPIからデータ取得をし、その取得したHTML構築を先に終わらせます。
そしてユーザーからリクエストが会った時に、先ほど構築しておいた「レンダリング済みのHTML」を送る。という感じです。
ウェブサイトの全てのページが静的ファイルとして生成されます。
これにより、リクエストごとにページを生成する必要がなく、ロード時間が大幅に短縮されます。
頻繁にコンテンツが更新されないブログ、ポートフォリオサイト、企業のランディングページなどに適しています。
特に、高速なロード時間とセキュリティが重要な場合に有利です。
「レンダリング方法」
ビルドタイムレンダリング
SSGでは、ウェブページはビルド時（ウェブサイトの構築時）に静的なHTMLとして生成されます。
これらのページは、リクエスト時にサーバーからそのまま提供され、クライアント側での追加的なレンダリングは必要ありません。
「使用背景」
ウェブページのロード速度とセキュリティは、特に静的なコンテンツを提供するサイトにおいて重要な要素です。
目的: SSGは、ロード速度とセキュリティを最適化するために開発されました。
ビルド時に静的なページを生成することで、配信速度を向上させ、サーバーサイドの脆弱性を減少させることができます。
「メリット」
高速なロード時間: 静的ファイルは即座に提供されるため、ページのロードが非常に速いです。
セキュリティ: 動的なサーバーサイド処理が少ないため、セキュリティリスクが低減されます。
「デメリット」
動的機能の制限: リアルタイムのデータやユーザーインタラクションの実装が難しいです。
更新の手間: コンテンツを更新するたびにサイト全体を再ビルドする必要があります。
「SSR（Server-Side Rendering）とSSG（Static Site Generation）の用途選択」
コンテンツの更新頻度: 頻繁に更新が必要なサイトではSSR（Server-Side Rendering）が適している一方で、内容があまり変わらないサイトではSSG（Static Site Generation）が有利です。
パフォーマンスとスケーラビリティ: 高速なパフォーマンスとスケーラビリティが求められる場合、SSG（Static Site Generation）が好ましい選択肢です。
SEOと初回ロード時間: SEOを最適化し、初回ロード時間を短縮したい場合、SSR（Server-Side Rendering）が有効ですが、SSG（Static Site Generation）も十分なパフォーマンスを提供します。
「実装方法」
GatsbyやHugoなどの静的サイトジェネレータを使用してSSG（Static Site Generation）を実装できます。これらは、ビルド時にサイトの全てのページを事前に生成し、高速な配信が可能な静的ファイルを作成します。
長くなりましたが、これで一旦全ての説明が終わりました。
ここでもう一度、記事の冒頭に書いた「レストランの例え」に戻っていただけるとさらに理解しすくなるかと思いますが、戻るのは手間だと思うので下記に再度記載します。
「再度レストランでの例え」
①MPA（Multi Page Application）
伝統的なコース料理のレストランに似ています。ここでは、お客さんが各料理（ウェブページ）を一つずつ注文し、各コースが別々に調理されて提供されます。コース料理は一皿終わるごとにスタッフが次の皿を準備し、それぞれの皿が独立した美味しさ（ページの内容）を提供します。
メリット: 時間がかかりますが、各料理（ページ）が個別に準備されるため、特定の味（コンテンツ）を楽しむことができます。
それぞれの料理が独自の特徴を持つため、多様な体験を提供できます。
②SPA（Single Page Application）
SPAは、オーダーしてから全ての料理が一度に全てテーブルに運ばれてくるフルコースディナーです。料理がテーブルにある間、あなたは自由に好きな料理を選んで食べることができます（ページのコンテンツの選択）。つまり、最初の一回のオーダーで全ての選択肢がテーブルに提供され、その後は追加のオーダーなしに料理を楽しむことができます。
メリット: １度のオーダーで必要な全てを手に入れるため、迅速に様々な料理（ページコンテンツ）にアクセスできます。
何度もウェイターを呼ぶ必要がなく、スムーズな食事体験を提供します。
③SSR（Server-Side Rendering）
ファーストフードレストランに似ています。お客さんが注文（ページリクエスト）をすると、厨房（サーバー）では既に準備されている料理（ウェブページ）を提供します。注文に応じて瞬時に料理を提供することができるため、サービスが迅速です。
メリット: 注文（リクエスト）に対して迅速に応答できるため、顧客満足度が高まります。
既に準備されている料理を提供するため、待ち時間が短くなります。
④SSG（Static Site Generation）
事前に調理された料理がすでに展示されているビュッフェスタイルのレストランに似ています。来店すると、多様な料理（ウェブページのコンテンツ）がすでに準備され、自由に選んで食べることができます。すべての料理は事前に準備されているため、オーダーを待つ必要がなく、すぐに料理を楽しむことができます。
メリット: 事前に準備された料理により、待ち時間なしに即座に食事を提供できます。
多様な料理を自由に選ぶことができ、迅速なサービスを提供します。
「まとめ」
これらの概念を理解することは、最適なウェブサイトのアーキテクチャを選択する上で非常に重要です。
SPA（Single Page Application）はインタラクティブなユーザー体験を提供し、SSR（Server-Side Rendering）はSEOとパフォーマンスを最適化し、SSG（Static Site Generation）は速度と安全性に優れています。
プロジェクトの要件に応じて、これらのアーキテクチャ（プログラムの構造）を適切に選択することが最適解だと思います。
さらに言うと、１つのWｅｂサイトに２つのアーキテクチャ（プログラムの構造）を使用して（例えば、SSR（Server-Side Rendering）とSSG（Static Site Generation）の２つを使う）ハイブリッドなサイトを構築することができるようです。
この柔軟性により、さまざまな要件に対応できるウェブサイトを実現していけるようにさらに精進していきます。
以上、この記事が読者の方の基本概念理解や、プロジェクトに適用する際の手助けになれば幸いです。
no plan inc.で扱っているTechに関する様々なジャンルをアウトプットします!!
no plan株式会社について
- no plan株式会社は 「テクノロジーの力でZEROから未来を創造する、精鋭クリエイター集団」 です。
- ブロックチェーン/AI技術をはじめとした、Webサイト開発、ネイティブアプリ開発、チーム育成、などWebサービス全般の開発から運用や教育、支援なども行っています。よくわからない、ふわふわしたノープラン状態でも大丈夫！ご一緒にプランを立てていきましょう！
- no plan株式会社について
- no plan株式会社 | web3実績
-
no plan株式会社 | ブログ一覧
エンジニアの採用も積極的に行なっていますので、興味がある方は是非ご連絡ください！ - CTOのDMはこちら