ノードダイレクトの理論と実践の概要_html/css_WEB-ITnose

元のアドレス

ズバリとは何ですか？どのようなパフォーマンスの最適化ですか?この記事では、ブラウザに URL を入力してから最終ページが表示されるまでのプロセスを段階的に分析し、Mobile Q Web での実際のアプリケーションの実践をまとめます。

モード 1 - 共通モード

ユーザーが URL を入力してから最終ページが表示されるまでのプロセスは、簡単に次の 5 つの部分に分けることができます

1. ユーザー入力 URL、静的ページのプルを開始します
2. 静的ページがロードされた後、ドキュメント タグを解析し、CSS のプルを開始します (通常、CSS は head に配置されます)
3. その後、プルしますJS ファイル (通常は最後に JS ファイル)
4. JS がロードされたら、JS コンテンツの実行を開始し、リクエストを行ってデータを取得します
5. データとリソースをページにレンダリングします最終的な表示効果を得るまで

具体的なフローチャートは以下の通りです

この形式の処理が大部分を占めるはずですが、これも簡単です。問題を見つけるには: 多くのリクエストと大きな依存関係があります 実行する前に JS がロードされるまで待機する必要がある場合、データ リクエストが開始され、ユーザーはデータが返されるのを待つことになります。この強い依存関係により、アプリケーション全体の最初の画面のレンダリング時間が長くなります。

モード 2 - データ送信

モード 1 では、ユーザーがポイント 1 で URL を入力すると、サーバーは他の処理を行わずに直接 HTML を返し、ポイント 4 でデータをリクエストします。サーバー。次に、ポイント 1 でリクエスト データをサーバーに配置し、取得したデータを HTML に結合して返すと、フロントエンド ページでのデータ リクエスト時間が計算されます。減りました。 これがモード 2 - データ直接出力の動作であり、処理方法も非常に簡単です

1. ユーザーが URL を入力すると、サーバーはページに必要なデータをリクエストする HTML を返します
2. データは HTML に結合され、一緒にフロントエンドに返されます (スクリプト タグを挿入してデータをグローバル変数に追加するか、3f59220063710ee874d08a8571025658)
3. フロントエンドのJSコード内で、サーバー側でデータが取得できたかどうかを判断し、直接使用します。データ要求を行わずにページをレンダリングするためのデータ

以下の特定のフローチャートは、このモードでは次のことを示しています

モード 1 と比較して、このモードではデータを要求する際の 2 つのモードの時間の違い。このギャップはどのくらいの大きさですか?

HTTP ネットワーク要求プロセスを開始します

DNS解析（100~200ms可以缓存）         |         |        建立TCP链接 (三次握手100~200ms )                |                |            HTTP Request( 半个RTT )                    |                   |              HTTP Response( RTT 不确定优化空间 )

注: RTT はラウンドトリップ時間の略で、データ パケットが送り返されるまでにかかる時間を表します。

HTTP リクエストはフロントエンドとバックエンドで発行されます。その違いは何ですか?

上記の HTTP ネットワーク リクエスト プロセスから、完全なリクエスト リターンの確立には、ネットワークやその他の要因の影響により、特に外部ネットワーク ユーザーが HTTP リクエストを行う場合に明らかに時間がかかることがわかります。そして送信にはかなりの時間がかかります。サーバー側でデータを取得する場合、それが HTTP リクエストであっても、バックエンドは同じイントラネット上にあるため、送信は非常に効率的です。これがギャップの主な原因であり、最適化が急務です。

モード 3 - ダイレクトアウト (サーバー側レンダリング)

モード 2 は、ロードされる JS ファイルに依存するデータリクエストをサーバーに移動し、データは HTML とともに返されます。 。次に、JS ファイルがロードされるのを待ちます。JS はサーバーから提供されたデータを HTML と組み合わせて、最終的なページ ドキュメントを生成します。

データリクエストはサーバー上で行うことができ、データと HTML の組み合わせ処理もサーバー上で実行できるため、JS ファイルの読み込みの待ち時間が短縮されます。 これはモード 3 - ダイレクトアウト (サーバーサイドレンダリング) で、主な処理は次のとおりです。

1. サーバー上のデータを取得し、そのデータをページテンプレートと組み合わせて、最終的な HTML にレンダリングします。サーバー側
2. 最終的な HTML 表示に戻ります

下の図からわかるように、ページの最初の画面表示は JS ファイルを待つ必要がなくなりました

上記のモードを通じて、モード 1 - コモン モードの時間のかかるポイント 3 と 4 が最適化されました。続行できますか。最適化するには？

ページのドキュメントが大きくない場合、CSS を HTML にインライン化することでリクエスト量を最適化できます。考慮すべき少し異なる点は、サーバーによって最終的にレンダリングされるドキュメントのサイズです。この範囲内で、CSS ファイルを HTML にインライン化することもできます。この場合、以下に示すように CSS の取得時間が最適化されます

概要

HTML リクエストが 1 つだけになるまで、一般的なパターンをズバリ最適化できます。最初の画面のレンダリング時間を短縮し、サーバーサイド レンダリングを使用すると、フロントエンド レンダリングでは克服するのが難しい SEO の問題を最適化することもできます。単純なデータの直接出力であっても、サーバー側のレンダリングによる直接出力であっても、ページのパフォーマンスの最適化を大幅に改善できることを実際のアプリケーションで説明します。

モバイル QQ ホームスクール グループのデータ直接エクスポートの最適化を例に挙げます

プロジェクトの開始までの時間制限が厳しいため、最初の最適化ではデータ直接エクスポートの簡単な方法を使用して最適化しました。最初の画面のレンダリング時間。具体的な処理はモード 2 のデータ直接エクスポート方式と一致していますが、AlloyTeam が開発した KOA に基づく Xuanwu 直接エクスポート サービスがフロントエンドとサーバー間の中間層として使用される点が異なります。形式は次のとおりです。

この中間層手法を使用すると、開発完了後も、フロントエンドとバックエンドの分離手法をプロジェクトの開発プロセス中に使用できます。 、ページリクエストはこの中間層サービスに送られます。中間層サービスは主に上記のモード 2 - データ直接エクスポートでの処理を実行します

1. フロントエンド ファイルを使用し、サーバーが用意したプル データ インターフェイスを呼び出します
2. 結合フロントエンドファイルとのデータを結合してリクエスト元に返す

中間層サービスは特定のサーバーと同じイントラネット上にデプロイされているため、それらの直接のデータ対話は非常に効率的ですこれにより、モード 2 - データ ダイレクト アウトで説明されている最適化が達成されます。

もう 1 つの点は、中間層の Xuanwu 直接送信サービスは、同社の L5 負荷分散サービスを使用しているため、直接送信バージョンと非直接送信バージョンと完全に互換性があり、たとえ直接送信サービスが失敗したとしても、引き続き可能です。これにより、基本的なユーザー エクスペリエンスが確保され、A/BTest のサポートが向上します。

パフォーマンス データ

モバイル Q 家庭科グループ リスト ページの最初の画面レンダリング完了時間も、以前と比べて大幅に向上しました。最適化前のバージョンでは、データ出力が約 650 ミリ秒最適化され、パフォーマンスが約 35% 向上しました。

概要

フロントエンドとバックエンドが分離されていない場合にバックエンドを使用してテンプレートをレンダリングする方法は、ダイレクトアウトと一致します。この記事で説明されているソリューションは、フロントエンドとバックエンドを分離するものでしたが、Node の開発により、より多くのフロントエンドがバックエンドの処理を開始できるようになり、直接的なアプローチがますます重視されるようになりました。

歴史の車輪は前進しており、直接的な解決策はサーバーサイド レンダリングの原点に戻ったように見えますが、実際には以前の解決策に基づいて上向きに上昇しています。能力が高まると、思考力も高まります。フロントエンドはますます強力になることが予想されます。いいえ、react-native ではフロントエンドがクライアント上で動作し始めることもできます。

追記

モバイル Q ホーム。 -school グループは React + Redux + Webpack アーキテクチャを使用しています。React なので、React 同型性 (サーバーサイド レンダリング) を無視してはなりません。 React 同型性の具体的な実践については、別の記事にまとめましたので、クリックすると、Web パフォーマンスの最適化 サーバー側レンダリング React 同型性をそのまま表示できます

記事の冒頭で述べたフロントエンド ルーティングについては、ルーティングの実装原理に興味がある人は、クリックして表示することもできます。フロントエンドルーティングの実装と反応ルーターのソースコード分析を表示

アドバイスありがとうございます!