Web パフォーマンスの最適化: ウォーターフォール グラフについて

ウォーターフォール チャートは、リソース間のシーケンスと依存関係を確認する機会を与えるタイムラインで、エンジンによって解析された Web サイト リソースのダウンロード方法を表す図です。 ロードプロセス中に重要なイベントが発生した場所を特定するのには支援します。 また、ユーザーは自分のウェブサイトのパフォーマンスがどれほど良いか悪いかを簡単に見せることができ、サイトの速度が低下しているものを正確に示すことができます。

Dotcom-Monitorプラットフォーム内のウォーターフォール グラフを使用すると、ページの読み込みプロセス中に発生した重要なイベントをユーザーが識別できます。 ウォーターフォールチャートでは、いくつかのタスクに連鎖的な効果が表示され、数秒のうちに、ユーザーは、並列ダウンロードをブロックしているリソースの数や、存在する行数など、Webサイトのパフォーマンスがどれほど悪いか、または良好であるかを確認できます。 ユーザーはデバイス上にサマリーを持ち、円グラフ上のデバイス統計の説明的な視覚化を行います。 ユーザーは、実際の URL 読み込みビデオをブラウザウィンドウで見ることもできます。

以下のスクリーンショットは、滝チャートの外観を紹介する amazon.com のウォーターフォールチャートのサンプルです。 ご覧のとおり、ページの読み込み時間中にさまざまな要素が表示されます。 これらの要因には、次のようなものがあります。

• URL
• テストの場所
• ブラウザ(クローム、Firefox、インターネットエクスプローラ、モバイルブラウザなど)
• 接続
• テストの数
• ビューを繰り返す

ウォーターフォール チャートで使用される要素

インタラクティブスライダー:インタラクティブスライダーは、ミリ秒の点で各要素のパフォーマンスの指標です。 下の画像では、矢印で指しています。 ユーザーは、インタラクティブスライダーをドラッグして、どの要素がロードされているか、どの時点で読み込まれているかを確認できます。 このスクリーンショットでは、ハイライトされた要素が 531 ミリ秒で読み込まれていることがわかります。

[時間グリッドの読み込み]: 下のハイライト表示領域は、ロード時間グリッドと呼ばれます。 各要素の読み込みにかかる時間を示します。

要素リスト: Web ページに存在する要素が要素リストに表示されます。 要素の拡張子は、HTML、CSS、GIFなどです。

要素のパフォーマンス: ウォーターフォール チャートに存在する各要素のパフォーマンスの情報に到達できます。

ユーザーが特定の要素ボタンをクリックすると、次に示すパフォーマンス ページが表示されます。

パフォーマンス ページを分析することで、ユーザーは応答の詳細についてより深い知識を持ちます。 彼らは、所望のを選択し、詳細を表示するためにマウスボタンを離すことができます。 また、ユーザーは、パフォーマンスの低下期間があることを意味する 赤いマークの領域に注意を払って、パフォーマンスの問題を観察することができます。

個々の要素の時間の詳細を読み込む: ウォーターフォール チャートでは、ユーザーが特定のバーにカーソルを移動すると、読み込み時間の詳細が表示されます。

カラーコーディングの説明: Dotcom Monitor プラットフォーム内では、ロード時間の詳細の表現は次の色で定義されます。

ナビゲーションタイミング: ウォーターフォール チャートにナビゲーションの開始、リダイレクトの開始、リダイレクトの終了、フェッチ開始、ドメイン ルックアップの開始、ドメイン ルックアップの終了、接続の開始、セキュリティで保護された接続の開始、接続の終了、接続の終了、要求の開始、イベントの開始のアンロード、イベントの終了、DOM の読み込み、DOM インタラクティブ、DOM コンテンツの読み込みイベントの開始を示す列として表示できます。、DOM コンテンツ読み込みイベント終了、DOM 完了、ロード イベント開始、およびロード イベント終了 (赤い楕円形の下に示す) の色分け。

Dotcom Monitor プラットフォーム内には、ユーザーがブラウザウィンドウで実際の URL 読み込みビデオを見ることができる機能があることを示す必要があります(以下を参照)。

ウォーターフォール チャートを理解して Web パフォーマンスを最適化する

Web サイトのパフォーマンスとスピードは、大きな役割を果たします。 Web サイトの速度が十分でない場合、ユーザーは読み込みが完了するまで待つ必要はありません。 高速なウェブサイトは、コンバージョン率を増加させ、検索エンジン上でのパフォーマンスを向上させます。 ウェブサイトの速度を理解するために、ウォーターフォール図が使用されます。 ウォーターフォール グラフは、問題の原因を特定するのに役立ち、Web ページの速度低下を診断するのに最適な方法です。

ウォーターフォール チャートでは、1MB を超えるファイルのサイズを見ると、サイトが遅くなる可能性があります。 ウォーターフォールチャートのタイムラインの助けを借りて、ユーザーはリソースの読み込みの 異なるフェーズ を発見し、どのフェーズが自分のウェブサイトを遅くするかを理解することができます。 いくつかのフェーズを以下に示します。

• 受信する . ファイルのダウンロードにかかる時間。 これはタイムラインの最初のフェーズです。 最適化されていない画像などの大きなファイルは、ダウンロード時間を遅らせ、より多くの帯域幅を吸収し、Web サイト上で遅延を引き起こします。 この問題の解決策は、ユーザーが品質を低下させることなく、画像のサイズを小さくしてメディアを最適化する必要があります。 帯域幅の可用性を高めるには、ユーザーはクラウド サーバー上にイメージを保持する必要があります。
• 待ち時間. 応答を生成するためにサーバーによってキャプチャされた時間。 待ち時間が長すぎる場合は、ネットワーク サーバーが過負荷になっているか、非効率的なコードが存在する可能性があります。 また、キャッシュユーティリティは、待ち時間を短縮することができます。 その場合、ユーザーは共有ホスティングから専用ホスティングに移行する必要があります。
• キューに置かれた要求: HTTP/HTTP2、HTTP認証、CSSまたはJavaScriptの実行、SSL接続時間で構成される便利な接続は、タイムラインの重要な段階です。
• DNS ルックアップ: DNSが解決する時間で構成され、ユーザーにウェブサイトの速度を低下させている大きな手がかりを与えます。 一般に、スクリプトのほとんどは、DNS参照のためにウェブサイトを遅くしています。

ウォーターフォール チャートの助けを借りて Web ページの速度を低下させている問題をユーザーが特定すると、問題の解決策を考え出すことができます。 問題とその解決策の一部を以下に示します。

初心者のユーザーでも、ウォーターフォールチャートを観察することで、ウェブサイトの速度が低下している具体的な理由をすぐに理解できます。 たとえば、長いバーは、関連する要素の読み込みに時間がかかりすぎることを意味し、赤色のテキストはデータをフェッチする際にエラーを意味し、バー間の長い間隔は要求がない時間を意味します。

ウェブサイトの読み込みを高速化する方法

ウォーターフォールチャートを使用することで、Webページの読み込みを高速化することで、優れたユーザーエクスペリエンスを実現できます。

滝の幅を狭くする

ウェブサイトのパフォーマンスは、ウォーターフォールチャートの幅を縮小するリードリソースをダウンロードするのにかかる時間を短縮することによって改善することができます。

滝チャートに長い紫色のバーがある場合
. 紫色は、SSL/TLS ネゴシエーションの実行に費やされた時間を意味します。 ユーザーが継続的に紫色に直面している場合、それはウェブサイトがTLSのために最適化されていないということを意味します。 ユーザーは TLS パフォーマンスを最適化する必要があります。

滝チャートにオレンジがたくさんある場合。 オレンジは、ウェブサイトに対して行われた最初のTCP接続を意味します。 特定のホスト名に対する 2 ~ 6 の要求のみが TCP 接続を作成する必要があります。 2 ~ 6 の要求の後、既存の接続が再利用されます。 ユーザーがオレンジ色の多い場合、Web サイトが永続的な接続を使用しないことを理解する必要があります。 永続的な接続が行われると、Webブラウザがすべてのリクエストで新しい接続を行うわけではないので、すべてのリクエストの幅は半分になります。

滝チャートに長い青いバーがある場合
. 青色は、応答のダウンロードに費やされた時間を意味します。 青い長いバーがある場合は、リソースが大きすぎるためである可能性が高くなります。 ファイルのサイズを小さくすると、問題を解決できます。 ユーザーは、画像の最適化または HTTP 圧縮によってサイズを小さくすることができます。

緑が多すぎる場合は、ウォーターフォールチャート
. 緑色は、ブラウザがコンテンツの取得を待機中であることを示します。 緑を減らすには、ユーザーは静的コンテンツを CDN に移動する必要があります。

ウォーターフォール グラフの高さを下げる

Web ページを読み込むためにブラウザが実行する必要がある要求の数を減らすことで Web サイトの速度を向上させ、滝の高さを減らすことにつながります。 ユーザーは、各ページ内のすべてのコンテンツを確認し、本当に必要かどうかを判断する必要があります。

2kb 未満の JavaScript/CSS ファイルが多すぎる場合
。 ユーザーは、インラインでこれらのファイルの内容を直接 HTML に含める必要があります。 , or

タグ。

ウォーターフォールチャートにJavaScript/CSSファイルが多すぎる場合
. ユーザーは、CMSプラグインまたはビルドプロセスの一部としてそれらを組み合わせる必要があります。 このアクションは、要求の数を減らすと、ページの速度が向上します。

302 リダイレクトが多すぎる場合。

黄色の行はリダイレクトを意味し、ページ上のリンクが誤って作成または古くなっていることを意味し、滝の高さを高める不必要なリダイレクトを作成します。 解決策は、これらのリンクを直接リンクに置き換える方法です。

レンダリング時間を増やす

レンダリング時間を短縮するには、ユーザーはリソース要求の順序を最適化する必要があります。

個別の CSS ファイルに対する要求が多すぎる場合
は、 ブラウザはページのレンダリングを開始する前に、すべての CSS がダウンロードされるまで待機します。 ユーザーは、これらの CSS ファイルをインラインまたは結合する必要があります。

JavaScript ライブラリを読み込む呼び出しが表示された場合
。 JavaScript インクルードは、ページのレンダリングをブロックする可能性があります。 ユーザーは、ページ内でこれらを下に移動する必要があります。

ユーザーに外部フォントが表示される場合
: ブラウザが外部フォントをダウンロードするまでは、何も描画しません。 ユーザーは、外部フォントを使用しないようにする必要があります。

最初の訪問と繰り返し訪問。 もっと重要なことは何ですか?

ユーザーの訪問に基づいて、 最初の訪問 と 繰り返し訪問の 2 種類のウォーターフォール チャートが作成される場合があります。 どう違いますか。

空のキャッシュ (最初のビュー): ユーザーは初めて Web サイトにアクセスし、キャッシュされたデータはありません。 一般的なブラウザベースのツールは、要求を行う前にキャッシュをクリアします。 つまり、初めてウェブサイトを訪れる人たちです。

キャッシュ モード (繰り返しアクセス): ユーザーは 2 回目の Web サイトにアクセスし、ユーザーの視点から 2 回目の訪問をエミュレートします。 言い換えれば、人々は事前にあなたのサイトを訪問したので、今、彼らはあなたのイメージを持っているかもしれない、CSSは、システムがそれらに多くを提供する必要はありませんので、ブラウザで現金化。

下のスクリーンショットでは、最初の訪問滝チャートと繰り返し訪問滝チャートがどのように異なっていることがわかります。

実現する重要なことの 1 つは、空のキャッシュの読み込みに 6.8 秒かかり、キャッシュ モードであるリピートには 1.9 秒かかるということです。

Web サイトのパフォーマンスが良好な場合は、タイミングを比較する点で同じケースになり、キャッシュされたバージョンよりも空のキャッシュに時間がかかります。 その理由は、最初の訪問では、ツールは要求を行う前にキャッシュを空にし、繰り返しの訪問では、システムは、Webサイトをロードする時間を短くするために、ローカルストレージにキャッシュすることができるファイルを持つことになります。

キャッシュ モード (ビューの繰り返し) グラフの行数が少なくて済むため、読み込まれたリソースが少なくなります。 これは、効率的なキャッシュが使用されている Web サイトの良い例です。

サイト上で何も変更しないと、要素がキャッシュされるため、繰り返しの訪問が迅速に応答します。 初めての訪問は、繰り返しの訪問よりも多くの時間がかかります。 Web サイト上で何か問題が発生し、Web サイトが遅くなった場合、ユーザーはそれを修正します。 そして、彼らは再びウェブサイトをテストします。 地理的位置、CDN サーバー、PoP (プレゼンスポイント) などの要素を考慮します。 ウォーターフォールチャートから、どの要素がプロセスを遅くしているかを確認できます。 たぶん、ウェブサイトはあまりにも多くのCPUを使用しています。 修正後、Web サイトを再度テストできます。

ユーザーは、画像やその他のリソースをダウンロードするのにかかる時間を理解しているため、初回の訪問が重要です。 キャッシュ プロセスの後、残りのアイテムの読み込みにかかる時間を評価する必要があるため、繰り返しの訪問も重要です。 さらに、ユーザーは、最初の訪問からウォーターフォールチャートを見て、どのリソースがキャッシュされているかを観察し、繰り返し訪問します。 これにより、ユーザーは Web サイトのパフォーマンスとリソースに関するコンテンツの問題を理解できます。

ウェブサイトの速度を落とす要素を見たいですか? 無料のウェブサイトスピードテストを実行し、ウォーターフォールチャートやパフォーマンスレポートを通じて結果を表示します。

ウォーターフォール チャートを使用して適切な CDN 分布を監視する方法

コンテンツ配信ネットワーク (CDN) は、エンド ユーザーに静的コンテンツを配信するために最適化された、地理的に分散したサーバーのグループです。 この静的コンテンツはほぼすべての種類のデータにできますが、CDN は通常、Web ページと関連ファイル、オーディオ、ストリーミング ビデオ、および大規模なソフトウェア パッケージを配信するために使用されます。

CDN 使用率

CDN のエッジ サーバーは、Web サイトリソースとその訪問者の間のギャップを埋めることによって、速度を向上させます。 ユーザーは、Web サイトの配信元に直接要求を行う代わりに、プロバイダーが持つ複数の CDN 配布プラットフォームに接続します。 リクエストが近づくほど、時間が節約されます。 さらに、CDN ホスティングはファイル圧縮に対応し、ファイル サイズが小さいほど読み込み速度が速くなるため、全体的な参照が向上します。

ウォーターフォール チャートを使用した CDN の監視

下のウォーターフォールチャートのスクリーンショットでは、モニタリングURLエリアは、すべての個々の要素のリストと、そのサイズとパフォーマンスを右側に表しています。

ユーザーが CDN を利用している場合、その 1 つのソースから多数のファイルやリソースが提供される可能性があります。

CDN は必要ですか?

ウォーターフォール チャートを使用すると、ユーザーは遅延が Web サイトの速度にどのような影響を与えているかを検出できます。 記事の前半で色分けされたグラフに戻ると、黄色のバーは Web ブラウザがドメイン ネーム サーバー (DNS) からのデータを待っている状態であることを示します。 一般的に、100msの待ち時間は通常通り受け入れられ、400msは遅いと考えられます。 速度に問題がある場合、ダウンロードに時間がかかりすぎるか、サイズが大きすぎると解釈できます。 さらに、Web サーバーの転送速度が遅すぎることを意味する場合があります。 この特定の問題では、CDN を使用すると、待機時間を短縮する解決策になる可能性があります。

さらに、ユーザーが応答を得るためにあまりにも多くの待ち時間を経験する場合は、Web サイトのコンテンツが訪問者から物理的に遠く離れている可能性があります。 CDN が必要かどうかを判断するには、サーバーの場所を知っている必要があります。 このために、Dotcom-Monitorのようなプラットフォームを利用して、サーバーから最も遠い場所を監視することができます。 ウォーターフォール グラフと、要求とリソースの行を確認します。 待機時間が 100 ミリ秒を超える場合は、CDN の使用を検討する必要があります。

30日間無料で完全なドットコムモニタープラットフォームをお

試しください。