簡単なことの難しさ：敵を作らずにページを開くのにかかる時間を測定する方法

あなたは開発者であり、すべての最適化の後、ページがより速く開くことを確認したいと考えています。 または、ラクダではなく、すべてを本当に加速したことを上司に証明する必要があります。 または、ユーザーがページをゆっくり開くことで苦労しないようにしたいかもしれません。 または、私たちの場合のように、あなたはテスターであり、今ではクライアントの生産性を宣誓する責任があり、プロダクションブレーキを逃すと夜寝ることができなくなります。



クライアントのパフォーマンスを測定することは簡単な作業ではありません。 特に、プロジェクトの多くのスタンドに数百ページある場合。 それぞれがjsコードで満たされ、何百人もの開発者が毎日最適化、変更、再作成します。 データを収集、処理、保存するシステムを設計する必要があります。 どのストレージを選択しますか？ データベースを設計する方法とDBMS 簡潔な「ページが開いた時間」の前に消える多くの興味深いタスク。 私たちにとって、この質問に対する答えを探した結果、探偵による調査、白熱した議論、真実の探求が行われました。 彼の最も興味深い点はこの記事にあります。

「ページを開く」とは何ですか？

昔、Web 2.0より前では、ページの読み込みの終了を判断するのは比較的簡単でした。サーバーからドキュメントが±数ミリ秒で到着し、ページが読み込まれたと考えられます。 その後、画像、スタイル、およびその他のリソースを読み込むクエリの数が増加しました。 ページの読み込みの終わりを見つけることはもう少し難しくなりました。すべてのリソースが読み込まれるのを待たなければならなくなったので、誰もがさまざまなjsイベント（window.onloadなど）に結びつき始めました。 インターネットは進化し、ページは重くなり、以前のアプローチは機能しなくなりました。 すべてのリソースを受け取った後のページの読み込みが停止しなくなりました。 jsから直接実行されるリクエストがあり、プリロードやその他のメカニズムが登場し、ページのロードの終了と見なすことができるポイントを大きく曖昧にしました。 そして今、あなたはページの読み込みの終わりを決定するためのさまざまなオプションを満たすことができます。 それぞれについて簡単に説明します。



ネットワーク活動。 定義自体（ページの読み込みの終わり）から、ページがリクエストの処理を停止した瞬間を待つ必要があることがわかります。 「保留」状態のリクエストはなく、しばらくの間、新しいリクエストは実行されていません。 これを決定するのは難しくなく、文言は明確です。 しかし、ほとんどのサイトでは機能しません。 ドキュメントを読み込んだ後、jsを初期化するのに時間がかかり、ページの構築時間が長くなります。 そして、その悪名高い「ページが読み込まれた」ことは、ダウンロードの終了よりもずっと後にユーザーに起こります。 また、不愉快な驚きはプリロードである場合があります。これはページのロード後にトリガーされ、数秒続くことがあります。 さらに、ページ上のさまざまなメカニズムが中断することなくサーバーと情報を交換することも珍しくありません。 したがって、ネットワークアクティビティが終了することはありません。



イベント。 「ページが読み込まれた」ではなく「ページが構築された」と言うのは正しいことです。 すでに述べたwindow.onload以来、jsコードのトリガーだけでなくページの完全なオープンもバインドできる新しいイベントが追加されました。 論理的な継続として、2012年に作業が標準に始まります。 ここでは、ページの読み込みプロセスに関連する一連のイベント全体が表示されます。 しかし実際には、これらのイベントは、ページ全体の構築が行われる前にトリガーされることが判明しています。 これは、 合成テストと膝テストの両方で確認できます。 はい、理論的には、ページが最終的に読み込まれたことを示す何らかの人工的なイベントを作成できます。 ただし、すべてのページに対して個別にこれを行う必要があります。 さらに、変更がある場合は、新しいアプローチの正確性を再確認してください。 これもまた、元のタスク-ページがロードされたことを理解する方法-につながります。



視覚的な変更。 クライアントパフォーマンスは、何らかの形でユーザーを中心に展開します。 すなわち 私たちにとって重要なのは、私たちの製品で作業するときに人がどのように感じるかです。 そして、ここでは、考えずに、急いで、生きている人を置き、ページの読み込み時間を「目で」判断するように彼に指示することができます。 アイデアは失敗する運命にある、なぜなら ユーザーはページがスローダウンしているかどうかを判断できますが、10ポイントのスケールでスローダウンがどれほど遅いかはわかりません。 ただし、ここでは、視覚的な変更がおそらくページがロードした最高の指標の1つであることを理解しています。 ページの表示を常に監視し、視覚的な変更を停止するとすぐに、ページが読み込まれたと想定できます。 しかし、すべてのページ変更は同様に重要ですか？



ページを描画するのはこれが初めてで、ここに境界線が表示され、テキストが表示され、写真が読み込まれ、カウンター、ソーシャルボタン、コメントなどが読み込まれ始めました。 さまざまな状況では、ページの読み込みに関連するさまざまな手順が重要です。 どこかで、最初のレンダリングが重要ですが、誰かにとっては、ユーザーがコメントを見たときを知ることが重要です。 ただし、原則として、ほとんどの場合、メインコンテンツをダウンロードすることが重要です。 「ページが読み込まれた」と見なされるのは、メインコンテンツの視覚的な外観です。 したがって、他のすべてのものが等しい場合、このイベントに基づいてページの読み込み速度を評価できます。 ページを包括的に操作するために、「速度インデックス」と呼ばれる素晴らしいアプローチがあります 。これについては、 ここで説明します 。



アイデアは次のとおりです。ページがどの程度均等にロードされるかを理解しようとしています。 1つのページの2つのバージョンは2秒で開くことができましたが、視覚的な変化の最初の90％は、開いてから1秒後に発生し、2番目は1.7秒後に発生しました。 ユーザーが同じ時間を開くと、最初のページは2番目のページよりもはるかに高速に見えます。



操作性。 したがって、「ページが開いた」ことを正確に理解できました。 止めてもいいですか？ しかし、ありません。 ページがロードされたら、新しいコメントを追加するためのボタンをクリックします...そしてズボンは何にも変わりません-ページはクリックを無視します。 どうする 別のメトリックを追加します。 ターゲット要素を選択する必要があります。 そして、いつ相互作用が可能になるかを調べます。 後述するように、これは最も難しいタスクです。



彼らはページの読み込みの終わりを考慮すべきことを理解したようです。 そして、オープニングの始まりはどうですか？ ここでは、すべてが明らかなようです-ブラウザにページを開くコマンドを与えた瞬間からカウントしますが、ここでも詳細を気にします。 beforeunloadのようなイベントがあります。 それらが発生したときに起動するコードは、ページが開く時間に大きな影響を与える可能性があります。 もちろん、事前に空欄にいつでも切り替えることができますが、この場合はこの問題をスキップできます。 そして、私たちのテストの優れた性能により、ユーザーはブレーキについて不平を言うでしょう。 繰り返しますが、詳細に基づいて選択してください。 比較測定では、常に空白のページから始めます。 また、重要なビジネスシナリオの作業時間を測定する一環として、ページからページへの移行に関する問題を検出します。



顧客として1対1で測定することは重要ですか？ おそらく。 しかし、開発と高速化にはすぐにメリットがありますか？ 事実とは程遠い。 少なくとも1つの指標を選択し、それに基づいてページを開くのにかかる時間を推定することが重要であると述べている優れた記事を次に示します。 選択した1つのインディケーターを操作し、最適化を追跡し、トレンドを構築するのがはるかに簡単になります。 そして、そのためのリソースがある場合にのみ、補助メトリックで補足します。

別の結果になるのはなぜですか？

素晴らしい、今では会社の全員が同じ言語を話します。 開発者、テスター、マネージャーは、ページを開く時間によって、ページにメインコンテンツを表示する時間を意味します。 これらの測定を正確に実行するツールも作成しました。 かなり安定した結果が得られ、散布の測定は最小限です。 私たちは最初のレポートを発行し、...多くの不満のあるコメントを受け取ります。 それらの中で最も人気のあるものは「しかし、私はここでそれを試しました、そして、すべてが私と異なります！ 測定方法に従って、同じツールを使用したと仮定しても、結果は皆まったく異なることがわかります。 掘り始めて、だれかがWi-Fiを介して測定を行い、誰かが32コアのコンピューターを持ち、誰かが電話からサイトを開いたことがわかりました。 測定の問題は多面的ではなく、多次元的であることがわかりました。 さまざまな条件下で、さまざまな結果が得られます。



問題が発生しました：ページが開く時間に影響する要因は何ですか？ 急いで、 そのような連想マップが作成されました。



約60〜70の異なる要因が判明しました。 そして、一連の実験が始まりました。これにより、非常に興味深い結果が得られることがありました。



キャッシュするかしないか-それが問題です。 最初に発生した異常は、最初のレポートで発見されました。 空のキャッシュと完全なキャッシュで測定を行いました。 キャッシュがいっぱいの一部のページは、空のページよりも速く配信されませんでした。 また、一部のページには時間がかかります。 同時に、最初の開始時のトラフィック量はメガバイト単位で測定され、2番目の時点では100 KB未満でした。 DevToolsを開きます（ちなみに、DevTools自体が測定に強い影響を与える可能性がありますが、比較研究の場合はこれが必要です）、データ収集を開始してページを開きます。 そして、この写真を取得します。







ここでは、ほとんどの場合、ブラウザがjsファイルを解析/初期化していたことがはっきりとわかります。 すなわち jsコードが非常に多く、ブラウザーはネットワーク経由でファイルを受信するのにかかる時間を非常に最適に使用するため、ほとんどの場合、jsモジュールの受信速度よりもjsモジュールの初期化速度に依存します。 ネットワークトラフィックは非常に重要ですが、理想的な接続（ネットワークの内部から測定）を考慮すると、まさにこの状況を把握できます。 この問題は、例えばEddie Osmaniによってすでに強調されています。



したがって、レポートでキャッシュを埋めても実際には加速しなかったページでは、すべてが明確です。 そして、なぜいくつかのページがさらに長く開き始めたのですか？ 次に、問題が発見された[ネットワーク]タブを注意深く確認する必要がありました。 リクエストの数を減らすために、ほとんどすべてのjsモジュールと追加の依存関係を1つの大きなファイルに結合しました。 そして、1ページで、このファイルの重量は3 MBにもなりました。 ディスクはSSDではなく、pingがゼロのチャネルでした。 さらに、Chromeは非常に奇妙なことにディスクキャッシュと連携して動作し、場合によっては突然ブレーキがかかります。 そのため、ファイルは、ネットワーク上を飛行するよりもキャッシュから時間がかかりました。 最終的に、これは合計時間の増加につながりました。



はい、ページサイズは重要であり、削減する必要があります。 しかし、今では、データ構造の最適化も同様に重要です。 ユーザーが圧縮解除に余分な50ミリ秒を費やした場合、新しい圧縮アルゴリズムによって小さなファイルのサイズを10％削減することの使用法は何ですか？ また、サイトhttparchive.orgの統計を見ると、この状況がさらに悪化する可能性があることがわかります。







下のスケールは月と年、左のスケールはページあたりのコードjsの平均量、右のスケールはページあたりの平均リクエスト数です。



ネットワーク条件について。 上記では主に理想的なチャネルで測定すると言われましたが、ユーザーがWi-Fiまたは3G経由でページを開いたときのユーザーの体験を調べることが必要になる場合があります。 または、どこかにダイヤルアップがあり、原則として、ページがククエボの村のババフロシで開くかどうかを理解する必要があります。 そしてもちろん、ここでは、同じ村に測定用のノードの1つを配置したり、不良チャネルをエミュレートしたりできます。 後者は、別の記事または本全体に基づいているため、私たちは、自分で使用できるツールのスタックに限定されます。



まず、これらはさまざまなhttpプロキシです：BrowserMobProxy（ライトモード）、Fiddler、mitmなど。 もちろん、不良チャネルをエミュレートするのではなく、n KBごとに遅延を作成するだけです。 しかし、実践が示すように、一般的にhttpで動作するアプリケーションの場合、これで十分です。 真にエミュレートしたいときは、 ネテムと不器用な人が助けになります。



このようなテストでは、ネットワークがWebアプリケーションのパフォーマンスにどのように影響するかを理解することが望まれます。 結果を得るためにこれがそれほど重要でない場合、その解釈のために、バグレポートに「遅くなります」と表示されないように実際に理解する価値があります。 このテーマに関する最高の本の1つは、 Ilya Grigorikによる「High Performance Browser Networking」です 。



ブラウザ 間違いなく、ブラウザ自体がページのオープン時間に非常に重要な役割を果たします。 そして今、私たちは、すべてのブラウザメーカーが自分たちの馬が地球上で最速であることを示すために自ら設計したベンチマークテストについても話していません。 現在、エンジンまたはブラウザー自体のさまざまな機能について説明しています。これらは最終的にページが開く時間に影響します。 したがって、たとえば、Chromeは別のストリームで受信されるときに大きなjsファイルを初期化します。 しかし、著者が「大きなファイル」とはどういう意味かはどこにも明記されていません。 しかし、Chromiumのソースを見ると、30 KBについて話していることがわかります。



したがって、jsモジュールをわずかに増やすことで、ページの読み込み時間を短縮できる場合があります。 確かに、それほど有限ではないので、すべてのjsモジュールを連続して増やすのはまさにその方法です。



これは小さな詳細です。 さらに広く見ると、さまざまなブラウザ設定、開いているタブ、さまざまなプラグイン、さまざまなストレージとキャッシュの状態があります。 そして、これらすべてが何らかの形でブラウザに参加し、特定のユーザーに対してこのページまたはそのページを開く速度に影響を与える可能性があります。



私たちは、測定に大きな影響または小さな影響を与える多くの要因があることを発見しました。 それについてどうすればいいですか？ すべての組み合わせを繰り返しますか？ その後、コンビナトリアル爆発が発生し、リリースごとに1ページでも実際に測定する時間がありません。 正しい決定は、メインの連続測定用に1つの構成を選択することです。 テスト結果の再現性が最も重要です。



残りの状況については、個別の実験を個別に実施することにしました。 さらに、ユーザーに関するすべての仮定は真実ではない可能性があり、インジケーターを直接収集する方法（ RUM ）を学ぶことをお勧めします。

ツール

一般に、測定とWebパフォーマンスに専念する多くのツールがあります（gmetrix、pingdom、webpagetestなど）。 Googleで武装し、それらの多くを試してみると、次の結論を導き出すことができます。

• すべてのツールは、「ページのオープン時間」が何であるかについて異なる理解を持っています
• ページが開かれるホストはそれほど多くありません。 そしてロシアのために-さらに少ない。
• 認証済みサイトの測定は非常に困難です。 いくつかの場所では、この問題を克服する方法があります。
• 詳細のないほとんどの部分のレポート。すべてがクエリのラダーと簡単な統計に制限されます。
• 結果が常に安定しているとは限らず、時には完全に不明確な理由もあります

さらに実用的なものについて。



WebPageTest さまざまなツールの中で、 WebPageTestは明確に際立っています。 これは多機能なマルチハーベスターであり、絶えず進化し、優れた結果をもたらします。

このツールの主な利点の1つ：

• ローカルノードを展開し、企業ネットワークからサイトをテストする機能
• 驚くほど詳細なレポート（スクリーンショットやビデオを含む）
• 良いAPI
• ページを開くタイミングを決定する多くの方法

最後のプラスについては、別に言う価値があります。 ここでは、おそらく、ほとんどすべてのメソッドが実際に収集されます。 最も興味深いのは、Speed IndexとFirst Interactiveです。 前述の最初について。 また、2番目は、ページの表示がアクションに応答し始めるまでの時間を示しています。 そして突然、油断ならない開発者がサーバー上で画像を生成し、私たちに送信し始めました（私はそうしません）。



このようなソリューションをローカルに展開する場合、パフォーマンステストのニーズのほぼすべてをカバーできます。 しかし、悲しいかな、すべてではありません。 メインコンテンツの正確な表示時間を取得したい場合、便利なフレームワークを使用してスクリプト全体を実行する機能を追加するには、独自のツールを作成する必要があります。 一度にやったこと。



セレン 意識的というよりも習慣から外れて、最初のパンケーキにセレニウムが選ばれました。 細部を考慮しないと、ソリューションの本質は次のようになりました。







ブラウザーを目的の状態に変換し、ページを開いて、Seleniumがターゲット要素をユーザーにアクセス可能かつ表示可能と見なすまで待機し始めます。 ターゲット要素は、ユーザーが見ることを期待しているものです：メッセージテキスト、記事テキスト、写真など。



これらの測定はすべて10回実行され、平均結果が計算されました（中央値、算術平均など）。 一般に、時々安定した結果が得られました。 ここでは幸福のように思えますが、私たちの辛抱強い額は再び普遍的な熊手に出会います。 1つの不変のページで安定していましたが、このページを変更すると不合理にジャンプし始めました。 ビデオはこれを理解するのに役立ちました。 同じページの2つのバージョンを比較しました。 ビデオ録画により、ページはほぼ同時に開かれました（±100 ms）。 また、Seleniumの測定結果から、ページが1秒半長く開き始めたことが持続的にわかりました。 そして安定して長くなります。



調査の結果、Seleniumでis_displayedが実装されました。 このプロパティの計算は、要素のいくつかのjsプロパティをチェックすることで構成されました。たとえば、DOMツリーにある、表示されている、サイズがゼロでないなどです。 さらに、これらのチェックはすべて、すべての親要素に対して再帰的に実行されます。 非常に大きなDOMツリーを持つことができるだけでなく、jsに実装されているチェック自体は、jsモジュールの初期化プロセスと他のjsコードの実行のために、ページを開く瞬間に非常に長い時間がかかる可能性があります。



その結果、Seleniumを別のものに置き換えることにしました。 最初はWebPageTestでしたが、一連の実験の後、シンプルで実用的なソリューションを実装しました。

自分の自転車

主にページ上のメインコンテンツの視覚的な外観の時間を測定したかったため、60 fpsの頻度でスクリーンショットを撮ってツールの測定値も選択しました。 測定メカニズム自体は次のとおりです。







デバッグモードを介して、Chromeブラウザーに接続し、必要なCookieを追加し、環境を確認し、同じマシンでPILを介して並行してスクリーンショットの撮影を開始します。 テストアプリケーション（UAT）で必要なページを開きます。 その後、10秒間続く重要なネットワークおよび視覚アクティビティの終了を待ちます。 その後、結果とアーティファクトを保存します：スクリーンショット、HARファイル、Navigation Timing APIなど。



その結果、数百のスクリーンショットを取得して処理します。







通常、何百ものスクリーンショットからすべての重複を削除した後、8個以下しか残りません。 次に、隣接するスクリーンショット間の差分を計算する必要があります。 最も単純な場合の差分は、たとえば、変更されたピクセルの数です。 信頼性を高めるために、すべてのスクリーンショットの違いは考慮せず、 一部のみを考慮します。 その後、すべての差分を合計して、変更の総数（100％）を取得します。 ここでスクリーンショットを見つけるだけで、その後90％以上のページ変更が発生します。 このスクリーンショットを取得するのにかかる時間は、ページが開く時間になります。



デバッグプロトコルを介してChromeに接続する代わりに、Seleniumを使用することもできます。 なぜなら バージョン63以降、Chromeは複数のリモートデバッグをサポートしているため、Seleniumが提供するものだけでなく、データセット全体にアクセスできます。



このようなソリューションの最初のバージョンができたらすぐに、退屈で骨の折れるが非常に必要な一連のテストを開始しました。 はい、製品をテストするためのツールもテストする必要があります。



テストには、2つの主なアプローチを使用しました。

1. ロード時間が事前にわかっている参照ページを作成します。
2. 代替手段を使用してページを開くタイミングを決定し、多数の（ページごとに100を超える）測定を実行します。 何よりも、画面のビデオがここに表示されました。

私たちは定期的にテストを実施しています。 ツール自体が変更され、テスト対象のアプリケーションが変更されます。 この記事を書くとき、私は安定したページの1つを取得し（サーバーパーツはほぼ瞬時に実行されます）、3つの異なるアプローチを通じて一連の100のテストを実施しました。 ビデオを通して、10回測定し、中央値を計算しました。







ご覧のとおり、スクリーンショットを使用すると、エラーから10ミリ秒以内に現実に近い結果が得られます。 しかし、Seleniumを使用すると、最大5秒の不可解な放出を伴うかなり強い広がりがあります。



はい、再び真空中の球形の馬について、これは普遍的な方法ではありません。 このようなアルゴリズムは、当社の製品でも機能しますが、他のサイトでは簡単に機能しません。 さらに、以前の多くのアプローチと同様に、量子物理学のように、彼は観測者のパラドックスを欠いていません。 結果が表示されないため、影響しないことが保証されています。 エラーの程度を減らすことしかできません。



少なくとも、PILはいくつかのリソースも利用します。 しかし、それにもかかわらず、このようなソリューションは昨年、会社でうまく使用されています。 定期的に更新されますが、基本的な考え方は変わりません。



著者セルゲイ・ドクチャエフ