Webパフォーマンスの例

複雑なシステムでは、ほとんどの部分の最適化プロセスは、システムのさまざまなレイヤー間の結合を解くことからなり、各レイヤーには独自の制限があります。 これまで、さまざまな物理的手段とデータ転送プロトコルなど、多数の個々のネットワークコンポーネントを詳細に調査してきました。 これで、Webパフォーマンスの最適化に関するより広く包括的な図に注意を向けることができます。

• Webパフォーマンスに対する遅延と帯域幅の影響。
• TCPがHTTPに課す制限。
• HTTPプロトコル自体の機能と欠点。
• Webアプリケーション開発の傾向とパフォーマンス要件
• ブラウザの制限と最適化。

異なる層間の接続の最適化、システムのレベルは、連立方程式を解くプロセスとほとんど変わりません。 各方程式は他の方程式に依存し、同時にシステム全体の可能な解決策の数に影響を与えます。 厳密に修正された推奨事項や既製のソリューションはないことに注意してください。 個々のコンポーネントは進化し続けています。ブラウザの高速化、ユーザー接続プロファイルの変化、Webアプリケーションのコンテンツの変化の継続、設定されるタスクの複雑化などです。


したがって、現代のベストプラクティスの分析と分析を掘り下げる前に、一歩下がって問題が実際に何であるかを判断することが重要です：現代のWebアプリケーションとは何ですか、どのツールがあり、Webパフォーマンスをどのように測定しますか？システムの一部は、私たちの進歩を助け、妨げます。

ハイパーテキスト、Webページ、およびWebアプリケーション

過去数十年にわたるインターネットの進化の結果として、ウェブ上で情報を提示するための3つの異なるアプローチを受け取りました。

• ハイパーテキスト文書。
• さまざまな形式のメディアコンテンツを含むWebページ。
• インタラクティブなWebアプリケーション。

エンドユーザーが最後の2つのアプローチの境界を見ることは難しい場合があることを認識しておく必要がありますが、パフォーマンスの観点からは、それぞれが異なる方法論、評価、パフォーマンスの決定を必要とします。

ハイパーテキスト文書

ハイパーテキストは、いくつかの基本的な書式設定機能とハイパーリンクのサポートを備えたプレーンテキストでWorld Wide Webの基礎になっています。

現在、これは面白そうに思えませんが、ハイパーテキストはWorld Wide Webにとって非常に有用であり、現在使用しているすべての前提条件でした。

ウェブページ

HTMLワーキンググループと最初のブラウザーの開発者は、ハイパーテキストの機能を拡張し、メディアのサポートを導入しようとしました：画像と音声。 その結果、Webページの時代が到来しました。これは、視覚的には問題ないが、インタラクティブ性が少ないメディアコンテンツの開発された形式の存在によって区別されます。 これに含まれるWebページは、通常の印刷された新聞ページと大差ありません。

Webアプリケーション

JavaScriptの追加、革命的なDynamic HTML（DHTML）およびAJAXのサポートの最近の導入により、業界は揺れ動き、単純なWebページがインタラクティブなWebアプリケーションに変わり、ユーザーがブラウザーのリクエストに直接応答できるようになりました。 これらすべてが、本格的なブラウザアプリケーションの最初の実装への道を開きました。 たとえば、Outlook Web Access（これによりIE 5でXMLHTTPサポートが開始されました）。 これは、スクリプト、カスケードスタイルシート、マークアップ間の複雑な関係の新しい時代の始まりであると言えます。

HTTP 0.9のセッションは、ハイパーテキストを正しく表示するのに十分な単一のドキュメントリクエストから表すことができます。 1つのドキュメント、1つのTCP接続、そして接続をリセットします。 上記に基づいて、最適化プロセスを想像することは難しくなく、非常に簡単でした。 必要なことは、短いTCP接続に対する単一のHTTP要求のパフォーマンスを改善することだけでした。

Webページの出現により、この公式は変わりました。 1つのドキュメントの要求/受信から、ドキュメントとそれに依存するリソースの要求に進みました。 HTTP 1.0では、メタデータ（ヘッダー）の概念が導入されましたが、HTTP 1.1では、概念が拡張され、パフォーマンス指向のさまざまなディレクティブが含まれるようになりました。 たとえば、厳密に定義されたキャッシング、キープアライブなど。 したがって、複数の同時TCP接続を取得し、ドキュメントのロード時間はパフォーマンスの重要な指標ではなくなります。 PLTと略されるページの読み込み時間を評価するのが習慣です。

最後に、Webページは、メインコンテンツの補足としてメディアコンテンツを使用するWebアプリケーションに徐々に変わりました。 統合アプローチを使用する場合、システム全体が次のスキームに適合します：htmlマークアップはアプリケーションのメイン構造であるスケルトンを決定し、cssは構造内の要素の位置を決定し、スクリプトはユーザーのリクエストに応答するインタラクティブアプリケーションを作成し、これらを実装するためにマークアップとスタイルを潜在的に変更しますクエリ。

そのため、Webパフォーマンスの分析に不可欠であったページの読み込み時間などのパラメーターは、パフォーマンスを測定するのに十分ではなくなりました。 私たちはもはやウェブページを作成するだけでなく、揮発性で動的なインタラクティブなウェブアプリケーションを構築します。

PLTの代わりに、次の質問への回答に興味があります。

• アプリケーションをダウンロードするプロセスの主な手順は何ですか？
• ユーザーからの最初のリクエストが正確に必要なのはいつですか？
• ユーザーにはどのようなクエリが必要ですか？
• 各ユーザーのエンゲージメントとコンバージョンの速度はどのくらいですか？

パフォーマンスと最適化戦略の成功は、特定の基準とガイドラインに従うイテレータを定義する能力に直接依存します。 特にすべてがビジネスの目標の1つである場合、アプリケーションの詳細、測定結果の使用に関する知識の特定のアプリケーションと比較することはできません。

DOM、CSSOM、およびJavaScript

最新のWebアプリケーションで「スクリプト、スタイル、マークアップの複雑な依存関係」とはどういう意味ですか？ この質問に答えるには、ブラウザのアーキテクチャを理解し、マークアップ、スタイル、およびスクリプトを組み合わせて画面にピクセルを描画する方法を理解する必要があります。


ブラウザでの解析プロセス

HTMLドキュメントの解析は、ドキュメントオブジェクトモデル（DOM）に準拠したビルドプロセスです。 また、カスケードスタイルシートオブジェクトモデル（CSSオブジェクトモデル）も使用することを忘れがちです。CSSオブジェクトモデルは、指定されたスタイルとリソースのルールに従って構築されます。 これら2つが組み合わされて、いわゆるレンダーツリーが作成されます。これは、ブラウザーが何かをレンダリングするのに十分です。 これまでのところ良い。 しかし、残念ながら、今は親友と敵を同時に紹介する必要があります：JavaScript。 スクリプトを実行すると、同期doc.writeが生成され、DOMの解析と構築がブロックされます。 スクリプトがオブジェクトの計算されたスタイルを要求できるように、これはCSSの実行をブロックします。 DOMオブジェクトとCSSOMオブジェクトのアセンブリは、しばしば絡み合っています。JSの実行中はDOMのアセンブリが不可能であり、CSSOMが使用可能な間はJSの実行を継続できません。 アプリケーションのパフォーマンス、特に最初のロードと「レンダリングの時間」は、マークアップ、スタイル、およびスクリプト間の関係がどの程度正常に解決されるかに直接依存します。

ちなみに、この人気のあるルールを覚えていますか？まず、スクリプトの後にスタイルがありますか？
これで理由がわかりました！ スクリプトの実行はスタイルレベルでブロックされるため、できるだけ早くCSSをユーザーに提供してください。

最新のWebアプリケーションの構造

まったく同じような最新のWebアプリケーションとは何ですか？ HTTPアーカイブは、この質問に答えるのに役立ちます 。 このプロジェクトはWebの構築方法を追跡し、最も人気のあるサイト（Alexa Top 1Mから300,000以上）に定期的にアクセスして、使用されるリソースの量、コンテンツの種類、ヘッダー、その他のメタデータを記録および分析します。

平均して、Webアプリケーションには次のものが必要です。

• 15ホストからの90リクエスト、合計1311 KB。
• HTML：10リクエスト、52 Kb
• 画像：55リクエスト、812 KB
• JavaScript：15リクエスト、216 Kb
• CSS：5リクエスト、36 Kb
• その他：5リクエスト、195 Kb

これを読んでいる間、数字は変化し、まだ成長していますが、止まる兆候のない安定した信頼できる成長傾向があります。 平均して、最新のWebアプリケーションは1 MB以上を占有し、15を超える異なるホストからの約100の異なるリソースで構成されています。


リクエストの平均サイズと数（HTTPアーカイブ）

デスクトップソリューションとは異なり、Webアプリケーションは個別のインストールプロセスを必要としません。 URLを入力してEnterを押すと完了です！ ただし、デスクトップアプリケーションは一度しかインストールできず、将来のインストールプロセスを忘れることがあります。 ネットワーク上の1つまたは別のアドレスにアクセスするたびにWebアプリケーションが「インストール」されると、リソースがダウンロードされ、DOMとCSSOMがアセンブルされ、jsスクリプトが実行されます。 当然のことながら、Webパフォーマンスは話題の話題となっています。
数百のリソース、メガバイトのデータ、数十のホスト、これらすべてが数百ミリ秒で統合され、インスタントネットワーキングが可能になります。

スピード、パフォーマンス、人間の知覚

速度とパフォーマンスは常に相対的です。 各アプリケーションは、ビジネス基準、コンテキスト、ユーザーの期待、および完了しなければならないタスクの複雑さに基づいて、これに関する独自の一連の要件を決定します。 アプリケーションがユーザーに応答して応答する必要があると言う場合、ユーザーの知覚の詳細を考慮して、アプリケーションの反応速度と動作を計画する必要があります。 生命の熱が加速しているという事実にもかかわらず、私たちの反応の時間は変わりません。 アプリケーションの種類（オンラインまたはオフライン）やデバイス（デスクトップ、ラップトップ、モバイルデバイス）に依存しません。

ユーザーの時間と待機：

• 0-100ミリ秒-即座に
• 100-300 ms-わずかな遅延
• 300-1000 ms-顕著な遅延
• 1000+ ms-ユーザーがコンテキストを別のものに切り替えます
• 10,000+ ms-タスクは拒否されます

ユーザーのアクションに対する応答が数百ミリ秒以内に提供された場合、アプリケーションの作業を即座に呼び出すことができます。 1秒以上経過すると、ユーザーの注意は分散され、アプリケーションとのやり取りはそれほど密集しなくなります。 10秒が経過し、フィードバックがなかった場合、ほとんどの場合、単純にタスクを拒否します。
DNSルックアップ、TCP接続のオープン、およびさらに数回のラウンドトリップ送信によるネットワーク遅延を合計します。すべてではないにしても、ミリ秒の多くがネットワーク接続に費やされます。 当然のことながら、多くのユーザーは、特にモバイルまたはワイヤレスネットワークに関しては、より優れたWebブラウザーのパフォーマンスが必要です。

ドルとセントでのWebパフォーマンス

速度はアプリケーションの機能です。 速度のためだけにダウンロードのパフォーマンスを改善する意味はありません。 Google、Microsoft、およびAmazonの調査に基づいて、これらすべてがWebパフォーマンス指標をドルとセントに換算していると結論付けることができます。 たとえば、Bingページで2000ミリ秒の遅延が発生したため、Microsoftはユーザーあたりの収入を4.3％増やすことができませんでした！

160を超える組織の調査では、ロード時間が1秒長くなると、コンバージョンが7％、ページビューが11％失われ、顧客満足度が16％低下することが示されています。

高速サイトは、より多くのビュー、高レベルのエンゲージメントとコンバージョンを提供します。 しかし、私たちの言葉を信じないでください！ 実践的な方法で信仰を強化し、サイトのパフォーマンスがコンバージョンにどのように影響するかを評価します。

データ読み込みスケジュールを分析します：滝の影響

ウェブパフォーマンスの完全な概要については、データの読み込みスケジュールに言及せずにはできません。 さらに、これは、負荷スケジュールが最も正確な診断ツールの1つであるという事実のために考慮される必要があります。
最新のブラウザには、このグラフを分析するためのさまざまなツールが用意されていますが、 WebPageTestなど、すべてのポイントを評価できる優れたオンラインサービスもあります。

WebPageTest.orgは、WebページのパフォーマンスをテストするためのWebサービスを提供する無料のプロジェクトです。 機能の1つは、テストが複数の場所で行われることです。 仮想マシンでブラウザーが起動され、多くの接続で動作するように構成できます。 テスト結果は明確なWebインターフェースですぐに利用できるため、WebPageTestはWeb開発者にとって不可欠なツールです。

まず、各HTTPリクエストは、DNS検索、TCP接続の開始、TLS交換（オプション）、HTTPリクエストの送信、コンテンツのダウンロードといういくつかの段階で構成されることを理解することが重要です。


HTTP要求コンポーネント（WebPageTest）

注意深く分析すると、Yahoo！ホームページの読み込み時間が 683ミリ秒かかります。興味深いことに、ネットワークの待機に200ミリ秒以上が費やされています。これは合計時間の30％です。 ただし、ドキュメントのリクエストはほんの始まりにすぎません。 ご存知のように、最新のWebアプリケーションには他のさまざまなリソースが必要です。


Yahoo.comページ読み込みスケジュール

Yahoo!ホームページをダウンロードするには ブラウザは、30の異なるホストから52のリソースを要求します。 リソースサイズは合計で486 KBです。

リソースグラフを使用すると、ページの構造とブラウザによるこのページの処理について多くの重要な結論を出すことができます。 まず、ブラウザーがHTMLドキュメントのコンテンツを受信して​​いる間、新しいHTTPリクエストが送信されることに注意してください。HTML解析は徐々に実行され、ブラウザーが必要なリソースをすばやく見つけて同時に新しいリクエストを送信できるようにします。

したがって、要求の順序とコンテンツの受信は、マークアップによって大幅に決定されます。 ブラウザはリクエストの優先順位を変更できますが、ドキュメント内の各リソースをさらに開くと、チャートにいわゆる「ウォーターフォール効果」が生じます。

次に、「レンダリングの開始」（緑の縦線）要素は、リソースのロードが終了するよりもはるかに早い位置にあることに注意してください。 これは、コンテンツの視覚化が早い段階で始まり、ユーザーがページの読み込みがまだ完了していないときにページとの対話をすぐに開始できることを示唆しています。 ちなみに、「ドキュメントの読み込みが完了しました」というマークは、すべてのリソースの読み込みの実際の終了よりも前にあります。 言い換えれば、ユーザーは自分のことを行うことができますが、追加のコンテンツ（広告やウィジェットなど）のダウンロードはバックグラウンドで続行されます。

レンダリングの開始、「ドキュメントがロードされました」マーク、およびコンテンツのロードの実際の完了の上記の違いは、Webパフォーマンスメトリックを議論するときにコンテキストを正しく理解する必要があることを完全に示しています。 これら3つの指標のうち、追跡するのに適切な指標はどれですか？ 秘密は、明確な答えがないことです。各Webアプリケーションは、コンテンツのダウンロードに異なるアプローチを使用します。 Yahoo! ユーザーがダウンロードの完了を待たずに作業できるようにページを最適化することにしました。 同時に、彼らは、リソースの重要性と優先度、より早くダウンロードできるもの、後でダウンロードできるものを正確に理解する必要がありました。

ブラウザはリソースの読み込みに異なるロジックを使用でき、これがパフォーマンスに影響する可能性があることを忘れないでください。 場所に加えて、WebPageTestではブラウザーとそのバージョンを選択できるため、最新のすべてのブラウザーでアプリケーションのパフォーマンスを評価できます。

ネットワーキングは、ページやアプリケーションの最適化のテストに役立つ強力なツールです。 以前のリソースグラフは、多くの場合、アプリケーションのフロントエンド分析と呼ばれます。 しかし、これは多くの人にとって誤解を招きます。 これは、パフォーマンスの問題全体がクライアントのみにあることを示している場合があります。 ただし、JS、CSS、およびレンダリングプロセスは重要で時間がかかりますが、パフォーマンスを最適化するには、サーバーの応答に取り組み、ネットワークの待ち時間を短縮することも同様に重要です。 最終的に、コンテンツの最適化にどれだけの労力を費やしても、リソースがネットワーク上で利用できない場合、これはほとんど役に立ちません！

これを実証するために、WebPageTestからグラフの接続ビューに移動します。


ネットワークビュー（接続ビュー）Yahoo.com

各エントリが特定のHTTP要求を記述するリソースグラフとは異なり、ネットワーク図には各TCP接続が表示されます。 この例では、30個すべてがYahooホームページのリソースをロードするために使用されています！..何かが際立っていますか？ 青色で強調表示されている起動時間は、合計接続時間のほんの一部にすぎないことに注意してください。 15個のDNSルックアップ要求があり、TCP接続が30回開かれ、応答の最初のバイトを待機することにより多くのネットワーク遅延が発生したことがわかります。

最後に、最も興味深いものを残しました。 多くの人にとって本当の驚きは、ネットワークの最下部にあるものかもしれません。帯域幅の使用が考慮されています。 いくつかの短いパケットを除いて、使用可能なチャネルの使用は非常に重要ではないように見えます。チャネルの帯域幅に制限されません。 これは異常ですか、それともブラウザのエラーですか？ 残念ながら、正しい答えは1つではありません。 チャネル幅によって制限されないことがわかります。 問題は、クライアントとサーバー間の遅延です。

効率の柱：コンピューティング、可視化、配布

Webアプリケーションの実行には、主に3つのタスクが含まれます。リソースの取得、ページの構築とレンダリング、およびJavaScriptの実行です。 視覚化とスクリプト実行の段階は、シングルスレッドの交互実行モデルに従います。 結果のドキュメントオブジェクトモデル（DOM）を並行して変更することはできません。 したがって、「DOM、CSSOM、およびJavaScript」で見たように、同時に機能するスクリプトの視覚化と実行としての最適化が重要です。

ただし、ブラウザがネットワーク上でブロックされ、リソースの配信を待機している場合、JavaScriptおよび視覚化パイプラインの実行の最適化も完全には機能しません。 ネットワークリソースの高速で効率的な配信は、すべてのブラウザベースのアプリケーションのパフォーマンスの基盤です。

インターネットの速度は日々速くなっているので、この問題自体は解決されないのでしょうか？ はい、私たちのアプリケーションは大きくなっていますが、グローバルな平均速度がすでに3.1 Mbps（「ネットワークの端の帯域幅」）であり、成長し続けている場合、何を心配しますか？ 残念ながら、ご想像のとおり、Yahoo！の例が示すように、もしそうであれば、この記事は読みません。 よく見てみましょう。

高スループットは重要ではありません（大きい）

あなたの馬を保持します！ もちろん、帯域幅の問題は重要です！ 特に大量のデータ転送（ビデオやストリーミングオーディオ、またはその他の種類の大量のデータ転送）を伴う場合には、より高いデータ転送速度へのアクセスが常に良好です。 ただし、数十の異なるホストからの数百の比較的小さなリソースの交換を必要とする日々のWebブラウジングに関しては、両方向の遅延が制限要因です。

Yahoo!ホームページからの高解像度ストリーミングビデオ 制限された帯域幅。 Yahoo!ホームページの読み込みと視覚化 遅延に制限されます。

再生しようとしているビデオの品質とエンコードに応じて、数百キロビットから数Mbpsの帯域幅が必要になる場合があります。たとえば、HD 1080pビデオストリームの場合は3 Mbps以上です。 Netflixなどのストリーミングビデオサービスの人気が高まっていることからも明らかなように、このデータ転送速度は多くのユーザーの手の届く範囲にあります。 では、なぜ、非常に小さなWebアプリケーションをダウンロードすることが、高解像度の映画をストリーミングできる接続にとってこのような問題になるのでしょうか？

パフォーマンスのネックのような遅延

SPDYプロトコルの作成者の1人であり、HTTP 2.0プロトコルの開発者の1人であるMike Belsheによって行われたチャネル帯域幅と遅延の変化に応じたページ読み込み時間の定量分析の結果を見てみましょう。


最初のテストでは、ページの読み込み遅延はほぼ一定ですが、チャネル帯域幅は毎秒1メガビットから10メガビットに増加します。 チャネルを1メガビットから2メガビットにアップグレードすると、ダウンロード速度が大幅に向上することに注意してください。 5メガビットから10メガビットへのアップグレードでは、反復あたり5％のダウンロードアクセラレーションのみが提供されます。

それにもかかわらず、遅延の実験ではまったく異なる状況が示されています。20ミリ秒の遅延ごとに、ページの読み込み速度が直線的に低下します。

インターネット全体を高速化するには、待ち時間を短縮する方法を検討する必要があります。 大西洋をまたぐ遅延を150ミリ秒から100ミリ秒に短縮できるとしたらどうでしょうか？ これは、チャネルの帯域幅を3.9 Mbpsから10に、または最大でギガビットに増やすよりも、インターネットアクセスの速度に大きな影響を与えます。 ページの読み込み時間を短縮するもう1つの方法は、ページの読み込みに必要なリクエストの数を減らすことです。 現在、Webページでは、クライアントとサーバーの間でかなりの数の接続が必要です。 ラウンドトリップリクエストの数は、クライアントとサーバー間の通信を開始するための公式のデータ交換（DNS、TCP、HTTPなど）に大きく関連しており、これは、たとえばTCPの起動が遅いなどの影響も受けます。 より少ない接続でデータを転送するためのプロトコルを改善できれば、ページの読み込み速度を上げることもできます。 これはSPDYの目標の1つです。
マイク・ベルシェ。

示されている結果は多くの人にとって驚くべきものですが、TCP、フロー制御と調整、パケット損失によるブロッキングなどのプロトコルパフォーマンス特性の直接的な影響の結果であるため、そうすべきではありません。 ほとんどのHTTPデータストリームには、小さな脈動するデータ伝送が含まれていますが、TCPは、長寿命の接続とパケットデータ用に最適化されています。 ネットワーク遅延は、HTTPおよびその上で実行されるほとんどのWebアプリケーションのボトルネックでもあります。

遅延がほとんどの有線接続の制限要因である場合、無線クライアントにとってそれらが果たす重要な役割を想像してください。通常、無線遅延は高く、ネットワークの最適化はWebパフォーマンスにとって非常に重要です。

合成およびカスタムパフォーマンステスト

何かを測定できる場合は、改善できます。 問題は、正しい測定基準が選択されており、プロセスが徹底されているかどうかです。 前述したように、最新のWebアプリケーションのパフォーマンスを測定することは簡単な作業ではありません。アプリケーションごとに同じままである共通のインジケーターはありません。つまり、個々のケースで特別なインジケーターを慎重に決定する必要があります。 次に、基準が選択されたら、パフォーマンステスト情報を取得する必要があります。これは、合成テストとユーザーテストの組み合わせを使用して行われます。

一般的に、合成テストは、制御された測定条件下のプロセスに適用されます：ローカルアセンブリプロセスは、パフォーマンステストソフトウェアを通じて起動され、負荷は、一連のスクリプトアクションとログ出力を定期的に起動する中間インフラストラクチャまたは地理的に分散したサーバーのセットに対してテストされます。 これらのテストはそれぞれ、インフラストラクチャのさまざまな部分（アプリケーションサーバーの帯域幅、データベースパフォーマンス、DNSタイミングなど）をテストでき、特定のシステムコンポーネントのパフォーマンス低下を判断するための安定した基盤として機能します。

適切に調整された合成テストは、制御された再現可能なテスト環境を提供し、エンドユーザーに到達する前にパフォーマンスの低下を検出および修正するのに適しています。 ヒント：総合テストの一環として、主要業績評価指標を特定し、それぞれに「予算」（容量）を割り当てます。 「予算」を超えた場合は、アラームを鳴らしてください！

ただし、すべてのパフォーマンスのボトルネックを特定するには、総合的なテストでは不十分です。 より具体的には、問題は、得られた測定値が、アプリケーションでの実際のユーザーエクスペリエンスを決定するさまざまな実際の要因を反映していないことです。

いくつかの要因が含まれます：

• シナリオとページの選択：実際のユーザーのナビゲーションパスをコピーすることは困難です。
• ブラウザーキャッシュ：パフォーマンスは、ユーザーのキャッシュによって大きく異なる場合があります。
• 仲介者：パフォーマンスは、中間プロキシとキャッシュによって異なる場合があります。
• さまざまなハードウェア：幅広いCPU、GPU、およびメモリパフォーマンス。
• さまざまなブラウザー：幅広いブラウザーバージョン（新旧）。
• 接続：実際の接続の速度と頻度は常に変化します。

, , (real-user measurment, RUM), . , W3C Web Perfomance Working Group , API (Navigation Timing Api), .


Navigation Timing

Navigation Timing , , DNS TCP ( ) perfomance.timing .

, : , . , , , , .

, : , . , .


igvita.com

: (2 ).

, . Google, . Navigation Timing ( ), . , , Navigation Timing.

, W3C Performance Group API — User Timing ( ) Resource Timing ( ). Navigation Timing , Resource Timing , . , User Timing JavaScript API , , :

function init() { performance.mark("startTask1"); 1 applicationCode1(); 2 performance.mark("endTask1"); logPerformance(); } function logPerformance() { var perfEntries = performance.getEntriesByType("mark"); for (var i = 0; i < perfEntries.length; i++) { 3 console.log("Name: " + perfEntries[i].name + " Entry Type: " + perfEntries[i].entryType + " Start Time: " + perfEntries[i].startTime + " Duration: " + perfEntries[i].duration + "\n"); } console.log(performance.timing); 4 } 

1.マークを関連する名前で保存します。
2.アプリケーションコードを実行します。
3.測定データを繰り返し記録します。
4.特定のページのナビゲーションタイミングオブジェクトを表示します。

ナビゲーション、リソース、およびユーザータイミングAPIの組み合わせは、リアルタイムパフォーマンスを測定するために必要なすべてのツールを提供します。あなたが何か間違ったことをした理由についての言い訳はなくなりました。 測定対象を最適化します。 合成テストとRUMはオプションのアプローチであり、パフォーマンスの問題領域をすべて特定し、ユーザーがアプリケーションをどのように認識しているかを知るのに役立ちます。

堅牢なパフォーマンス最適化戦略を作成するには、カスタムおよびアプリケーション固有のメトリックが重要です。 ユーザーエクスペリエンスの品質を測定および決定する普遍的な方法はありません。 代わりに、アプリケーションごとに、アプリケーション開発の特定の段階を決定する必要があります。 このプロセスには、プロジェクトのすべての関係者（所有者、設計者、開発者）間の協力が必要です。

ブラウザの最適化

最新のブラウザは単純なソケットマネージャ以上のものであることは言うまでもありません。 パフォーマンスは、ブラウザの競争上の利点の1つです。 したがって、ブラウザが日々賢くなっていることは驚くことではありません。 可能性のあるDNSの検索の事前解決、可能性のあるホストへの事前接続、ページ上のリソースの事前選択と優先順位付けなど。

実行の正確なリストはブラウザによって異なりますが、これらはすべて2つの大きなクラスに分けることができます。

ドキュメント対応の最適化

ネットワークプロトコルスタックはドキュメントに統合されています。 Html、css、jsの解析は、重要なネットワークリソースに優先順位を付け、それらを以前にダウンロードし、インタラクティブパーツを含むページをできるだけ早く取得するのに役立ちます。 多くの場合、これは優先リソースのリストに基づいて行われ、予備解析および同様の方法を使用します。

投機的最適化

ブラウザは、時間の経過に伴うユーザーナビゲーションパターンを認識し、推測的な最適化を実行して、DNSを事前に解決したり、可能性のあるホストに事前に接続したりするなど、ユーザーの考えられるアクションを予測します。

幸いなことに、これらの最適化はすべて私たちに代わって自動的に実行され、その助けを借りて最大で数百ミリ秒節約できることがよくあります。 これがどのように、なぜこのように機能するのか、そしてブラウザーがWebアプリケーションをさらに高速に読み込む方法を理解することが重要です。

ほとんどのブラウザで使用される4つの方法があります。

リソースの予備選択とそれらのロードの優先順位付け

HTML、CSS、およびJSは、ネットワークスタックの追加情報を送信して、各リソースの相対的な優先度を報告できます。他のリソースの受信を許可しないリソースが最初に要求され、優先度の低い要求がキューに入れられます。

高度なDNS解決

ホストは事前に定義できます。これにより、HTTP要求のDNS決定フェーズ中の遅延が回避されます。 ブラウザーは、訪問の履歴、ユーザーのアクション（リンク上でのホバーリングなど）を分析することにより、ホストアドレスを学習できます。

TCP接続を開く

ドメインをホストIPにバインドした後、ブラウザーは最初にTCP接続を開き、HTTP要求を待機します。 接続が確認されたら、同じ方法でTCPハンドシェイクを行うことができます。

予備レンダリング

一部のブラウザでは、非表示のタブにページを描画できます。ユーザーがリクエストを開始すると、タブは非表示になりません。

外部では、最新のブラウザのネットワークスタックはコンテンツを受信するための単なるメカニズムではなく、内部から見ると複雑で魅力的なケースであり、その研究はWebパフォーマンスの最適化に役立ちます。

ブラウザをどのように支援できますか？ まず、各ページの構造に注意を払う必要があります。

• CSSやJSなどのリソースをできるだけ早く提供する必要があります。
• レンダリングとJavaScript実行のロックを解除するには、できるだけ早くCSSを指定する必要があります。
• DOMとCSSOMのアセンブリをブロックすることを避けるために、JavaScriptを後ほど与える必要はありません。
• HTMLは徐々に解析されるため、パフォーマンスを向上させるためにドキュメントを定期的にクリーニングする必要があります。

これらすべてに加えて、追加の最適化の必要性についてブラウザに警告できる追加のヒントをブラウザに残すことができます。 ブラウザは私たちに代わって必要なすべてを行います：

 <link rel="dns-prefetch" href="//hostname_to_resolve.com"> 1 <link rel="subresource" href="/javascript/myapp.js"> 2 <link rel="prefetch" href="/images/big.jpeg"> 3 <link rel="prerender" href="//example.org/next_page.html"> 4 

1.ホスト名の事前承認。
2.ページの後半に投稿された重要なリソースをプリロードします。
3.現在または将来のナビゲーションのためのリソースのプリロード。
4.特定のページの事前レンダリング、次のユーザーアクションの予測。

これらのヒントはそれぞれ、投機的な最適化を思い出させます。 ブラウザは、これらのプロンプトが必須であることを保証できませんが、プロンプトを使用して戦略とロジックを改善できます。 残念ながら、すべてのブラウザがこれらの機能をサポートしているわけではありません。

ほとんどのユーザー、さらにはWeb開発者にとっても、DNS、TCP、およびSSLの遅延は深刻なものではなく、ネットワークレベルで克服されます。 それでも、これらの各ステップは、ユーザーエクスペリエンス全体にとって非常に重要です。ネットワーク経由でアクセスするたびに、数十または数百ミリ秒のネットワーク遅延が追加されるためです。 ブラウザーがこれらのことを予測できるようにすることで、問題のある領域に対処し、Webアプリケーションをはるかに高速かつ適切にダウンロードできます。

Google検索の最初のバイトまでの時間を最適化する

HTMLドキュメントは徐々に解析されます。 これは、サーバーがマークアップドキュメントをできるだけ頻繁にクリアできることを意味します。 これにより、クライアントは逃した重要なリソースにすばやく移動できます。

Google検索は最良の例の1つです。 クライアントブラウザーがヘッダーレイアウトを解析する間、検索クエリは検索インデックスに送信され、検索結果を含むドキュメントの残りの部分は、結果の準備ができ次第ユーザーに配信されます。 この時点で、ログインしているユーザーの名前など、ヘッダーの動的な部分はJavaScriptを使用して読み込まれます。

InfoboxおよびInfoboxCloudの使用に成功！ サイトとアプリケーションを迅速かつ確実に機能させましょう！