ウェブサイト性能テスト完全ガイド：Lighthouse + Window Performanceで「感覚頼り」の最適化を終わらせる

2024年1月1日 00:00|テクニカルSEO|読了目安：14 分

ウェブサイト性能テスト完全ガイド：Lighthouse + Window Performanceで「感覚頼り」の最適化を終わらせる

ウェブサイトを運営する者として、私たちは皆、ユーザーには快適な体験を、検索エンジンには好意的な評価を求めています。その全ての土台となるのがウェブサイトの性能です。ページの読み込みに時間がかかればユーザーは離脱し、検索エンジンも良い評価を与えてはくれません。特に、多くの人がモバイルデバイスでインターネットを利用し、通信速度が不安定な現代において、ウェブサイトの表示が遅いことはトラフィックを失うことに直結します。

かつては、パフォーマンス最適化はどこから手をつければ良いかわからない「玄学」のようなものでした。しかし現在では、問題を数値化し、ボトルネックを正確に特定するのに役立つ優れたツールが数多く存在します。その中でも、Google Lighthouseとブラウザに標準で搭載されているWindow Performance APIは、最も一般的に使われる2つの「万能ツール」です。

このガイドでは、これら2つのツールを使いこなし、「感覚頼り」の最適化から脱却し、データに基づいたウェブサイト性能とユーザー体験の向上を実現する方法を解説します。

1. なぜパフォーマンスはそれほど重要なのか？（ユーザーと検索エンジンからの二重の圧力）

ツールについて掘り下げる前に、なぜ私たちがパフォーマンスにこだわる必要があるのかを理解しておく必要があります。

  1. ユーザー体験が最優先： 待つことが好きな人はいません。調査によると、ページの読み込みに3秒以上かかると、直帰率は急上昇します。モバイルインターネット環境では、ユーザーは高速なアプリに慣れており、忍耐力はほとんどありません。読み込みが遅い、インタラクションがカクつく、レイアウトがずれるといった問題は、ユーザーを苛立たせ、ページを閉じさせたり、アプリをアンインストールさせたりする原因になります。
  2. 検索エンジンは見ている： Googleはかなり前からCore Web Vitals (CWV) をランキング要因に組み込んでいます。CWVの核となるのは、読み込み速度（LCP）、インタラクティブ性（FID/INP）、視覚的な安定性（CLS）といったユーザー体験です。他の検索エンジンがこれを完全に模倣しているわけではありませんが、SEO業界では、パフォーマンスの高いウェブサイトが良いランキングを得やすいというのが共通認識です。結局のところ、検索エンジンの最終目標もユーザーに良いサービスを提供することなのです。

よくあるパフォーマンスの「落とし穴」:

  • サーバーの応答が遅い（ホスティングの性能不足、データベースのクエリが遅い）
  • CDNの不適切な使用または選定（静的アセットの読み込みが遅くなる）
  • 圧縮や遅延読み込みが行われていない大きな画像や動画
  • 重いフロントエンドフレームワーク、レンダリングをブロックする大きなJS/CSSファイル
  • サイトを遅くする第三者のスクリプト（広告、分析ツール、カスタマーサービスプラグイン）

したがって、パフォーマンスの最適化は選択肢ではなく、必須事項です。

2. Lighthouse：ウェブサイトの「総合健康診断」

Google Lighthouseは、ウェブサイトの「医師」のようなもので、パフォーマンス、アクセシビリティ、ベストプラクティス、SEO、PWA（プログレッシブウェブアプリ）など、複数の側面からスコアを付けてくれます。そして、何がうまくいっていて、どこを改善する必要があるかを示す詳細なレポートを生成します。

Lighthouseの使い方

非常に簡単で、主に3つの方法があります：

  1. Chrome DevTools (F12): 最も便利で一般的な方法です。テストしたいウェブページを開き、F12キーを押してDevToolsを開き、「Lighthouse」タブ（以前は「Audits」）を見つけます。監査したいカテゴリ（例：Performance）とデバイス（Mobile/Desktop）を選択し、「Analyze page load」をクリックするだけです。 Chrome DevTools Lighthouse
  2. Lighthouse Chrome拡張機能： ChromeウェブストアからLighthouse拡張機能をインストールし、アイコンを1回クリックするだけでテストを実行できます。
  3. Node CLI（コマンドラインインターフェース）： 自動テストやCI/CDパイプラインへの統合に最適です。まずNode.jsをインストールし、npm経由でLighthouseをインストール（npm install -g lighthouse）してから、コマンドラインで実行します（lighthouse <url>）。

Lighthouseレポートで何を見るべきか？

レポートは、いくつかの主要な側面についてスコア（0～100）を表示します。スコアが高いほど良いです。ここでは、Performanceスコアとそれに関連する指標に焦点を当てます。

3. Lighthouseパフォーマンス指標の解釈（もう混乱しない）

Lighthouseのパフォーマンスレポートには、色鮮やかな指標や頭字語がたくさん出てきます。心配はいりません、一つずつ解説していきましょう。

Lighthouse Performance Metrics

  1. First Contentful Paint (FCP) - 最初のコンテンツフルペイント： ページ上で最初のDOMコンテンツ（テキスト、画像、SVGなど）がレンダリングされた時間を示します。簡単に言うと、ユーザーが真っ白な画面以外の何かを初めて目にする瞬間です。FCPが短いほど、ページの体感速度は速くなります。
  2. Largest Contentful Paint (LCP) - 最大のコンテンツフルペイント： （Core Web Vitalsの一つ） ビューポート内に表示されている最大の可視コンテンツ要素（通常は画像、動画、または大きなテキストブロック）がレンダリングされるまでの時間を測定します。LCPは、ページの主要なコンテンツが読み込まれた可能性が高い時点を示すため、体感的な読み込み速度を測る重要な指標です。GoogleはLCPを2.5秒未満にすることを推奨しています。
  3. Speed Index (SI) - スピードインデックス： ページの読み込み中に、コンテンツが視覚的にどれだけ速く表示されるかを示す指標です。SIスコアが低いほど、ページコンテンツが速く表示され、よりスムーズな体験に感じられます。
  4. Time to Interactive (TTI) - インタラクティブになるまでの時間： ページが完全にインタラクティブになるまでの時間です。「完全にインタラクティブ」とは、ページがコンテンツを表示するだけでなく、ユーザーの入力（クリックやテキスト入力など）に確実に応答できる状態を指します。TTIが長いと、ユーザーはページが表示されても操作できず、悪い体験につながります。
  5. Total Blocking Time (TBT) - 合計ブロッキング時間： （インタラクティブ性と密接に関連し、Core Web Vitalsの一つ） FCPとTTIの間で、メインスレッドがロングタスク（50ミリ秒以上かかるタスク）によってブロックされた合計時間です。TBTが高いと、読み込み中にページがカクついたり、ユーザーの操作への応答が遅れたりする可能性があります。実際のインタラクションの遅延を測定するFID（初回入力遅延）やINP（次回のペイントまでのインタラクション）などの指標は、TBTの影響を大きく受けます。
  6. Cumulative Layout Shift (CLS) - 累積レイアウトシフト： （Core Web Vitalsの一つ） ページのライフサイクル全体で発生した予期しないレイアウトシフトの合計を測定します。簡単に言うと、画像が読み込まれてテキストが下に追いやられたり、広告が突然挿入されたりして、ページの要素が突然動くことです。CLSスコアが低いほど、視覚的な安定性が高く、ユーザー体験は向上します。GoogleはCLSを0.1未満にすることを推奨しています。

これらの指標の解釈方法

  • 色を見る： レポートでは通常、指標のスコアが緑（良い）、オレンジ（普通）、赤（悪い）で色分けされており、一目で状況を把握できます。
  • 推奨事項を読む： Lighthouseはスコアだけでなく、「未使用のJavaScriptを削減する」「画像を最適化する」「テキスト圧縮を有効にする」といった具体的な最適化の提案（OpportunitiesとDiagnostics）もしてくれます。これらの提案は非常に価値があり、従うことでパフォーマンスを大幅に改善できます。

実践的なヒント： スコアだけを追い求めないでください！スコアが高くても、実際のユーザー体験が良いとは限りません（例えば、ページの主要な機能部分の読み込みが遅いなど）。常にビジネスの目的やユーザーのフィードバックと合わせてレポートを分析しましょう。

4. Window Performance API：パフォーマンス詳細を覗く「顕微鏡」

Lighthouseが提供するのは、ラボ環境でのシミュレーションテスト結果です。包括的ではありますが、実際のユーザー体験とは必ずしも一致しません。一方、ブラウザに標準搭載されているWindow Performance APIを使えば、より現実的で詳細なパフォーマンスデータを取得でき、さらには実際のユーザーのパフォーマンスデータ（リアルユーザーモニタリング、RUM）を収集することも可能です。

Window Performance APIで何ができるか？

このAPIは、JavaScriptコード内でページの読み込みやリソース読み込みに関する詳細なタイミング情報にアクセスするための一連のインターフェースを提供します。

主なAPIの例：

  1. performance.timing: （このAPIは非推奨になりつつありますが、多くの古いコードや記事でまだ使用されています）ページの読み込みのさまざまな段階のタイムスタンプを提供します（例：navigationStart, fetchStart, domLoading, domInteractive, domContentLoadedEventEnd, loadEventEnd）。これらのタイムスタンプの差を計算することで、DNSルックアップ時間、TCP接続時間、白画面の時間、DOM readyまでの時間、総ページ読み込み時間など、さまざまな所要時間を算出できます。 
    1// 例：おおよその初回ペイント時間を計算
2let timing = performance.timing;
3let whiteScreenTime = timing.responseStart - timing.navigationStart; 
4console.log('おおよその白画面の時間:', whiteScreenTime, 'ms');
  2. performance.navigation: ページがどのように読み込まれたか（新規ナビゲーション、リフレッシュ、戻る/進むなど）やリダイレクトの回数に関する情報を提供します。
  3. performance.getEntriesByType(entryType): 非常に便利です！特定のタイプのパフォーマンスエントリを取得します。
    • performance.getEntriesByType('navigation'): Navigation Timing APIからデータを取得します（performance.timingの代替として推奨）。
    • performance.getEntriesByType('resource'): ページで読み込まれたすべてのリソース（JS、CSS、画像、Ajaxリクエストなど）の詳細なタイミング情報を取得します。URL、所要時間、サイズなどが含まれ、サイトを遅くしている特定のリソースを見つけるのに役立ちます。
    • performance.getEntriesByType('paint'): first-paintやfirst-contentful-paintなど、描画関連のタイミングを取得します。
    • performance.getEntriesByType('largest-contentful-paint'): LCPデータを取得します。
    • performance.getEntriesByType('layout-shift'): CLSデータを取得します。
    • performance.getEntriesByType('longtask'): ロングタスクのデータを取得します（TBTの分析用）。
  4. performance.mark(markName)とperformance.measure(measureName, startMark, endMark): コード内にカスタムのタイムスタンプを作成し、所要時間を測定できます。例えば、複雑な計算や特定のモジュールのレンダリングにかかる時間を測定したい場合、開始点と終了点にマークを付け、measureで差を計算します。 
    1performance.mark('startCalculation');
2// ... 複雑な計算を実行 ...
3performance.mark('endCalculation');
4performance.measure('calculationTime', 'startCalculation', 'endCalculation');
5let measures = performance.getEntriesByName('calculationTime');
6console.log('計算時間:', measures[0].duration, 'ms');

Window Performance APIを最大限に活用するには？

  • 文脈に応じた分析： 一般的な指標を見るだけでなく、主要なビジネスフロー（商品詳細ページの読み込み、注文確定など）のパフォーマンスを分析しましょう。
  • データレポートとモニタリング（RUM）： API経由で収集した実際のユーザーのパフォーマンスデータ（LCP、CLS、FID/INP、カスタム測定値など）をモニタリングプラットフォーム（自社開発または第三者のRUMサービス）に送信します。これにより、本番環境のパフォーマンスを継続的に追跡し、広範囲にわたる問題を特定できます。

5. Lighthouse + Window Performance API：最強の組み合わせ？

LighthouseとWindow Performance APIにはそれぞれ長所と短所があります。両者を組み合わせることで、その真価を最大限に発揮できます。

  • Lighthouse（ラボテスト）：
    • 長所： 包括的、標準化されている、詳細な最適化の提案を提供、使いやすい、開発・テスト環境での迅速な診断に最適。
    • 短所： シミュレーション環境であり、実際のユーザー体験とは異なる場合がある。すべてのネットワーク条件やデバイスを完全に再現することはできない。
    • 用途： 開発者のセルフテスト、リリース前のチェック、バージョン間の比較、一般的なパフォーマンス問題の特定、初期の最適化方針の決定。
  • Window Performance API（リアルユーザーモニタリング - RUM）：
    • 長所： 実際のユーザーデータに基づき、実体験を反映。より詳細で長期的なパフォーマンスデータを収集可能。重要なビジネスパスのカスタム測定が可能。
    • 短所： データ収集・分析システムの自社開発（または第三者のRUMサービスの利用）が必要。データ量が多く、分析が複雑になる場合がある。直接的な最適化の提案は提供しない。
    • 用途： 本番環境の実際のパフォーマンス監視、ラボ環境では再現不可能な問題の発見、最適化効果の評価、長期的なパフォーマンストレンドの分析、パフォーマンスとビジネス指標の関連付け。

黄金のワークフロー：

  1. 日々の開発・テスト： Lighthouseを使用して迅速なパフォーマンスチェックと、その推奨事項に基づく初期最適化を行う。
  2. 専門的なパフォーマンス最適化： Lighthouseで主要なボトルネックを特定し、Window Performance APIでリソースの読み込みやロングタスクなどの詳細を分析する。
  3. 本番環境の監視： Window Performance APIを使用して実際のユーザーデータ（RUM）を収集し、主要指標やビジネスフローのパフォーマンスを継続的に監視し、問題があればアラートを出す。
  4. 最適化効果の検証： 最適化をデプロイした後、Lighthouseで変更前後を比較し、RUMデータのトレンドを監視する。

6. 結論：「感覚頼り」を脱し、データでパフォーマンス最適化を推進する

ウェブサイトのパフォーマンス最適化は、もはや勘や当てずっぽうで行う「玄学」ではありません。LighthouseとWindow Performance APIという強力なツールを使えば、以下のことが可能になります。

  • パフォーマンスの数値化： 「速い」「遅い」といった曖昧な感覚を、具体的な指標やデータに変える。
  • ボトルネックの正確な特定： ウェブサイトを遅くしている原因を迅速に見つけ出す。
  • 最適化の指針： 的を絞った最適化作業を行うための、具体的な推奨事項を得る。
  • 効果の検証： データを用いて最適化の効果を評価し、継続的な改善を推進する。

パフォーマンス最適化は継続的なプロセスであることを忘れないでください。ツールはあくまで手段であり、最終的な目標はユーザー体験を向上させ、ユーザーと検索エンジンの両方から信頼を得ることです。

最後の質問です： あなたはLighthouseやWindow Performance APIを使っていて、どんな課題に直面しましたか？あるいは、何か秘伝のテクニックはありますか？ぜひ下のコメント欄で共有してください！