Webサイトの品質を改善するとき、表示速度だけを確認して終わってしまうことがあります。

しかし、実際のユーザー体験はパフォーマンスだけでなく、

アクセシビリティ
SEO
セキュリティ
ベストプラクティス

など、複数の要素によって決まります。

こうしたWeb品質をまとめて確認できる便利なツールが Google Lighthouse です。

本記事では、Lighthouseを使ってWebサイトを継続的に改善するための基本的な考え方と、実務で使いやすいチェック方法を紹介します。

Lighthouseとは？

Lighthouseは、Googleが提供するWebページ監査ツールです。

Chrome DevToolsから簡単に実行でき、主に以下のカテゴリを確認できます。

Performance
Accessibility
Best Practices
SEO

環境によっては追加カテゴリが表示されることもあります。

Lighthouseのメリットは、単にスコアを表示するだけではなく、「なぜ評価が低いのか」「どこを改善すればよいのか」を具体的に確認できる点です。

Chrome DevToolsから実行する

Chromeで対象ページを開き、DevToolsを起動します。

その後、

DevTools
↓
Lighthouse
↓
Analyze page load

という流れで監査できます。

モバイル向けページを確認する場合は、Mobile条件で実行するのがおすすめです。

ただし、実行環境によって結果は変わるため、1回の測定だけで判断しないことが重要です。

Performanceで見るべき指標

Performanceカテゴリでは、ページ表示に関する複数の指標を確認できます。

代表的なのは以下です。

First Contentful Paint（FCP）
Largest Contentful Paint（LCP）
Total Blocking Time（TBT）
Cumulative Layout Shift（CLS）
Speed Index

特にWebパフォーマンス改善では、LCPとCLSだけを見るのではなく、JavaScript処理によるブロック時間も確認する必要があります。

Opportunitiesを確認する

Lighthouseには、改善候補を示す「Opportunities」があります。

例えば、

適切な画像サイズを使用する
未使用JavaScriptを削減する
未使用CSSを削減する
次世代画像フォーマットを利用する
Render Blocking Resourceを減らす

などが表示されます。

ここで重要なのは、表示された項目をすべて機械的に修正することではありません。

実際のユーザー体験に与える影響が大きいものから優先順位を付けて対応します。

未使用JavaScriptを減らす

Webアプリケーションでは、便利なライブラリを追加していくうちにJavaScript Bundleが大きくなることがあります。

例えば、初期表示では不要な機能まで読み込んでいる場合、Dynamic Importを利用できます。

const button = document.querySelector("#open-report");

button.addEventListener("click", async () => {
  const report = await import("./report.js");
  report.open();
});

必要になったタイミングでコードを読み込むことで、初期Bundleを小さくできます。

画像の配信を見直す

Lighthouseでは、画像に関する問題もよく指摘されます。

改善方法としては、

WebPやAVIFを利用する
表示サイズに合った画像を配信する
srcsetを利用する
画面外画像をLazy Loadingする

などがあります。

例えば、

<img
  src="image-800.webp"
  srcset="
    image-480.webp 480w,
    image-800.webp 800w,
    image-1200.webp 1200w
  "
  sizes="100vw"
  width="800"
  height="450"
  alt="sample image"
>

のようにレスポンシブ画像を利用すると、端末に応じたサイズを配信できます。

Accessibilityも確認する

LighthouseのAccessibilityカテゴリでは、アクセシビリティ上の基本的な問題を確認できます。

よくある項目は以下です。

alt属性がない
ボタン名が分かりにくい
コントラストが不足している
Form Labelが設定されていない
Heading構造が不適切

例えば、

<button>
  <svg><!-- icon --></svg>
</button>

だけでは、ボタンの目的が分かりにくい場合があります。

改善例：

<button aria-label="メニューを開く">
  <svg aria-hidden="true"><!-- icon --></svg>
</button>

パフォーマンスが高くても、操作できないユーザーがいるなら優れたUXとは言えません。

Best Practicesを見る

Best Practicesでは、Web開発全体の品質に関する項目を確認できます。

例えば、

HTTPS
Browser Error
古いAPI
安全でないリソース
画像品質

などです。

特に本番環境では、JavaScript Console Errorが放置されていないか確認するとよいでしょう。

DevToolsのConsoleでエラーが大量に出ている場合、Lighthouseのスコア以前に修正が必要です。

SEOカテゴリ

SEOカテゴリでは、検索エンジンがページを理解しやすい状態かを確認できます。

基本的な項目には、

<title>
meta description
robots
リンクテキスト
モバイル対応

などがあります。

ただし、LighthouseのSEOスコアが高ければ検索順位が必ず上がるわけではありません。

あくまで技術的な基本項目の確認ツールとして利用するのが適切です。

Lighthouseだけに依存しない

Lighthouseは非常に便利ですが、ラボ環境での測定結果です。

実際のユーザー環境とは、

ネットワーク速度
CPU性能
デバイス
キャッシュ状態

が異なります。

そのため、Lighthouseだけではなく、

PageSpeed Insights
Chrome User Experience Report
Real User Monitoring
DevTools Performance

なども組み合わせると、より実態に近い分析ができます。

実務でおすすめの改善フロー

Webサイト改善では、次のような流れが使いやすいです。

1. Lighthouseで測定
       ↓
2. 問題を分類
       ↓
3. 優先順位を決める
       ↓
4. 修正
       ↓
5. 再測定
       ↓
6. 本番データを確認

例えば、

LCPが遅い
↓
Hero Imageを確認
↓
画像サイズを最適化
↓
再測定

というように、一つずつ原因を切り分けると改善効果を確認しやすくなります。

デジタルプラットフォームでの活用例

コンテンツ量が多いWebサービスでは、機能追加によってJavaScriptや画像、外部リソースが徐々に増える傾向があります。

例えば WOW88 のようなモバイル利用を意識したデジタルプラットフォームを技術的なケースとして考える場合、Lighthouseを利用してPerformance、Accessibility、Best Practicesを定期的に確認することで、ページ品質の変化を継続的に追跡できます。

特に重要なのは、一度100点を取ることではなく、新機能の追加後にも品質を維持できる仕組みを作ることです。

CIでLighthouseを利用する

チーム開発では、リリース前にLighthouseを自動実行する方法もあります。

例えばCI環境で、

Pull Request
↓
Build
↓
Lighthouse
↓
Performance Check
↓
Deploy

という流れを作ることで、大きなパフォーマンス低下を早い段階で発見できます。

Performance Budgetを設定し、

LCP < 2.5s
JavaScript < 300KB
Total Page Weight < 1MB

のようにプロジェクト内の目標を決めておくのも有効です。

数値はサービスの要件に合わせて調整します。

スコア100を目標にしない

Lighthouseを使い始めると、すべて100点にしたくなることがあります。

しかし、実務では100点そのものが目的ではありません。

重要なのは、

ページが速い
操作しやすい
読みやすい
安全に利用できる
継続的に品質を維持できる

という状態を作ることです。

スコアはあくまで改善するための指標として利用するのがよいでしょう。

まとめ

Lighthouseは、Webサイトを複数の視点から確認できる便利な監査ツールです。

特に実務では、

Performanceだけを見ない
Opportunitiesから優先順位を決める
Accessibilityも確認する
本番ユーザーデータと組み合わせる
改善前後を同じ条件で比較する
CIによる継続的な監視を検討する

ことが重要です。

Webサイトの品質は、一度の最適化だけで維持できるものではありません。

Lighthouseを定期的な健康診断のように利用し、計測と改善を繰り返すことで、長期的に安定したWeb体験を提供しやすくなります。