モード 1 – よく使用されるモード

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

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

(サーバーサイドレンダリング) React 同型性の具体的な実践については、クリックして Web パフォーマンスの最適化をご覧ください。サーバーサイドレンダリング React はまさに同形です

Tencent AlloyTeam フロントエンド er 個人ホームページ · 私の記事 ·

ホームページ

ウェブフロントエンド

htmlチュートリアル

Web パフォーマンス最適化の「単純な」理論と実践 summary_html/css_WEB-ITnose

WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWB

Jun 24, 2016 am 11:15 AM

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

モード 1 – よく使用されるモード

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

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

具体的なフローチャートは次のとおりです

この形式の処理が大部分を占めるはずですが、前後に巨大な依存関係が存在するという問題も簡単に見つかります。たとえば、データリクエストは JS のロード後にのみ開始する必要があります。ユーザーは、最終ページを表示する前にデータが戻るまで待つ必要があるため、アプリケーション全体の最初の画面のレンダリングに時間がかかります。

モード 2 – データが直接出力されます

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

以下の具体的なフローチャートは、このモードで見ることができます

このモードは、モード 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 - ダイレクトアウト (サーバーサイドレンダリング) で、主な処理は次のとおりです

はい下の図からわかるように、ページの最初の画面表示は 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 の開発により、より多くのフロントエンドがバックエンドの処理を実行し始めており、直接的なアプローチがますます注目を集めています。