最初のスクリーン時間を自動的に取得する方法

作者:劉遠洋
会社:マイクロショップ-フロントエンドチーム
日付:2018-03-05
本文はマイクロショップのフロントエンドチームblogに発表します

背景

フロントエンド性能データの取得方法では、現在、業界内では手動で点を埋める方法が多く使用されている.すなわち、コードでは、ヘッダが完了した位置を手動で判断し、そこにヘッダ記録のコードを追加する.
このようにするのは簡単で手間が省けますが、欠点も明らかです.

と業務コード混用共通の監視ニーズが業務コードに混入

.

カバー不完全はページ開発者が自覚的に手動で埋め込みコードを追加する必要があり、業務における埋め込みカバー率は必ずしも100%

に達するとは限らない.

の精度は必ずしも高くない.開発者が統計スクリプトの配置位置を自分で判断する必要があるため、1人1画面に対する理解が異なるため、いくつかの不正確な状況がある.
上記の分析に基づいて、私たちは最近いくつかの方案を試みて、最初のスクリーンの時間計算を自動化して、人力を節約して、そして正確性を高めることを試みました.

定義＃テイギ＃

最初のスクリーン時間の定義は、企業ごとに異なる場合があります.この文書では、最初のスクリーン時間とは、次のことを指します.

ページヘッダに画像がある場合

     =               - window.performance.timing.navigationStart

ページヘッダに画像がない場合

     =               dom       - window.performance.timing.navigationStart

実装の原理

全体的な考え方は次のとおりです.

ページのロードから、一定の間隔で打点し、各時刻の下のページの最初の画面の画像リストとその他の情報の問題を絶えず記録します:どのような間隔で打点しますか?

ページヘッダが安定している時刻T 1(この時刻までにページヘッダが一定に安定している可能性がある)を見つける問題:このT 1をどのように見つけるか?

は、T 1時点のヘッダピクチャ数を基準として、前に反転する、すべての打点のうち最後にT 1時点のヘッダピクチャと一致する打点時刻T 2

を見つける.

統計T 2時刻の全ピクチャロード完了時間T 3

T 3すなわち先頭画面が完了する時点で、

へのエスカレーションが行われる.
次に、上記の問題を1つずつ解決します.

問題:どのようにしてトップスクリーンが安定した状態にある時刻T 1を見つけますか?ページのロードからレンダリングまで、2つの大きな段階に分けます.1.データの取得;2.データを取得し、ページをレンダリングします.このロジックは、ほとんどのページロジックに合致します.まずデータを取得し、ページをレンダリングします.ソリューション:

AOP切面方式でXHRのsendオブジェクトを傍受し、ページ内の最初のXHRリクエストをキャプチャし、最初のXHRリクエストが発行された時点を起点とし、1000 ms以内に発行されたすべてのリクエストを配列Requestに統計する.最初の画面に影響を及ぼす可能性のある要求は、firstscreen.report()の期間内に発行されたと考えられています.

は、直列型の要求(すなわち、次の要求が前の要求の戻りデータに依存する)について、各要求が戻った後、500 ms以内に新たに発行された要求を配列Requestに統計する.一部のページのデータ要求方式はシリアルであり、2つの直列の要求後にヘッダ画面のデータがロードされる可能性があります.最初の画面に影響を与えるリクエストもこのような形式で発行される可能性があります.

配列Requestで集計されたリクエストは、基本的にすべての影響を及ぼすヘッダのデータリクエストを含み、ヘッダに影響を及ぼさないデータリクエストの一部も含まれています.

は、上記の統計された要求に対して、すべてのデータが返される時刻T 1を見つけ、その後、[ xhr ， xhr + 1000ms]は、ページがデータを受信した後にレンダリングが完了することを保証する(300 msは1回のレンダリングに十分である).

このときのT 1時点では、ページヘッダは安定した状態とされている.

質問:どのような間隔で打点しますか?

MutationObserverページdomの変化をキャプチャするためにMutationObserverオブジェクトが使用されていることはよく知られています.したがって、スクリプトでは、MutationObserverを使用してdomの変化をリスニングし、domの変化のたびに1回のドット(この時点の最初の画面の画像情報を統計する)

をトリガーします.

setIntervalsetIntervalもタイミング打点

を実現できる.

MutationObserverとsetIntervalを組み合わせたが、MutationObserverコールバック関数のトリガタイミング開発者は制御できず、いくつかの状況がある.

の2回のコールバック間は数百ミリ秒から1秒以上離れ、統計誤差が大きい

を招く可能性がある.

は場合によってはdomは変化しないが、ページ要素のうちT1 = T1 + 300msのimgが変化したり、要素のsrcが変化したりして、MutationObserverでのコールバックをトリガーすることはなく、統計的なミスを招くため、現在のスキームはMutationObserverとsetIntervalを組み合わせて、MutationObserverのコールバックの合間にsetIntervalを起動し、ページのロード中にドット間隔が長すぎないことを保証し、統計精度を高めます.

とうけいてきごさ

上記の複雑な打点と判断を用いても誤差は依然として存在するが,誤差はいったいどこにあるのか.
次の図に示します.

     （1 images）       2（2 images）          1（2 images）
    |                        |                       |
    |________________________|_______________________|
    t1                       t2                      t3

上記の理論によれば、background-image時刻をヘッダ画面を統計できる時刻、2枚のピクチャのロードが完了した時刻、すなわちヘッダ画面が完了した時刻とする.t2とt2の時刻差は1枚の画像です.
我々の理論によれば、ヘッダスクリーンの完了時間は、t 2の後のある時点t1にあるに違いない.
実際に異なる画像は、いつロードが完了したのか、t2.n前にロードが完了したのか、リクエストが発行されたのか分からないが、まだロードが完了していない.
誤差はここにあります.それはいつも存在します.
しかし、誤差が許容できる範囲内のトップスクリーンデータを統計する必要があります.会社の業務実践のフィードバックから見ると、データの信頼性が高いです.

Talk is cheap, show me the code

私たちもこのツールをオープンソースしました.
github: auto-compute-first-screen-time
npm: auto-compute-first-screen-time
仲間たちの使用、ツッコミ、改善を歓迎します.