[フロントエンドチュートリアル]フロントエンドパフォーマンス最適化実践のBaiduアプリ個人ホームページ最適化

著者：フロントエンドエンジニアpanming

序文

パフォーマンスは、すべてのフロントエンドエンジニアが注意を払う必要があるトピックです。一般的な最適化方法については多くの記事や実践があるので、ここでは詳しく説明しません。この記事では、Baidu Appパーソナルホームページを例として使用して、ビジネス特性のパフォーマンス最適化プラクティスについて説明します。

適用対象：パッケージ化とアンパック、HTTPリクエストの数と数の削減、CDNとオンデマンドロードなど、従来のすべての最適化方法を使用できますが、パフォーマンスは依然として理想的ではありません。

指標の定義、レポートの作成

優れた計画を立てるには、まずそれをサポートする正確なデータが必要です。

一般に、フロントエンドのパフォーマンス指標としては、DOM READY、まずContentfulペイント、**黒と白、倍、用户可操作时间、onload时间等，**トラフィック自体の実際の特性が定義される一般的な使用インジケータの定義を必要とし、現在のサービスのユーザーを反映していません実際の経験。

個人のホームページは、Baidu Appクライアントのウェブページです。ハイブリッドバージョンを開くには（ファイルプロトコルを使用してローカルのHTMLとJS、CSSを直接読み込む）、ウェブバージョン（ウェブのURLを開く）には2つの方法があります。

まず、個人ホームページのページの構造を理解しましょう。

ヘッドエリアは現在の作者の個人情報を示し、タブエリアは作者が作成したコンテンツです。ページ上のすべてのデータは非同期で取得されます。

個人ホームページを開くプロセスは、次のように簡略化できます。

時間の消費は、終了時間、ネットワークとサーバーの時間、フロントエンドのレンダリング時間の3つの部分に分けることができます。

上記のプロセスに従って、指標を定義する原則を策定しました。

ホームページに表示されるユーザーデータは、ページ内のJSリクエストデータの後の非同期レンダリングです。したがって、最初の画面は次のように定義されます。ヘッド領域とタブリストの最初の画面データのレンダリングが完了します（ユーザーは実際に表示されます。つまり、ユーザーは時間を操作できます）。
ホームされsan構築されSPA、ページのDOMの同期とページの読み込み状態として表示され、最初の画面のユーザーデータに復帰する前に、実際のコンテンツをHTMLに表示されません。したがって、白い画面の定義は次のとおりです。ページDOMにマウントされたコンテンツ（ユーザーが最初にページが空白ではなくなったことを確認したとき）
最後に、異なるタイミングiOSとAndroidがイベントトリガONLOADので、iOSのリソース負荷のiOSのホーム・ページを使用して調整されているので、ページのレンダリングをブロックすることができrAFiOSが最初の画面にJSが起動時にonloadイベントトリガー、およびAndroidのさ必要な画像、jsonp、およびその他のリソースはすべて、ロードの完了後にトリガーされるため、このインジケーターは主に補助機能として使用されます。

レポート作成のプロセスでは、ホームページのビジネスフォーム（AndroidとiOSのデュアルエンドハイブリッドバージョンとWebバージョンの両方）とインジケーター定義の意味を組み合わせて、プロセス全体の段階を次のようにできるだけ詳しく説明します。

ホームページの3つのバージョン（ハイブリッドバージョン、ハイブリッドWebバージョン、Webバージョン）をグループ化します。データの干渉を回避でき、オンライン時間を制御することで実験を比較できます
さまざまな使用条件によって引き起こされるデータの違いを排除するために、スクリーニングの条件として、システムの両端、開始点、および開始点を追加します。これにより、範囲を絞り込み、分析を見つけるのに役立ちます
ホームページの実行プロセスによると、時間のかかるプロセスは、問題をさらに特定するために細分されます。ステージ全体は、最後に時間がかかります（ページヘッダーの上部をクリックしてから）、HTMLのJS参照ステージの同期に時間がかかり、データを消費します。、ページの内部機能、および各コンポーネントの最初の画面への時間のかかる時間（時間のかかる部分は、実際の最適化分析で徐々に調整されます）

最後に、各ステージの詳細な区分を取得します。

追加のメモ：

エンドツーエンドのRBIは、ユーザーが操作を実行した瞬間から、クライアント時間、ネットワーク時間、サーバー時間、ユーザーがクリック操作を開始してからページが完全に表示されるまでのフロントエンド消費をカバーするデータを記録します時間管理の完全なプロセス。
その中でも、開始タイムスタンプは、ユーザーが操作したときに前のページによって記録され、透過的に個人のホームページに送信されます。
フロントエンドは、ネットワーク要求が開始されるたびに現在のタイムスタンプを記録し、インターフェースの戻り値がバックエンド処理インターフェースに返されます現時点では、この2つの違いは時間のかかるHTTP接続です。
今回は、フロントエンドコンピューティングレポートとプラットフォーム表示ソリューションが採用され、フロントエンド制御は柔軟で反復的です。
最後の時間のかかる部分は、前のページのクリックから解決ページの上部までの合計時間しか計算できません。

データ分析、最適化の方向性を提案

最初の段階の後、安定したデータとページを取得し、ソリューションを分析して提案するには時間がかかります。

性能データは、図に見られる主要な段階を処理し：終了時間がかかり、メインprofile.js JS開始時間がかかるの内部に導入され、時間のかかる第1のスクリーンインタフェース、ページ時間のかかる処理と描画データ、時間のかかる一次段階のために、サブ最適化以下の側面について：

以下のための終了時間のかかる最適化ポイントのフロントエンドの外観と、
のための最初の画面インターフェース時間のかかるインターフェース最適化フロントエンドジョイントサーバ
用JS内部時間がかかり、自分のフロントエンド・コードの最適化

最適化を開始し、徐々に改善する

ホームページへの入り口はたくさんありますが、それらはさまざまな入り口条件や歴史的遺産に対応する必要があります。個人のホームページビジネスの基本的な状況は次のとおりです。

ページはSPAモードですが、ビジネスは複雑で、合計コードサイズは大きいです
ハイブリッドバージョンの最初の画面に必要なリソースは2つのインターフェースによって返され、2つのインターフェースは依存しており、フロントエンドでシリアルに実行されます
Webバージョン上部のユーザーデータは同期データを使用し、タブインターフェイスはハイブリッドと同じものに依存します
ハイブリッドバージョンの機能：
ハイブリッドバージョンとWebバージョンは異なる方法でコンパイルされた同じコードセットを使用しますが、Webバージョンの最初のインターフェイスは同步的、データがHTMLテンプレートで返され、ハイブリッド内のすべてのインターフェイスが非同期であることです
より多くのシーンを使用する
ファイルプロトコルを使用してHTMLテンプレートを読み込み、jsonpを使用してバックエンドデータインターフェースをリクエストする

フロントエンドコード、エンジニアリング、サーバー、クライアントのネイティブフレームワークの4つの方向に従って、最適化計画が個別に作成されます。主に、フロントエンドの制御可能なコードとエンジニアリングの2つの側面を紹介します。

フロントエンドコード

事前にiOSのオンロードをトリガーする

方法：rAF 嵌套 setTimeout事前のトリガーは、ページの表示をロードするためのリソースをブロックする状況のiOSに対処するために、イベントをonloadイベント
利点：ユーザーに表示される最初のスクリーン時間は負荷によってブロックされません

最初の画面への依存を減らす

最初の画面時間は、ユーザーのページ速度に対する認識を反映している可能性があります。最初の画面に依存する操作が多いほど、ユーザーは待機する時間が長くなります。そのため、パフォーマンスの最適化では、最初の画面の前に実行する操作と最初の画面の後で重要でない操作の一部を減らす必要があります。これにより、ユーザーエクスペリエンスをある程度向上させることができます。

一定期間のデータ収集分析とコードレビューの結果、いくつかの改善が見つかりました。

最初の画面の前のロジックでは、JSが一部のデータを初期化したときに、ネイティブ提供の複数のメソッド（終了機能）を一度に呼び出したため、終了機能の実行に時間がかかり、理論値をはるかに超える80分位値が発生しました。
SPAページの最も外側のコンポーネントAppは、最初のインターフェースのデータが返された後にマウントされます。ページのWebバージョンの場合、最初のインターフェイスは同期されているため、インターフェイスがほとんど影響を与えずにアプリがマウントされますが、使用シナリオが多いハイブリッドバージョンの場合、ページの最初の画面には少なくとも2つのインターフェイスとすべてのインターフェイスが必要ですリクエストはすべて非同期であり、最初のインターフェースが戻る前に多くのページを処理するために必要なロジックで十分であり、アプリのマウントのタイミングは非常に不適切です。
ページには多くのドットが埋め込まれています。PVを除いて、ページ上のほとんどのウィジェットはドットで表示されています。最初の画面が最初の画面の画像の読み込み時間を圧迫する前に、ドットリクエストが頻繁に送信されます。

上記の結果に基づいて、コードは次のように調整されました。

ネイティブの機能終了呼び出しの実行順序を調整します。最初の画面を残し、もう1つを後ろに配置することで、機能終了の実行に費やす時間を削減します。
必要なコード情報（例：個人ホームページの最初から最後までのランタイム）を最適化する初期化ロジック
最も外側のAppコンポーネントのマウントはインターフェイスデータに依存せず、ページは事前に初期化され、インターフェイスデータは並列で要求され、レンダリングは非同期です。
コード実行ロジックを調整し、キーロジックを格納に移動し、事前に実行する
ドットなどのページの一部を論理的に後置することにより、ページマウントの実行時間が短縮され、操作の波の後
に、80ビットの100ms +ゲインが得られます。

最初の画面インターフェイスのマージ

上記のように、ハイブリッドの最初の画面では、フロントエンドでシリアルに実行される2つの非同期ネットワークインターフェイスが必要です。統計パフォーマンスデータから、インターフェイスを呼び出してインターフェイスデータを取得するプロセスで、最長の時間がネットワーク接続の確立です。2つのインターフェイスが1つのインターフェイスにマージされ、最初のスクリーン時間を少なくとも1回節約できますインターネット接続時間（110ms +個人ホームページ用）。もちろん、インターフェイスのマージでは、サーバーのフラットサウンドを考慮し、ホワイトスクリーン時間の損失を考慮する必要もあります。

フロントスクリーンインターフェース

標準のSPAページとして、個人のホームページのほとんどすべてのロジックはパブリックjsがロードされた後に実行されますが、特に最初にロードされ、ローカルキャッシュがない場合、jsのロードには時間がかかります。
ハイブリッドバージョンには同期インターフェースがなく、最初の画面の最初のリクエストはjsが読み込まれた後にのみ発行できるため、ハイブリッドバージョンには最適化の余地があります。
現在、主流のブラウザはデフォルトで4〜6個のリクエストを処理できることが知られています。jsをロードするときに、最初の画面に必要なデータ（jsonp）を取得すると、シリアルが並列になり、2つがオーバーラップする時間を節約できます。
フロントスクリーンインターフェースは以前はそうでした：
ハイブリッドは、最初のスクリーンの最初のインターフェースのデータをフェッチするために最小限の最小コードパッケージをパッケージ化し、完了後にグローバル変数とイベントをイベントに格納しましたフォームが送信されます。一部のiOSシナリオでは、ネットワーク接続を確立するための時間のかかる最初のリクエストのため、jsonpの代わりにネイティブ側の機能が使用されます。最初の画面インターフェースでのiOS画面のゲインは260ミリ秒以上で、Androidは約60ミリ秒です。

エンジニアリング

エンジニアリングの最適化は、主にパッケージ化に力を注ぐことです。パッケージ化は、時間のかかるhttpロードJS、CSS、およびその他のリソースに影響します。同じ条件下で、パッケージサイズが小さくなり、リクエスト数が少ないほど、リソースのロード速度が速くなります。

梱包と開梱

JSとCSSのリソースはパッケージ化されてマージされますが、パッケージファイルが大きすぎること、単一のリクエストに時間がかかりすぎること、およびビジネスシナリオに従ってコードパッケージを合理的に分割する必要があることを考慮する必要があります。
メインストリームブラウザは通常、4〜6個のリクエストを並行して処理できます。これにより、リソースパッケージを合理的に分割し、並行リクエストを使用して全体の応答時間を短縮できます。
ブラウザのキャッシュは、パケットを合理的に分割することにより、最大限に使用されます。各小を維持するロックバージョン、bundleハッシュ値を変更しないときは、安定した、より大きなJS、CSSで、画像を直接ハードディスクのキャッシュに書き込むことができます。たとえば、パーソナルホームページでは、コードの変更頻度に応じて、jsパッケージを同じサイズの3つのボリュームに分割しています。ベンダーはさまざまなnpm依存関係であり、バージョンは安定しており、通常は変更されません。ユーザーがオンラインになるたびに、ユーザーのブラウザーはCDNから他の2つのコードパッケージを要求するだけでよく、ベンダーは前回有効期限が切れていないローカルキャッシュを使用します。

モダンモード

通常、開発中にコードを作成するためにES6（ES2015 +）を使用します。ES6の新機能により、開発作業がより便利で高速になります。ただし、パッケージ化するときは、Babelを使用して変換し、ES6をサポートしないブラウザーでコードを実行する必要があります。変換されたコードはポリフィルに追加されます。最も直感的なのは、コードパッケージのサイズが大きくなることです。モダンモードネイティブES6をサポートするブラウザーでは、jsはESモジュールをロードします

|
|

白い画面（ミリ秒）

最初の画面（ミリ秒）


実験グループ
対照群
収入

最適化効果のまとめ

最適化後、JSの初期化時間が短縮されます。最初の画面データjsonpリクエストは、インライン最小コードパッケージを使用してページが準備される前に送信されます。jsonpが戻り値を取得する前に、ページに必要な他のCSSおよびJSリソースが並列にロードされます。アプリマウントとページランタイムは事前に初期化されています。最初の画面データが戻った後、他の操作に貴重な時間を費やすことなく、すぐにデータを処理してレンダリングできます。RBIなどのリクエストの後、最初の画面が完了したら、JSがデータとレンダリングに集中できるようにします。同時に帯域幅を解放して、画像などのユーザーに見えるリソースをロードします。最適化されたプロセスは、次の図で表すことができます。

最適化後のデータ分析

両端の最初のスクリーン時間は大幅に短縮されます。最初のスクリーン要求（2つの画像のオレンジ色の部分）は、サーバークラスメートのインターフェースパフォーマンスの最適化の恩恵を受けます。フラットサウンドだけで時間を80ミリ秒+短縮できます。

Androidでは、クラスメートのハイブリッドフレームワークの最適化のおかげで、ハイブリッドページとローカルのjsリソースがより速く読み込まれ、効果がより大きくなります。

まとめ

労働者が自分の仕事をうまくやりたいのなら、彼は最初に彼の武器を研がなければなりません。最適化に着手する前に、データ参照ポイントの選択とデータの収集に多くの時間を費やし、繰り返しのコードレビュー、実験、ビジネスロジックの精査を通じて、各主要指標が真の信頼できるデータを反映するようにしました。この記事は、データから始まる最適化ポイントの分析方法のみを提供します。リストされた最適化方法は、実際のビジネスと切り離せず、普遍的ではありません。ボトルネックを解決するための少し異なる方法がもたらされることを願っていますアイデア。