サーバー vs クライアントアーキテクチャ

サーバー vs クライアントアーキテクチャ

ウェブサイトを訪れるとき、根本的な疑問が浮かびます：ページは実際にどこで構築されるのでしょうか？サーバーがすべてを準備して完成したページを送信するのか、それともブラウザがスケルトンをダウンロードして自分でページを構築するのか？その答えは、サイトの体感速度から検索結果での表示に至るまで、すべてを形作ります。

サーバーサイドレンダリング：従来のアプローチ

従来のモデルでは、サーバーが重い処理を行います。誰かがページをリクエストするたびに、サーバーはデータベースからデータを取得し、テンプレートを実行し、完全なページをブラウザに送信して、HTMLをゼロから組み立てます。これが何十年もの間ウェブが機能してきた方法であり、今日でもサイトの大部分を支えています。

利点は明確です：検索エンジンはコンテンツが完全に形成されて到着するため、簡単に読み取ることができます。訪問者が最初に目にするものは、JavaScriptが起動するのを待つ必要がないため、すぐに読み込まれます。また、JavaScriptが無効になっている場合や非常に古いデバイスを使用している場合でもページは機能します。

しかし、トレードオフも現実に存在します。サーバーはすべてのリクエストでページを生成するため、より多くの作業を必要とします。ページ間の移動は完全な再読み込みを意味し、遅く感じられる可能性があります。また、キャッシュはより難しくなります。各ページがパーソナライズされている可能性がある場合、同じ静的ファイルをすべての人に提供することはできません。

クライアントサイドレンダリング：アプリのような体験

現代の代替手段はモデルを逆転させます。サーバーは、JavaScriptバンドルとともに、ほとんど空のHTMLファイル（単なるコンテナ）を送信します。ブラウザが引き継ぎ、データを取得して、デバイス上で完全にインターフェースを構築します。これがシングルページアプリケーションの仕組みです。

エクスペリエンスはネイティブアプリのように感じられます。初期読み込みが完了すると、ナビゲーションは瞬時に行われます。ページのリフレッシュもサーバーを待つこともありません。サーバーも静的ファイルとデータAPIを提供するだけで済むため、負荷が軽減されます。

しかし、欠点もあります。検索エンジンは歴史的にJavaScriptを多用したサイトの読み取りに苦労してきましたが、大幅に改善されています。最初の訪問は、ブラウザが意味のあるものを表示する前にすべてのJavaScriptをダウンロード、解析、実行する必要があるため、遅く感じられます。その間、訪問者は空白の画面を見つめることになります。

静的サイト生成：速度のための事前構築

両方の長所を活かせたらどうでしょうか？静的生成は、ビルドプロセス中にすべてのページを事前に構築します。結果として、CDN上に置かれた純粋なHTMLファイルができ、誰でもどこでも即座に配信できる状態になります。リクエストごとのサーバー処理も、最初の読み込み時に解析するJavaScriptバンドルもありません。

これは非常に高速で、ホスティングコストも安価です。リクエスト時にサーバーサイドコードが実行されないため、セキュリティは優れています。ただし、コンテンツが頻繁に変更されない場合、または少なくとも訪問者ごとに異なる変更がない場合にのみ機能します。1000の投稿があるブログ？完璧です。パーソナライズされたデータを表示するダッシュボード？そうはいきません。

インクリメンタル静的再生成：中間の立場

現代のフレームワークは巧妙な妥協案を導入しました。ページは静的ファイルとして始まりますが、システムに「このページが1時間以上経過した状態でリクエストされたら再生成する」と指示できます。そのしきい値を超えた最初の訪問者は、バックグラウンドでページが再構築される間、わずかに遅い応答を受け取りますが、それ以降の訪問者は更新された静的バージョンを取得します。

これにより、定期的に更新されるコンテンツ（商品ページ、コメント付きのブログ投稿、ドキュメント）に対して、サイト全体を変更のたびに再構築することなく、ほぼ静的なパフォーマンスを実現できます。

サーバーコンポーネント：新しい章

最新の進化はReactエコシステムから来ています。サーバーはHTMLや完全なJavaScriptアプリを送信する代わりに、UIの軽量な説明（一連の指示と考えてください）を送信します。ブラウザはこれを使用して、インタラクティブ性を必要としない部分の重いコンポーネントコードをダウンロードすることなくページを更新します。

つまり、データベースと直接通信したり、サーバーのファイルシステムからファイルを読み取ったりするコンポーネントを作成でき、そのコードはブラウザに送信されることはありません。結果として、JavaScriptバンドルが小さくなり、初期読み込みが高速化され、データフェッチが必要な場所で直接行われるシンプルなメンタルモデルが実現します。

自分に合ったものを選ぶ

単一の正解はありません。コンテンツの多いサイト（ブログ、ドキュメント、マーケティングページ）は、静的生成またはインクリメンタル再生成で効果を発揮します。Eコマースの商品ページは、インクリメンタル更新またはサーバーレンダリングによる新鮮さの恩恵を受けます。対話性の高いダッシュボードやツールは、多くの場合、クライアントサイドアプリとして、または新しいサーバーコンポーネントモデルを使用して最適に機能します。検索での可視性が重要なページは、サーバーレンダリングまたは静的生成に傾くべきです。リアルタイムのコラボレーションアプリには、クライアントサイドアーキテクチャが自然に処理する持続的な接続が必要です。

良いニュースは、最新のフレームワークを使用すると、自由に組み合わせられることです。ブログは静的に生成し、チェックアウトページはサーバーレンダリングし、ダッシュボードはクライアントサイドアプリとして構築する——すべて同じプロジェクト内で。アーキテクチャはコンテンツに奉仕するものであり、その逆ではありません。