フロントエンドのレンダリング方法の歴史

フロントエンドフレームワークを勉強していく中でMPAやSPA,SSR,SSG,ISR,Server Componentなどの概念が出てくる。 この章ではフロントエンドの歴史の中でどのような課題があり、それに対してどのような解決策を出してきたのかに着目しながらこれら概念について説明する。

MPA (Multi-Page Application)

  • 時期: ウェブの黎明期から存在
  • フレームワークの例: 伝統的なサーバーサイド言語とフレームワーク (PHPのWordPress(2003),Laravel(2011)、RubyのRails(2004))
  • 動作: ユーザーがページをリクエストすると、サーバーはそのリクエストに対応する完全なHTMLページを返します。ユーザーが新しいページに移動するたびに、ブラウザは新しいHTMLをロードし、ページ全体がリフレッシュされます。
  • 解決した課題: 初期のウェブ開発では、MPAが基本形で、ウェブサイトの構造をシンプルに保ちながら、ユーザーにコンテンツを提供する能力を持っていました。SEOの最適化が容易であり、ウェブページのインデックス作成がシンプルである点も大きな利点でした。
  • 抱える課題: ユーザー体験の観点からは、ページ遷移ごとに全体がリロードされるため、レスポンス時間が長くなりがちであり、モダンなウェブアプリケーションの要求するスムーズなユーザー体験を提供するのが難しいです。また、リッチなインタラクティブ性を実現するためには追加の開発労力が必要になります。つまり、サーバーサイドはPHPやRubyで書き、フロントエンドに返すHTMLの中でJavascriptを書くのです。

SPA (Single-Page Application)

  • 時期: 2010年代初頭
  • フレームワークの例: AngularJS(2010)、React(2013)、Vue.js(2014)
  • 動作: SPAでは、最初のリクエスト時にサーバーからHTML、CSS、JavaScriptがロードされます。その後、新しいページへの遷移やデータの更新が発生すると、ブラウザはJavaScriptを用いてAPI経由でデータを取得し、ページを動的に更新します。ページのリロードは発生しません。
  • 解決した課題: SPAは、ページのリロードなしにユーザーインターフェースを動的に更新することで、ユーザー体験を大幅に向上させました。これにより、デスクトップアプリケーションに近いスムーズな操作感をウェブアプリケーションで実現することが可能になりました。また、フロントエンドとバックエンドの分離が進み、開発プロセスがモジュール化されました。
  • 抱える課題: SEO最適化が難しく、初期ロード時にJavaScriptが全てダウンロードされるため、パフォーマンスが低下する可能性があります。また、JavaScriptが無効な環境ではコンテンツが表示されない問題もあります。

SSR (Server-Side Rendering)

  • 時期: 2010年代中頃
  • フレームワークの例: Next.js(2016)、Nuxt.js(2016)
  • 動作: SSRでは、サーバーが各リクエストに対してHTMLを動的に生成し、ブラウザに送信します。これにより、ブラウザは即座にページをレンダリングできます。クライアントサイドのJavaScriptは、この後でページをさらにインタラクティブにするために使用されます。
  • 解決した課題: SSRはSPAのSEOと初期ロードパフォーマンスの問題を解決しました。サーバー側でページを予めレンダリングすることで、クローラーがコンテンツを容易に把握できるようになり、また、ユーザーに対してより迅速に初期ページを提供できるようになりました。
  • 抱える課題: サーバーの負荷が増大しやすく、キャッシュ戦略が複雑になることがあります。また、クライアントサイドとサーバーサイドの両方で同じコードを管理する必要があり、開発の複雑さが増します。

SSG (Static Site Generator)

  • 時期: 2010年代中頃
  • フレームワークの例: Jekyll(2008)、Hugo(2013)、Next.js(2020)、Nuxt.js(2020)
  • 動作: SSGでは、ビルド時にサイトの全ページが静的ファイルとして生成されます。これらのファイルはCDNを通じて配信されるため、リクエストに対するレスポンスが非常に高速です。
  • 解決した課題: SSGはパフォーマンスとセキュリティを大幅に向上させました。静的ファイルの配信は動的サイトよりも高速であり、サーバーサイドの処理が不要なため、セキュリティリスクが低減します。また、ビルド時に生成されたページはSEOにも優れています。
  • 抱える課題: 静的サイトでは、動的なコンテンツやユーザーごとのカスタマイズが難しいです。大規模なサイトではビルド時間が問題となることがあります。

ISR (Incremental Static Regeneration)

  • 時期: 2020年、Next.js 9.5で導入
  • フレームワークの例: Next.js
  • 動作: ISRは、ビルド時に静的ページを生成するSSGの概念を拡張し、サイトがデプロイされた後も特定のページを再生成することができます。これにより、サイトの一部だけを更新でき、全体のビルドを再度実行する必要がありません。
  • 解決した課題: ISRは、SSGのビルド時間の問題と、動的コンテンツの取り扱いに関する課題を解決しました。最新のコンテンツをユーザーに提供しつつ、静的サイトの高速なローディングとセキュリティの利点を保持します。
  • 抱える課題: 複雑な設定や、ページごとの再生成戦略を考慮する必要があります。また、全ページの即時更新が必要な場合には適さないことがあります。

Server Components

  • 時期: 2023/5/4、Next.js 13.4で導入(React 18のRFCで提案された機能)
  • フレームワークの例: Next.jsのみ
  • 動作: React Server Componentsは、サーバーでレンダリングされるコンポーネントとクライアントでレンダリングされるコンポーネントを混在させることができる新しい概念です。これにより、必要なJavaScriptの量を減らし、パフォーマンスを向上させることができます。
  • 解決した課題: Server Componentsは、クライアントサイドのJavaScriptの膨大な量に起因するパフォーマンス問題を解決することを目指しています。サーバーサイドでのみ必要なロジックを実行し、クライアントに送信するデータ量を最小限に抑えることができます。
  • 抱える課題: このアプローチはまだ実験的であり、完全な実装やベストプラクティスが確立されていないため、採用にあたっては注意が必要です。また、サーバーとクライアントのコードを適切に分離・管理するための新たなパターンやツールが必要になります。

一見静的なHTMLを生成する点において同じに見えるMPAとSSGの違いとHydrationの役割

MPAとSSGの主な違いは、ページの生成と配信の方法にあります。MPAは各ページをユーザーのリクエストに応じてサーバーが動的に生成し、SSGはあらかじめビルド時に全てのページを静的ファイルとして生成しておきます。Hydrationは、SSGやSSRで生成された静的なページにSPAのインタラクティブな特性を付与するために使用され、現代のウェブ開発において重要な技術の一つです。これにより、開発者は静的サイトの高速なローディングと、SPAのリッチなユーザー体験の双方を実現することができます。

Hydrationとは

  • 概念: Hydrationは、SSGやSSRで生成された静的なHTMLに対して、クライアントサイドのJavaScriptを「活性化」させるプロセスです。このプロセスを通じて、静的ページに対してSPAのような動的な挙動やインタラクティビティを追加できます。
  • 動作: サーバーから送られた静的HTMLがブラウザに読み込まれた後、JavaScriptが実行され、静的なマークアップをアプリケーションの状態を反映できる動的なものに変換します。これにより、ページに対するユーザーのインタラクションやデータのフェッチが可能になります。
  • 重要性: Hydrationは、静的サイトのパフォーマンスとセキュリティの利点を保ちつつ、ユーザー体験を向上させるSPAの利点を組み合わせることを可能にします。特に、SSGを使用してSPAを構築する場合、初回ロード時のパフォーマンス向上と、以降のページ間遷移のスムーズさを両立させるために重要です。