ノードダイレクトの理論と実践の概要_html/css_WEB-ITnose-htmlチュートリアル-php.cn

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

モード 2 - データ送信

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

ユーザーが URL を入力すると、サーバーはページに必要なデータをリクエストする HTML を返します
データは HTML に結合され、一緒にフロントエンドに返されます (スクリプトタグを挿入してデータをグローバル変数に追加するか、< などのタグの data 属性に置くことができます) body data-serverData = '{list:[1,2 ,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 - ダイレクトアウト (サーバーサイドレンダリング) で、主な処理は次のとおりです。

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

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

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

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

概要

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

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

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

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

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

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

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

パフォーマンスデータ

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

概要

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

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

追記

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

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

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

このウェブサイトの声明

この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。