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

llcタイプsまたはc

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

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

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

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

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

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

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

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

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

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

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

イオン2対イオン1

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

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つしかないホームページスケルトンが表示される場合があります。

代わりに本番のwsgiサーバーを使用してください

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

• https://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/ index.htmlを自動的に検索するため、リダイレクトなしで機能しますそのディレクトリ内。ただし、パラメータURLがある場合は、このプロキシが必要です— https://my-website.com/profile/guillaumeリクエストを/profile/index.htmlにリダイレクトする必要がありますprofile/guillaume/index.htmlのため、独自のレイアウトで存在せず、404エラーをトリガーします。

---

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

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

方法	着陸（例：/）	静的（例：/about）	固定動的（例：/news）	パラメータ化された動的（例：/users/:user-id）
クライアントレンダリング	読み込み中→フル	読み込み中→フル	読み込み中→スケルトン→フル	読み込み中→スケルトン→フル
事前レンダリング	フル	フル	スケルトン→フル	HTTP 404（ページが見つかりません）
プロキシで事前レンダリング	フル	フル	スケルトン→フル	スケルトン→フル
SSR	フル	フル	フル	フル

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

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

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

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

関連： 人気のある静的サイトジェネレーターの概要

基本を理解する

クライアントサイドレンダリングとは何ですか？

クライアント側のレンダリングにより、開発者はWebサイトをJavaScriptを使用してブラウザーで完全にレンダリングできます。ルートごとに異なるHTMLページを使用する代わりに、クライアント側でレンダリングされたWebサイトは、ブラウザーで直接各ルートを動的に作成します。このアプローチは、JSフレームワークによって簡単に利用できるようになると普及しました。

サーバー側のレンダリングとは何ですか？

サーバー側のレンダリングにより、開発者はWebページにカスタムユーザーデータをサーバー上に直接事前入力できます。一般に、サーバー内ですべてのリクエストを行う方が、ブラウザからサーバーへの追加のラウンドトリップを行うよりも高速です。これは、開発者がクライアント側のレンダリングの前に行っていたことです。

クライアント側とサーバー側のレンダリングの違いは何ですか？

クライアント側のレンダリングは、ユーザーが別のルートを要求するたびにページを更新することなく、ルーティングを動的に管理します。ただし、サーバー側のレンダリングでは、Webサイトの任意のルートの最初のロードで完全に入力されたページを表示できますが、クライアント側のレンダリングでは最初に空白のページが表示されます。

事前レンダリングとは何ですか？

事前レンダリングは、クライアント側とサーバー側のレンダリングの間のトレードオフです。データがAJAX / XHRリクエストで再水和されるのを待つ間、事前にレンダリングされたすべてのページにスケルトンテンプレートが表示されます。ページがフェッチされると、クライアント側でレンダリングされたWebサイトを利用するために、内部ルーティングが動的に実行されます。

最高のrtl-sdrソフトウェア

ユニバーサルアプリとは何ですか？

ユニバーサルアプリは、データが入力されたページをブラウザに送信します。次に、アプリはJavaScriptをロードし、ページを再水和して、完全にクライアント側でレンダリングされたアプリを取得します。このアプローチは、今日利用可能な最新の技術の利点を組み合わせたものです。