古代のウェブサイト:
- ユーザーが bar または href を介して URL に移動すると、その特定のページに対してサーバー呼び出しが行われます
- ページが返されます (静的 html または ASP.NET MVC によってサーバー上でレンダリングされた html など)。
- すべてのページがすべてをリロードし、遅いため、SPA に行く理由
Angular 2 SPA:
- ユーザーはバーまたはルーター経由で URL に移動します
- コンポーネントの html/javascript に対してサーバー呼び出しが行われます。
- navbarなどではなく、ルーターアウトレット内のもののみがロードされます（SPAの主な利点）
- ただし、html は実際にはサーバーからそのまま受信されるわけではありません。Angular 2 コード/マークアップは、ブラウザが理解できるプレーンな HTML として表示される前にクライアントで処理されます。遅いですか? Angular Universal に入りますか?
角度ユニバーサル:
アプリケーションを初めて使用するユーザーは、サーバーでレンダリングされたビューを即座に見ることができ、知覚されるパフォーマンスと全体的なユーザー エクスペリエンスが大幅に向上します。
つまり、要するに：
- ユーザーは検索バーまたはルーターを介して URL に移動します
- Angular コンポーネントを返す代わりに、Angular Universal は実際にそれらのコンポーネントを html に変換し、クライアントに送信します。これが唯一の利点です。
TLDR:
- Angular Universal が正しいことを理解しているでしょうか? （上記の最後の箇条書き）。
- そして最も重要なことは、私がそれが何をするかを理解していると仮定すると、どのようにこれを達成するのでしょうか? 私の理解では、IISまたは何でも要求されたリソースを返すだけなので、Angular Universalはそれらをどのように前処理しますか(編集:基本的に、処理されたhtmlを返すAPIに似たものを実行します)?
- これは、サーバーが最初のビューを表示するために必要なすべての最初の API 呼び出しを行うことを意味します。たとえば、ルート解決から...正しいですか?
編集：質問を絞り込むために、このアプローチに焦点を当てましょう：
2 つ目の方法は、リクエストごとに Web サーバーでアプリケーションを動的に再レンダリングすることです。スケーラビリティとパフォーマンスを向上させるために、このアプローチで使用できるいくつかのキャッシング オプションがまだありますが、リクエストごとに Angular Universal のコンテキスト内でアプリケーション コードを実行することになります。
ここでのアプローチ：
最初のオプションは、アプリケーションを事前にレンダリングすることです。つまり、ユニバーサル ビルド ツール (gulp、grunt、broccoli、webpack など) のいずれかを使用して、ビルド時にすべてのルートの静的 HTML を生成します。次に、その静的 HTML を CDN にデプロイできます。
私を超えています。大量の動的コンテンツがあることを確認しながら、静的 html をプリロードします。