訪問者の目を通してサイトの負荷を確認する
訪問者が Web サイトにアクセスしたときに実際に体験していることをよく理解してください。
ロードが遅い、または場違いなことに気づきましたか? これは、訪問者が経験する重要なラグやコンバージョンの問題を特定するのに役立ちます。
2022 年 10 月の DebugBear ウェブ パフォーマンス テストの結果を示すスクリーンショットタイムライン フィルムストリップは、時間の経過に伴う Web サイトのレンダリングの進行状況を示します。
たとえば、このページは 0.7 秒後にレンダリングを開始し、メイン イメージは 1.3 秒後にレンダリングします。
チャット ウィジェットが 3.7 秒後に表示されると、Web サイトは完全にレンダリングされます。これは Visually Complete とも呼ばれます。
時間の経過に伴う Web サイトのレンダリングの進行状況を示す DebugBear のスクリーンショット、2022 年 10 月ツール内で、レンダリング プロセスのビデオ録画を見ることもできます。
これは、パフォーマンスの問題がクライアントやチームの他のメンバーに与える影響を示す優れた方法です。
2022 年 10 月の DebugBear で部分的にレンダリングされた Web サイトのビデオ録画を示すスクリーンショット実際の読み込み統計を確認して、サイトの速度の変化をテストする
ウェブサイトを最適化しており、それらの変更が影響を与えるかどうかを知りたいとしましょう。
このツールは、最適な環境で「ラボ テスト」を実行して、サイトが正しく最適化されているかどうかを確認します。
サイトをテストすると、公式の「ラボ スコア」が得られます。これは、Google の Lighthouse ツールのパフォーマンス スコアから得られる 6 つのパフォーマンス メトリックの要約です。
- 最初のコンテンツ ペイント (全体スコアの 10%)。
- 速度指数 (10%)。
- 最大のコンテンツ ペイント (25%)。
- インタラクティブになるまでの時間 (10%)。
- 合計ブロッキング時間 (30%)。
- 累積レイアウト シフト (15%)。
このデータを使用すると、前回の最適化がどれほど役に立ったか、何を変更する必要があるかがわかります。
ここまでで、何を変更する必要があるのか疑問に思われることでしょう。 指標の概要の各主要指標を使用して、サイトを最適化する方法を学びましょう。
ウェブサイトの速度を最適化する方法
速度テストの実行は、Web サイト最適化の旅の最初の部分です。
メトリックを取得したら、それらを解釈する方法と、それらを修正するために何をすべきかを知る必要があります。
Web サイトの速度レポートの [メトリックの概要] 領域には、サイトの高速化に役立つ主要なメトリックが表示されます。
- First Contentful Paint : これは、サーバーの通信速度を修復することで高速化できます。
- Largest Contentful Paint : これは、メディアとリソースを最適化することで高速化できます。
さらに、リクエスト ウォーターフォールを使用して、リクエストにかかる時間と、それらの指標への影響を確認できます。
最初のコンテンツ ペイント (FCP) を高速化する方法
あなたのウェブサイトが訪問者により早く表示されるようにすることから始めましょう。 まず、First Contentful Paint に取り組みます。
最初のコンテンツ ペイントとは?
First Contentful Paint は、訪問者がそのページに移動した後、そのページのコンテンツが最初に表示されるまでの時間を測定します。
訪問者が Web サイトを離れないようにするためには、重要なコンテンツがすばやく表示されることが重要です。 ユーザーがウェブサイトを離れるのが早ければ早いほど、Google はページ エクスペリエンスが悪い可能性があることをより早く認識します。
しかし、ウェブサイトの読み込みが遅い原因を正確に知るにはどうすればよいでしょうか?
Web サイトの速度を低下させているサーバーの問題を特定するにはどうすればよいでしょうか? 確認してみましょう。
最初のコンテンツ ペイントに時間がかかるのはなぜですか?
FCP は、サーバー接続速度、サーバー リクエスト、レンダリング ブロック リソースなどの影響を受ける場合があります。
多くのように聞こえますが、FCP の速度を低下させている原因を正確に確認する簡単な方法があります。それは、リクエスト ウォーターフォールです。
この便利なツールは、Web サイトからどのようなリクエストが行われたか、および各リクエストの開始時と終了時を示します。
たとえば、このスクリーンショットでは、最初に HTML ドキュメントのリクエストが表示され、次にドキュメントで参照されているスタイルシートをロードする 2 つのリクエストが表示されます。
2022 年 10 月の DebugBear の最初のコンテンツ ペイント メトリックのデバッグ データを示すスクリーンショット最初のコンテンツ ペイントが 0.6 秒後に行われるのはなぜですか? これを理解するために、ページで何が起こっているかを分析できます。
最初のコンテンツ ペイントの前に何が起こるかを理解する
コンテンツの最初の部分が Web ページに読み込まれる前に、ユーザーのブラウザはまずサーバーに接続してコンテンツを取得する必要があります。
このプロセスに時間がかかる場合、ユーザーが Web サイトを表示するまでに時間がかかります。
目標は、Web サイトの読み込みが始まる前に何が起こっているかを把握して、問題を特定し、エクスペリエンスをスピードアップできるようにすることです。
ページの読み込みパート 1: ブラウザがサーバー接続を作成する
最初にサーバーから Web サイトを要求する前に、訪問者のブラウザーはそのサーバーへのネットワーク接続を確立する必要があります。
これには通常、次の 3 つの手順が必要です。
- DNS レコードをチェックして、ドメイン名に基づいてサーバーの IP アドレスを検索します。
- 信頼できるサーバー接続 (TCP 接続と呼ばれます) を確立します。
- 安全なサーバー接続 (SSL 接続と呼ばれます) を確立します。
これらの 3 つの手順は、ブラウザーによって順番に実行されます。 各ステップでは、訪問者のブラウザから Web サイトのサーバーへの往復が必要です。
この場合、サーバー接続を確立するのに約 251 ミリ秒かかります。
サーバー接続の確立に使用されるネットワーク ラウンド トリップを示す DebugBear スクリーンショット、2022 年 10 月ページ読み込みパート 2: ブラウザーが HTML ドキュメントを要求する (最初のバイトまでの時間はここで発生します)
サーバー接続が確立されると、訪問者のブラウザーは Web サイトのコンテンツを含む HTML コードを要求できます。 これを HTTP リクエストと呼びます。
この場合、HTTP 要求には 102 ミリ秒かかります。 この期間には、ネットワーク ラウンド トリップに費やされた時間と、サーバーが応答を生成するのを待機するために費やされた時間の両方が含まれます。
接続を作成するのに 251 ミリ秒、HTTP 要求を作成するのに 102 ミリ秒が経過した後、訪問者のブラウザーは最終的に HTML 応答のダウンロードを開始できます。
このマイルストーンは、Time to First Byte (TTFB) と呼ばれます。 この場合、合計 353 ミリ秒後に発生します。
サーバー応答の準備が整った後、訪問者のブラウザーは HTML コードのダウンロードにさらに時間を費やします。 この場合、応答はかなり小さく、ダウンロードにはさらに 10 ミリ秒しかかかりません。
HTTP リクエストのさまざまなコンポーネントを示す DebugBear スクリーンショット、2022 年 10 月ページ読み込みパート 3: Web サイトが追加のレンダリングをブロックするリソースを読み込む
ブラウザーは、ドキュメントを読み込んだ直後にページをレンダリングまたは表示しません。 代わりに、通常、追加のレンダリング ブロック リソースがあります。
ほとんどのページは、視覚的なスタイリングがないと見栄えが悪くなります。そのため、ページのレンダリングが開始される前に CSS スタイルシートが読み込まれます。
この Web サイト速度テストの例で 2 つの追加のスタイルシートを読み込むには、137 ミリ秒かかります。
これらのリクエストは、新しいサーバー接続を必要としないことに注意してください。 CSS ファイルは以前と同じドメインからロードされ、既存の接続を再利用できます。
HTML ドキュメントの後に追加のレンダリング ブロック リソースが読み込まれていることを示す DebugBear のスクリーンショット、2022 年 10 月ページの読み込みパート 4: ブラウザーがページをレンダリングする
最後に、必要なリソースがすべて読み込まれると、訪問者のブラウザはページのレンダリングを開始できます。 ただし、この作業にはある程度の処理時間もかかります (この場合は 66 ミリ秒)。 これは、ウォーターフォール ビューのオレンジ色の CPU タスク マーカーで示されます。
HTML ドキュメントの読み込みから Web ページのレンダリングまでの手順を示す DebugBear のスクリーンショット、2022 年 10 月FCP が 632 ミリ秒後に発生する理由がわかりました。
- HTML ドキュメント リクエストの場合は 364 ミリ秒。
- スタイルシートの読み込みに 137 ミリ秒。
- ページのレンダリングに 66 ミリ秒。
- 他の処理作業に 65 ミリ秒。
その他の処理作業には、インライン スクリプトの実行やダウンロード後の HTML および CSS コードの解析などの小さなジョブが含まれます。 このアクティビティは、レンダリング フィルムストリップのすぐ下に小さな灰色の線として表示されます。
First Contentful Paint (FCP) を最適化する方法
Web サイトがレンダリングされる原因がわかったので、最適化の方法を考えることができます。
- サーバーは HTML 要求により迅速に応答できますか?
- 新しい接続を作成する代わりに、同じ接続を介してリソースをロードできますか?
- レンダリングをブロックしないように削除または変更できるリクエストはありますか?
Web サイトの最初の部分の読み込みが早くなったので、今度はサイト全体の読み込みを速くすることに集中しましょう。
DebugBear の推奨事項を使用して、Largest Contentful Paint (LCP) を高速化する方法
LCP を高速化する方法はたくさんあります。
簡単にするために、DebugBear は推奨事項セクション内で次の優れたステップを提供してくれます。
推奨事項の例をいくつか見て、この Web サイトの LCP を高速化する方法を学びましょう。
推奨事項 1: HTML ドキュメントから LCP 画像リクエストを開始する
ページの最大のコンテンツ要素が画像である場合、ベスト プラクティスは、URL が最初の HTML ドキュメントに直接含まれていることを確認することです。 これにより、できるだけ早くロードを開始できます。
ただし、このベスト プラクティスは常に使用されるわけではなく、ブラウザがメイン イメージをダウンロードする必要があることを認識するまでに長い時間がかかる場合があります。
以下の例では、JavaScript を使用して、最大のコンテンツである画像がページに追加されています。 その結果、ブラウザーは、イメージを検出してダウンロードを開始する前に、200 キロバイトのスクリプトをダウンロードして実行する必要があります。
イメージ リクエストに至る一連のリクエスト チェーンを示す DebugBear のスクリーンショット、2022 年 10 月修正方法: Web サイトによっては、2 つの解決策があります。
解決策 1: JavaScript を使用して大きな画像を遅延読み込みする場合は、画像サイズを最適化し、遅延読み込みスクリプトを削除するか、JavaScript を必要としない最新の loading="lazy" 属性に置き換えます。
解決策 2: その他のケースでは、サーバー側のレンダリングにより、ページをレンダリングする前に JavaScript アプリをダウンロードする必要がなくなります。 ただし、これは実装が複雑になる場合があります。
推奨事項 2: LCP イメージが高い優先度で読み込まれるようにする
ページの HTML コードをロードした後、訪問者のブラウザは、メインの画像に加えて、スタイルシートなどの多数の追加リソースをロードする必要があることに気付く場合があります。
ここでの目標は、Google による最大のコンテンツ ペイント要件を満たすために、大きなメイン画像が読み込まれるようにすることです。
サードパーティの分析スクリプトなどの他のリソースは、メインの画像ほど重要ではありません。
さらに、サイトの HTML で参照されているほとんどの画像は、ページがレンダリングされるとスクロールしなければ見えない位置に表示されます。 ネストされたヘッダー ナビゲーションで完全に隠されているものもあります。
このため、ブラウザは最初にすべての画像リクエストの優先度を低に設定しました。 ページがレンダリングされると、ブラウザはどの画像が重要かを判断し、優先度を変更します。 優先度列のアスタリスクで示されているように、下のスクリーンショットでその例を確認できます。
2022 年 10 月、初期優先度の低い LCP イメージが読み込まれていることを示す DebugBear のスクリーンショットウォーターフォールは、ブラウザーが早い段階で画像を認識していたものの、灰色のバーで示されているように、ダウンロードを開始していないことを示しています。
修正方法:これを解決するには、優先度のヒントと呼ばれる新しいブラウザー機能を使用できます。 fetchpriority=”high” 属性を img 要素に追加すると、ブラウザーは最初から画像の読み込みを開始します。
推奨事項 3: CSS を使用してページ コンテンツを非表示にしない
リクエストのウォーターフォールを見ると、すべてのレンダリング ブロック リソースが読み込まれているにもかかわらず、ページ コンテンツが表示されないことがあります。 どうしたの？
A/B テスト ツールは、テストのバリエーションがページのコンテンツ要素に適用されるまで、ページ コンテンツを非表示にすることがよくあります。 このような場合、ブラウザーはページをレンダリングしましたが、すべてのコンテンツは透過的です。
A/B テスト ツールを削除できない場合はどうすればよいですか?
修正方法: A/B テストの影響を受けるコンテンツのみを非表示にするようにツールを構成できるかどうかを確認してください。 または、A/B テスト ツールの読み込みを高速化する方法があるかどうかを確認することもできます。
A/B テスト ツールによってコンテンツが非表示になっているレンダリング フィルムストリップを示す DebugBear スクリーンショット、2022 年 10 月DebugBear でサイトの速度を監視する
ウェブサイトを継続的にテストしたいですか？ 有料の監視ツールを 14 日間の無料トライアルでお試しください。
そうすれば、パフォーマンスの最適化が機能しているかどうかを確認し、サイトのパフォーマンスの低下についてアラートを受け取ることができます.
2022 年 10 月の DebugBear での Web サイトのサイト速度の傾向を示すスクリーンショット
DebugBear の Core Web Vitals データを示すスクリーンショット、2022 年 10 月