何がまっすぐですか？それはどのようなパフォーマンスの最適化ですか？この記事では、ブラウザにURLを入力してから最終ページを表示するまでのプロセスを段階的に分析し、モバイルQQWebでの実際のアプリケーションの実践を要約します。
モード1-コモンモード
ユーザーによるURLの入力から最終ページの表示まで、このモデルは次の5つの部分に簡単に分けることができます。
-
ユーザーがURLを入力し、静的ページのプルを開始します
-
静的ページがロードされたら、ドキュメントタグを解析し、CSSのプルを開始します（通常、CSSはヘッドに配置されます）
-
次に、JSファイルをプルします（通常、JSファイルは最後に配置されます）
-
JSがロードされると、JSコンテンツの実行が開始され、要求が行われ、データが取得されます。
- データとリソースをページにレンダリングして、最終的な表示効果を取得します
具体的なフローチャートは以下のとおりです。
この形式の処理が大部分を占めるはずですが、リクエストの数が多く、前後の依存関係が大きいという問題は簡単にわかります。たとえば、JSをロードして実行するときにデータリクエストを開始する必要があり、ユーザーはデータが返されるのを待った後に最終ページを表示できます。この強い依存関係により、アプリケーション全体の最初の画面のレンダリング時間がはるかに長くなります。
モード2-データをまっすぐに
モード1では、ポイント1でユーザーがURLを入力すると、サーバーは他の処理を行わずに直接htmlを返し、ポイント4でサーバーにデータを要求します。次に、サーバーから取得するように要求されます。要求されたデータが最初のポイントでサーバーに配置され、取得されたデータがHTMLにスプライスされて返される場合、フロントエンドページでのデータ要求時間を短縮できます。これはモード2です。データの処理は簡単で、処理方法は非常に簡単です。
-
サーバーがHTMLを返す前に、ユーザーはURLを入力し、ページに必要なデータを要求します
-
データをHTMLに接続し、一緒にフロントエンドに返します（スクリプトタグを挿入してデータをグローバル変数に追加するか、<body data-serverData = '{list：[1,2などのタグのデータ属性に配置できます。 、3]} '>）
- フロントエンドJSコードで、データがサーバー側で取得されたかどうかを判断し、データを直接取得してページをレンダリングし、データ要求を行わないようにします
このモードでは、以下のフローチャートで確認できます。
モード1と比較して、このモードは、データを要求するための2つのモード間の時間のかかるギャップを減らします。このギャップはいくらですか？
HTTPネットワーク要求プロセスを開始します
DNS解析（100~200ms可以缓存）
|
|
建立TCP链接 (三次握手100~200ms )
|
|
HTTP Request( 半个RTT )
|
|
HTTP Response( RTT 不确定优化空间 )
注：RTTはRound-trip timeの略で、データパケットが送信されて返されるまでにかかる時間を意味します。
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取得時間が最適化されます。
概要
Straight-outは、コモンモードを1つのHTMLリクエストに最適化し、最初の画面のレンダリング時間を短縮し、サーバー側のレンダリングを使用し、フロントエンドレンダリングでは克服が難しいSEOの問題を最適化できます。単純なデータ出力であろうとサーバー側レンダリングであろうと、ページのパフォーマンスの最適化を大幅に向上させることができます。実際のアプリケーションから以下に説明します。
例として、モバイルQQホームスクールグループの直接データ最適化を取り上げます。
プロジェクトの立ち上げ時間が厳しいため、最初の最適化では、最初の画面レンダリング時間を最適化するために、直接データ出力の簡単な方法が使用されました。具体的な処理は、モード2のデータ直接出力方式と同じですが、フロントエンドとサーバーの中間層として、AlloyTeamが開発したKOAベースのXuanwu直接出力サービスを使用している点が異なります。フォームは次のとおりです
この中間層の方法を使用すると、プロジェクト開発プロセスでフロントエンドとバックエンドの分離方法を引き続き使用でき、開発が完了した後、ページ要求はこの中間層のサービスに送信されます。中間層サービスは、主に上記のモード2データのストレート処理を実行します
-
フロントエンドファイルを使用して、サーバーによって準備されたデータプルインターフェイスを呼び出します
- データをフロントエンドファイルと組み合わせて、リクエストソースに返します
中間層サービスと特定のサーバーは同じイントラネットにデプロイされているため、モード2-データダイレクトアウトで説明されている最適化を実現するために、それらの直接データインタラクションは非常に効率的です。
一方、同社のL5ロードバランシングサービスによる中間層のXuanwuダイレクトアウトサービスとして、ダイレクトアウトバージョンと非ダイレクトアウトバージョンと完全に互換性があります。つまり、ダイレクトアウトサービスが切断された場合、非ダイレクトアウトバージョンもスムーズに使用して基本ユーザーを確保できます。経験はまたA / BTestをよりよくサポートすることができます。
パフォーマンスデータ
シンプルなデータ方式もパフォーマンスの大幅な向上をもたらしました。事前に最適化されたバージョンと比較して、モバイルQQホームスクールグループリストページの最適化は約650ミリ秒で、約650ミリ秒増加しています。 35％のパフォーマンス。
総括する
フロントエンドとバックエンドが分離されていない場合、バックエンドを使用してテンプレートをレンダリングする方法は、記事で説明されているストレートアウトソリューションの効果と一致します。フロントエンドとバックエンドが分離された後、このアイデアは軽視されます。ノードの開発により、より多くのフロントエンドがバックエンドの実行を開始できるようになります。物事、まっすぐなアプローチもますます注目されています。
歴史の輪は前進しており、真っ直ぐな計画はサーバー側のレンダリングの元のポイントに戻ったように見えますが、実際には以前に基づいて上向きにスパイラルしています。より多くの能力があれば、より多くの思考を持つことができます。フロントエンドがますます強力になることを楽しみにしています、いいえ、リアクションネイティブでもフロントエンドがクライアントで動作し始めるようにします〜
追記
モバイルQファミリースクールグループは、React + Redux + Webpackアーキテクチャを使用しています。Reactであるため、React同形性（サーバー側レンダリング）を無視してはなりません。React同形性の具体的な実践については、別の記事で直接要約します。クリックして、Webパフォーマンス最適化サーバー側レンダリングを直接表示します（https://github.com/joeyguo/blog/issues/9）
記事の冒頭で述べたフロントエンドルーティングの場合、ルーティングの実装原則に関心のある人は、クリックしてフロントエンドルーティングの実装とreact-routerソースコード分析を表示することもできます。