Webアプリのクライアント側とサーバー側と事前レンダリング

最近、フロントエンドコミュニティ内で何かが起こっています。 Reactとその組み込みのサーバー側ハイドレーション機能のおかげで、サーバー側のレンダリングはますます勢いを増しています。 しかし、ファーストバイトまでの時間（TTFB）スコアが非常に速いユーザーに高速なエクスペリエンスを提供するソリューションはこれだけではありません。事前レンダリングも非常に優れた戦略です。 これらのソリューションと完全にクライアントがレンダリングしたアプリケーションの違いは何ですか？

クライアントがレンダリングしたアプリケーション

Angular、Ember.js、Backboneなどのフレームワークが存在するため、フロントエンド開発者はすべてをクライアント側でレンダリングする傾向があります。 GoogleとJavaScriptを「読み取る」機能のおかげで、JavaScriptは非常にうまく機能し、SEOにも対応しています。

クライアント側のレンダリングソリューションでは、リクエストを単一のHTMLファイルにリダイレクトすると、すべてのJavaScriptを取得し、コンテンツをレンダリングする前にブラウザにすべてをコンパイルさせるまで、サーバーはコンテンツなしで（またはロード画面を使用して）リクエストを配信します。

良好で信頼性の高いインターネット接続の下では、それはかなり高速でうまく機能します。 しかし、それははるかに優れている可能性があり、そのようにするのは難しいことではありません。 これが次のセクションで説明します。

サーバー側レンダリング（SSR）

SSRソリューションは、何年も前に私たちがよく行っていたものですが、クライアント側のレンダリングソリューションを支持することを忘れがちです。

古いサーバー側のレンダリングソリューションを使用して、たとえばPHPを使用してWebページを構築しました。サーバーはすべてをコンパイルし、データを含め、完全に入力されたHTMLページをクライアントに配信しました。 それは速くて効果的でした。

しかし…別のルートに移動するたびに、サーバーはすべての作業をやり直す必要がありました。PHPファイルを取得してコンパイルし、HTMLを配信します。すべてのCSSとJSは、ページの読み込みを数百ミリ秒またはまるまる秒ですら。

SSRソリューションで最初のページの読み込みを実行し、次にフレームワークを使用してAJAXで動的ルーティングを実行し、必要なデータのみをフェッチできるとしたらどうでしょうか。

これが、Reactがこの問題を使いやすいソリューションであるRenderToStringメソッドで普及させたため、SSRがコミュニティ内でますます注目を集めている理由です。

この新しい種類のWebアプリケーションは、ユニバーサルアプリまたは同形アプリと呼ばれます。 これらの用語の正確な意味とそれらの間の関係についてはまだいくつかの論争がありますが、多くの人々はそれらを同じ意味で使用しています。

とにかく、このソリューションの利点は、同じコードでサーバー側とクライアント側のアプリを開発し、カスタムデータを使用してユーザーに非常に高速なエクスペリエンスを提供できることです。 欠点は、サーバーを実行する必要があることです。

SSRは、サーバーの信頼性の高いインターネット接続を利用して、データをフェッチし、カスタムコンテンツをページに事前入力するために使用されます。 つまり、サーバー自体のインターネット接続は、嘘つきのユーザーのインターネット接続よりも優れているため、データをユーザーに配信する前に、データをプリフェッチして統合することができます。

事前に入力されたデータを使用して、SSRアプリを使用すると、クライアントがレンダリングしたアプリがソーシャル共有とOpenGraphシステムで抱える問題を修正することもできます。 たとえば、クライアントに配信するindex.htmlファイルが1つしかない場合、それらには1つのタイプのメタデータ（ほとんどの場合、ホームページのメタデータ）しかありません。 別のルートを共有したい場合、これはコンテキスト化されないため、ユーザーが世界と共有したい適切なユーザーコンテンツ（説明とプレビュー画像）を使用して、他のサイトにルートが表示されることはありません。

事前レンダリング

ユニバーサルアプリの必須サーバーは、一部の人にとっては抑止力になる可能性があり、小さなアプリケーションにとってはやり過ぎかもしれません。 これが、事前レンダリングが本当に優れた代替手段になる理由です。

Preactと独自のCLIを使用してこのソリューションを発見しました。これにより、事前に選択されたすべてのルートをコンパイルして、完全に入力されたHTMLファイルを静的サーバーに保存できます。 これにより、Node.jsを必要とせずに、Preact / Reactハイドレーション機能のおかげで、ユーザーに超高速のエクスペリエンスを提供できます。

問題は、これはSSRではないため、現時点で表示するユーザー固有のデータがないことです。これは、最初のリクエストでそのまま送信される静的な（そしてある程度一般的な）ファイルです。 したがって、ユーザー固有のデータがある場合は、美しく設計されたスケルトンを統合して、ユーザーのデータが来ていることをユーザーに示し、ユーザーの不満を避けることができます。

別の落とし穴があります。この手法を機能させるには、ユーザーを適切なファイルにリダイレクトするためのプロキシなどが必要です。

なんで？

シングルページアプリケーションでは、すべてのリクエストをルートファイルにリダイレクトする必要があります。その後、フレームワークは組み込みのルーティングシステムを使用してユーザーをリダイレクトします。 したがって、最初のページのロードは常に同じルートファイルです。

事前レンダリングソリューションが機能するためには、一部のルートには特定のファイルが必要であり、必ずしもルートindex.htmlファイルであるとは限らないことをプロキシに通知する必要があります。

たとえば、4つのルート（ / 、 /about 、 /jobs 、およびblog ）があり、それらすべてのレイアウトが異なるとします。 スケルトンをユーザーに配信するには、4つの異なるHTMLファイルが必要です。これにより、React / Preact/etcが実行されます。 データで水分補給します。 したがって、これらすべてのルートをルートindex.htmlファイルにリダイレクトすると、ページの読み込み中に不快なグリッチ感が生じ、読み込みが完了してレイアウトが置き換えられるまで、ユーザーは間違ったページのスケルトンを見ることになります。 たとえば、Pinterestのようなギャラリーで別のページを要求したときに、列が1つしかないホームページスケルトンが表示される場合があります。

解決策は、これら4つのルートのそれぞれに特定のファイルが必要であることをプロキシに通知することです。

• https://my-website.com //my-website.com→ルートindex.htmlファイルにリダイレクトします
• https://my-website.com/aboutファイルに/about/index.html
• https://my-website.com/jobsファイルに/jobs/index.html
• https://my-website.com/blogファイルに/blog/index.html

これが、このソリューションが小さなアプリケーションに役立つ理由です。数百ページあるとしたら、どれほど苦痛になるかがわかります。

厳密に言えば、この方法で行う必要はありません。静的ファイルを直接使用することもできます。 たとえば、 https://my-website.com/about/ //my-website.com/about/は、ディレクトリ内のindex.htmlを自動的に検索するため、リダイレクトなしで機能します。 ただし、パラメータURLがある場合は、このプロキシが必要ですprofile/guillaume/index.htmlであるため、 https://my-website.com/profile/guillaume //my-website.com/profile/guillaumeは独自のレイアウトでリクエストを/profile/index.htmlにリダイレクトする必要があります。存在せず、404エラーをトリガーします。

つまり、上記のレンダリング戦略には3つの基本的なビューがあります。ロード画面、スケルトン、そして最終的にレンダリングされた後のページ全体です。

戦略によっては、これら3つのビューすべてを使用する場合もあれば、完全にレンダリングされたページに直接ジャンプする場合もあります。 1つのユースケースでのみ、別のアプローチを使用する必要があります。

クライアントのみのレンダリングでは不十分なことがよくあります

クライアントがレンダリングするアプリケーションは、ユーザーにとってより良い結果が得られるため、今は避けるべきものです。 そして、この場合、より良い結果を出すことは、事前レンダリングソリューションと同じくらい簡単です。 これは間違いなくクライアントのみのレンダリングよりも改善されており、完全にサーバー側でレンダリングされたアプリケーションよりも実装が簡単です。

SSR /ユニバーサルアプリケーションは、多くの異なるページを持つ大規模なアプリケーションがある場合、非常に強力になる可能性があります。 ソーシャルクローラーと話すときに、コンテンツに焦点を合わせて関連性を持たせることができます。 これは検索エンジンロボットにも当てはまります。検索エンジンロボットは、サイトのランク付け時にサイトのパフォーマンスを考慮に入れるようになりました。

フォローアップチュートリアルにご期待ください。ここでは、SPAの事前レンダリングバージョンとSSRバージョンへの変換について説明し、それらのパフォーマンスを比較します。