トップ > テクニカルSEO > Lighthouseの使い方：スコアの見方とINP時代の改善手順

Lighthouseの使い方：スコアの見方とINP時代の改善手順

テクニカルSEO

GoogleのLighthouseは、ウェブページの品質を自動監査するオープンソースツールであり、Core Web Vitals（CWV）の指標、特にInteraction to Next Paint（INP）を最適化する鍵となります。INPはユーザーの体感速度を測り、良好な基準は200ms未満です。

本記事では、Lighthouseの実行方法（DevTools、PageSpeed Insights、CLI、CI）、スコアの読み方、INP対応の改善手順を初心者にもわかりやすく解説。即効施策やチェックリストも提供し、上位表示を目指します。

INPについてはこちらの記事をご覧ください！

Lighthouse（ライトハウス）とは？

Lighthouseは、ウェブページの品質（パフォーマンス、SEO、アクセシビリティなど）を自動診断するツールで、Chrome DevTools、CLI、Node、CIで実行可能です。

  • PageSpeed Insights（PSI）との違い

    • Lighthouse：主にラボデータ（シミュレーション環境での測定）。

    • PSI：ラボデータ＋CrUX（実ユーザーデータ）を統合。チーム共有に便利。

  • ポイント：ラボデータで問題を特定し、CrUXで実ユーザー体験を確認する両輪アプローチが重要です。

出典：Lighthouse の概要  |  Chrome for Developers

実行方法4パターン

Lighthouseは用途に応じて4つの実行方法があります。
初心者はDevToolsから始めるのが簡単なのでおすすめです。

  1. DevTools版

    • ChromeでF12→「Lighthouse」タブ→「Run Audit」。

    • モバイル/デスクトップ切り替え可能。ネットワーク速度やCPUスロットリングに注意。

  2. PageSpeed Insights（PSI）経由

    • PSIにURLを入力。

    • ラボデータ（Lighthouse）＋CrUXデータを取得。レポート共有が容易。

  3. CLI版

    • コマンド：npm install -g lighthouse→lighthouse https://example.com --output html --output-path report.html

    • 再現性ある計測に最適。CI前提の運用に推奨。

  4. Lighthouse CI（LHCI）

    • プルリクエストごとに自動監査。しきい値（例：Performanceスコア80以上）に達しない場合、ビルドを失敗させる。

    • 例：GitHub Actionsで設定（後述のスニペット参照）。

出典：Lighthouse: ウェブサイトを最適化する  |  Chrome DevTools

スコアの見方：何が何点に効く？

LighthouseのPerformanceスコアは、主要指標の加重平均で計算しています。診断や機会は直接スコアには影響しませんが、改善の優先度を示しているので参考にしましょう。

  • 主要指標とウェイト

    • LCP（Largest Contentful Paint）：25%、2.5秒未満が良好。

    • CLS（Cumulative Layout Shift）：25%、0.1未満が良好。

    • INP（Interaction to Next Paint）：30%、200ms未満が良好。

    • TBT（Total Blocking Time）：20%、長タスクの合計時間。

    • 速度指数（Speed Index）：残りを補完。

  • 診断（Diagnostics）
    メインスレッドの負荷や未使用JS/CSSなど、具体的な問題点。

  • 機会（Opportunities）
    改善による時間短縮の見積もり
    （例：「画像最適化で0.5秒短縮」）。

図解例

SEO日報のある記事ページのスコアは上記の通りですが、改善の余地はかなりあります。今後改善してまいります。

まずこれだけ：スコアが“今すぐ”上がる順

ここでは、はてなブログユーザー向けに、INP/LCP/TBTを即改善する施策を優先順に紹介いたします。

  1. 画像リサイズ＆次世代形式

    • 画像をWebP/AVIFに変換、最大幅1200pxに圧縮。

    • <img fetchpriority="high">でファーストビュー画像を優先。

    • 例：<img src="image.webp" fetchpriority="high" width="800" height="450">

  2. 不要スクリプトの削除、タグマネ最適化

    • 不要なウィジェット（例：SNS埋め込み）を削除。

    • Google Tag Managerの発火条件を厳格化（例：スクロール50%で実行）。

  3. フォントの先読みと表示フォールバック

    • システムフォント優先（例：font-family: system-ui）。

    • カスタムフォントは<link rel="preload" href="font.woff2">で読み込み。

  4. ファーストビュー要素の優先

    • 重要なUI（メニュー、検索）にpreloadやfetchpriority="high"を適用。

    • 例：<link rel="preload" href="menu.js" as="script">

INP時代の考え方：TBT→INPを連動で改善

INPはユーザーのインタラクション応答性を測る指標です。
TBT（長タスク時間）の削減がINP改善に直結するので、まず改善しましょう。

  1. 長タスク(>50ms)の分割

    • 重い処理をrequestIdleCallbackやsetTimeoutで分割。

    • 例：

      function heavyTask(data) {
  const chunk = data.slice(0, 100);
  processChunk(chunk);
  if (data.length > 100) setTimeout(() => heavyTask(data.slice(100)), 0);
}
requestIdleCallback(heavyTask);

  2. イベントハンドラの軽量化

    • イベントデリゲーションで処理を効率化。

    • 例：

      document.body.addEventListener('click', (e) => {
  if (e.target.matches('.cta-button')) handleCTA(e.target);
});

  3. サードパーティの同期JS排除

    • 広告やトラッキングスクリプトをasync/deferで遅延。

    • 例：<script src="ads.js" async></script>

  4. Web Workerで重処理を隔離

    • 例：

      const worker = new Worker('heavy-task.js');
worker.postMessage(data);
worker.onmessage = (e) => console.log(e.data);

  5. UI重要動線の初回応答保証：

    • メニューや検索ボタンのJSを優先読み込み（fetchpriority="high"）。

Lighthouseレポートの読み方

Lighthouseレポートの「Opportunities」「Diagnostics」「Passed Audits」を項目別に読み解く方法をご紹介します。

  • Opportunities

    • 例：「画像最適化で0.5秒短縮可能」。

    • 工数対効果マトリクス：

      施策

      影響時間

      工数

      優先度

      画像WebP化

      0.5s

      低

      高

      JS軽量化

      0.3s

      高

      中

  • Diagnostics

    • メインスレッド負荷（例：長タスク50ms超）。

    • ネットワークリクエスト数（例：100超は削減）。

    • 未使用JS/CSS（例：bundle.jsの30%が未使用）。

  • Passed Audits

    • 維持対象。例：LCPが2.0秒なら次回も同等を確保。

    • バージョン更新時にリグレッション確認。

例

レポート例（2025-10-19）
Opportunities：画像最適化（0.5s短縮）、JS圧縮（0.2s短縮）
Diagnostics：長タスク3件（60ms超）、未使用CSS 20%
Passed：LCP 2.0s、CLS 0.05

再現性ある計測のコツ（誤差を減らす）

Lighthouseのスコア変動を抑えるには、計測条件を固定することが重要です。
下記条件によって誤差を減らすようにしてください。

  1. 環境設定

    • 拡張機能を無効、シークレットウィンドウ使用。

    • 安定したネットワーク（例：Wi-Fi固定）。

  2. 複数回計測

    • 3回以上の中央値を採用。

    • 同一端末・同一条件で実施。

  3. CLIでスロットリング固定

  4. CIでしきい値管理

    • LHCIでPerformanceスコア80以上を設定。

    • 例（GitHub Actions）：

      name: Lighthouse CI
on: [pull_request]
jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm install -g @lhci/cli
      - run: lhci autorun --upload.target=temporary-public-storage

よくあるQ&A

  • Q. PSIとDevToolsの結果が違うのはなぜ？
    A. PSIはフィールドデータ（CrUX）とラボデータ（Lighthouse）の統合、DevToolsはラボのみ。計測条件（端末、ネットワーク）も影響。→条件を固定して比較。

  • Q. スコアが急落したのはなぜ？
    A. Lighthouseのバージョン更新（重み付け変更）や計測条件の変動が原因。まず同一条件で再計測。

  • Q. 何点なら“合格”？
    A. INP<200ms、LCP<2.5s、CLS<0.1を満たす。Performanceスコア80以上が目安。

チェックリスト（参考）

以下のチェックリストでLighthouse運用を確認してみてください。

まとめ

Lighthouseは、INPを含むCore Web Vitalsの最適化を効率化する強力なツールです。DevTools、PSI、CLI、CIを使い分け、スコアの読み方を理解し、画像最適化や長タスク分割などの即効施策を進めましょう。

はてなブログユーザーでも実践可能なテンプレートとチェックリストを活用し、定期的な計測でINP<200msを目指してください。まずはDevToolsで初回計測をスタートしましょう！

関連記事