Lighthouse 6.0 の新機能

新しい指標、パフォーマンス スコアの更新、新しい監査など。

本日、Lighthouse 6.0 がリリースされました。

Lighthouse は自動ウェブサイト監査ツールです。デベロッパーの皆様が、サイトのユーザー エクスペリエンスを改善するための最適化案や診断情報を提供します。このライブラリは、Chrome DevTools、npm（Node モジュールと CLI として）、またはブラウザ拡張機能（Chrome と Firefox）で使用できます。web.dev/measure や PageSpeed Insights など、多くの Google サービスを支えています。

Lighthouse 6.0 は、npm と Chrome Canary ですぐにご利用いただけます。Lighthouse を使用する他の Google サービスには、月末までに更新が適用されます。Chrome 84（7 月中旬）で Chrome Stable 版が提供される予定です。

Lighthouse Node CLI を試すには、次のコマンドを使用します。 bash npm install -g lighthouse lighthouse https://www.example.com --view

このバージョンの Lighthouse には多数の変更が含まれています。詳しくは、6.0 の変更履歴をご覧ください。この記事ではその要点を説明します

• 新しい指標
• パフォーマンス スコアの更新
• 新しい監査
• Lighthouse CI
• Chrome DevTools パネルの名称変更
• モバイル エミュレーション
• ブラウザ拡張機能
• 予算
• ソースの場所のリンク
• 今後の予定
• ありがとうございました。

新しい指標

Lighthouse 6.0 では、レポートに 3 つの新しい指標が導入されています。これらの新しい指標のうち、Largest Contentful Paint（LCP）と Cumulative Layout Shift（CLS）の 2 つは、Core Web Vitals のラボでの実装です。

Largest Contentful Paint（LCP）

Largest Contentful Paint（LCP）は、認識される読み込みエクスペリエンスの測定値です。ページの読み込み中に、メイン（または「最大」）コンテンツが読み込まれてユーザーに表示される時点を示します。LCP は、読み込みエクスペリエンスの初期段階のみをキャプチャする First Contentful Paint（FCP）を補完するものです。LCP は、ユーザーが実際にページのコンテンツを表示するまでの時間をデベロッパーに知らせます。LCP スコアが 2.5 秒未満の場合は「良好」と見なされます。

詳しくは、Paul Irish による LCP の詳細動画をご覧ください。

Cumulative Layout Shift（CLS）

Cumulative Layout Shift（CLS）は視覚的な安定性の指標です。ページのコンテンツの視覚的な変化を数値化します。CLS スコアが低い場合は、ユーザーに過度のコンテンツ シフトが発生していないことがわかります。CLS スコアが 0.10 未満の場合、「良好」と見なされます。

ラボ環境における CLS は、ページ読み込みの終わりまで測定されます。一方、フィールドでは、最初のユーザー操作まで、またはすべてのユーザー入力を含む CLS を測定できます。

詳しくは、Annie Sullivan による CLS の詳細動画をご覧ください。

Total Blocking Time（TBT）

Total Blocking Time（TBT）は読み込みの応答性を定量化し、入力の応答性を防ぐのに十分な時間、メインスレッドがブロックされた合計時間を測定します。TBT は、First Contentful Paint（FCP）から操作可能になるまでの時間（TTI）の合計時間を測定します。これは TTI に付随する指標であり、ユーザーによるページ操作を妨げるメインスレッド アクティビティを数値化する際に微妙な違いをもたらします。

また、TBT は Core Web Vitals であるフィールド指標 First Input Delay（FID）ともよく相関しています。

パフォーマンス スコアの更新

Lighthouse のパフォーマンス スコアは、ページの表示速度を集計する複数の指標の重み付けを組み合わせて計算されます。パフォーマンス スコア 6.0 の式は次のとおりです。

フェーズ	指標名	指標の重み付け
早着（15%）	First Contentful Paint（FCP）	15%
中（40%）	Speed Index（SI）	15%
	Largest Contentful Paint（LCP）	25%
遅延（15%）	操作可能になるまでの時間（TTI）	15%
メインスレッド（25%）	Total Blocking Time（TBT）	25%
予測可能性（5%）	Cumulative Layout Shift（CLS）	5%

3 つの新しい指標が追加されました。また、First Meaningful Paint、First CPU Idle、Max Potential FID の 3 つの古い指標が削除されました。残りの指標の重みが変更され、メインスレッドのインタラクティビティとレイアウトの予測可能性が強調されています。

比較のために、以下はバージョン 5 のスコアリングです。

フェーズ	指標名	重量
早着（23%）	First Contentful Paint（FCP）	23%
中（34%）	Speed Index（SI）	27%
	First Meaningful Paint（FMP）	7%
終了（46%）	Time to Interactive（TTI）	33%
	初回 CPU アイドル（FCI）	13%
メインスレッド	最大潜在的な FID	0%

Lighthouse のバージョン 5 とバージョン 6 のスコア判定の変更点は次のとおりです。

• TTI の重量は 33% から 15%に削減されました。これは、TTI のばらつきや、指標最適化の不整合がユーザー エクスペリエンスの向上につながるというユーザー フィードバックに直接応えたものでした。TTI はページが完全にインタラクティブである場合には有用なシグナルですが、TBT を補完として使用することで、ばらつきが低減されます。このスコアリングの変更により、デベロッパーはユーザーの操作に合わせて最適化できるようになることを願っています。
• FCP の重みは 23% から 15% に削減されました。最初のピクセルがペイントされる（FCP）ときだけ測定しても、全体像は得られませんでした。ユーザーが関心を持っていると思われる情報を確認できるタイミング（LCP）の測定と組み合わせることで、読み込みエクスペリエンスをより適切に反映できます。
• Max Potential FID のサポートは終了しました。レポートに表示されなくなりますが、JSON では引き続き使用できます。インタラクティビティを定量化するには、mpFID ではなく TBT を確認することをおすすめします。
• First Meaningful Paint は非推奨になりました。この指標はバリエーションが多すぎて、実装が Chrome レンダリングの内部に固有のものであるため、標準化を実現できる方法がありませんでした。サイトによっては FMP のタイミングに価値があると考えるチームもいますが、指標をさらに改善することはできません。
• First CPU Idle は非推奨となりました。これは、TTI との区別が十分ではないためです。TBT と TTI は、現在インタラクティビティに関する頼りになる指標です。
• CLS の重みは比較的低いものの、今後のメジャー バージョンで増加させる予定です。

スコアの変化

これらの変化は実際のサイトのスコアにどのような影響を与えていますか？Google は、2 つのデータセット（サイトの一般的なセットと Eleventy で構築された静的サイトのセット）を使用したスコア変更の分析を公開しています。まとめると、約 20% のサイトではスコアが著しく高く、約 30% ではほとんど変化がなく、約 50% では 5 ポイント以上低下しています。

スコアの変化は、主に次の 3 つの要素に分けられます。

• 体重変化スコア
• 基盤となる指標の実装に関するバグを修正
• 個々のスコア曲線の変化

スコアの重み付けの変更と 3 つの新しい指標の導入が、総合スコアの変化の大部分を後押ししました。バージョン 6 のパフォーマンス スコアで、デベロッパーが重点を置いておくためにまだ最適化されていない新しい指標。バージョン 5 のテストコーパスの平均パフォーマンス スコアは約 50 でしたが、新しい Total Blocking Time 指標と Largest Contentful Paint 指標の平均スコアは約 30 でした。この 2 つの指標を合わせると、Lighthouse バージョン 6 のパフォーマンス スコアの重みの 50% を占めるため、当然ながらサイトの大部分で減少が見られます。

基盤となる指標の計算に関するバグが修正され、スコアが異なる場合があります。影響を受けるサイトは比較的少数ですが、状況によっては大きな影響を及ぼす可能性があります。全体として、約 8% のサイトで指標の実装の変更によりスコアが改善し、約 4% のサイトで指標の実装の変更によりスコアが低下しました。約 88% のサイトでこの修正による影響はありませんでした。

個々のスコア曲線の変化も、全体的なスコア変化にはわずかですが、影響を及ぼしました。Google では、スコア曲線が HTTPArchive データセットで観測された指標と一致するように定期的に確認しています。実装の大幅な変更の影響を受けたサイトを除外して、個々の指標のスコア曲線を微調整したところ、サイトのスコアは約 3% 改善し、約 4% 減少しました。およそ 93% のサイトでこの変更による影響はありませんでした。

スコア計算ツール

パフォーマンス スコアリングを調べるのに役立つスコア計算ツールが公開されています。料金計算ツールでは、Lighthouse バージョン 5 とバージョン 6 のスコアを比較することもできます。Lighthouse 6.0 を使用して監査を実行すると、レポートに計算ツールへのリンクが表示され、その結果が入力されます。

新しい監査

未使用の JavaScript

新しい監査「使用されていない JavaScript」で、DevTools のコード カバレッジを利用しています。

この監査は完全に新しいものではありません。2017 年半ばに追加されましたが、Lighthouse をできるだけ高速に維持するため、パフォーマンス上のオーバーヘッドがあるため、デフォルトでは無効になっています。このカバレッジ データの収集ははるかに効率的になったため、デフォルトで有効にしても問題はありません。

ユーザー補助の監査

Lighthouse では、優れた axe-core ライブラリを使用してユーザー補助カテゴリを強化しています。Lighthouse 6.0 では、以下の監査が追加されました。

• aria-hidden-body
• aria-hidden-focus
• aria-input-field-name
• aria-toggle-field-name
• form-field-multiple-labels
• heading-order
• duplicate-id-active
• duplicate-id-aria

マスク可能なアイコン

マスク可能なアイコンは、PWA のアイコンをあらゆるタイプのデバイスで適切に表示する新しいアイコン形式です。PWA をできるだけ快適に表示できるように、manifest.json がこの新しい形式をサポートしているかどうかを確認する新しい監査を導入しました。

文字セット宣言

メタ文字セット要素は、HTML ドキュメントの解釈に使用する文字エンコードを宣言します。この要素がない場合、またはドキュメントの後半で宣言されている場合、ブラウザはさまざまなヒューリスティックを使用して、使用するエンコードを推測します。ブラウザが正しく推測せず、遅延したメタ文字セット要素が見つかった場合、パーサーは通常、それまでに行われたすべての処理を破棄して最初からやり直し、ユーザー エクスペリエンスの低下を招きます。この新しい監査では、ページの文字エンコードが有効で、事前に定義されていることが確認されます。

Lighthouse CI

昨年 11 月の CDS で、Lighthouse CI を発表しました。これは、継続的インテグレーション パイプラインのすべての commit で Lighthouse の結果を追跡するオープンソースの Node CLI およびサーバーであり、アルファ版リリース以来長い道のりを歩んできました。Lighthouse CI で、Travis、Circle、GitLab、GitHub Actions など、多数の CI プロバイダがサポートされるようになりました。すぐにデプロイできる Docker イメージにより、セットアップが簡単になります。また、ダッシュボードの包括的なデザイン変更により、Lighthouse であらゆるカテゴリと指標のトレンドを確認できるようになり、詳細な分析が可能になりました。

スタートガイドに沿って、プロジェクトで Lighthouse CI を今すぐご利用ください。

Chrome DevTools パネルの名前を変更

[Audits] パネルの名前が [Lighthouse] パネルに変更されました。お疲れさまでした。

DevTools のウィンドウ サイズによっては、パネルが [»] ボタンの背後にある可能性があります。タブをドラッグして順序を変更できます。

[コマンド メニュー] でパネルをすばやく表示するには:

1. Ctrl+Shift+J キー（Mac の場合は Command+Option+J キー）を押して DevTools を開きます。
2. Control+Shift+P（Mac では Command+Shift+P）を押して [コマンド] メニューを開きます。
3. 「Lighthouse」と入力します。
4. Enter キーを押します。

モバイル エミュレーション

Lighthouse はモバイル ファーストの考え方を追求。パフォーマンスの問題は一般的なモバイル条件下でより顕著になりますが、デベロッパーは多くの場合、このような条件でテストしません。このため、Lighthouse のデフォルト構成ではモバイル エミュレーションが適用されます。エミュレーションは次のものから構成されます。

• シミュレートされた低速ネットワークと CPU の状態（Lantern と呼ばれるシミュレーション エンジン経由）。
• デバイス画面のエミュレーション（Chrome DevTools と同じ）。

Lighthouse では当初から Nexus 5X を参照デバイスとして使用してきました。近年、ほとんどのパフォーマンス エンジニアがテスト目的で Moto G4 を使用しています。Lighthouse もこれに続き、参照デバイスを Moto G4 に変更しました。実際には、この変更にそれほど大きな影響はありませんが、ウェブページで検出可能な変更は次のとおりです。

• 画面サイズが 412x660 ピクセルから 360x640 ピクセルに変更されました。
• ユーザー エージェント文字列が若干変更され、以前は Nexus 5 Build/MRA58N だったデバイス部分が Moto G (4) になりました。

Chrome 81 以降では、Chrome DevTools のデバイス エミュレーション リストでも Moto G4 を利用できます。

ブラウザ拡張機能

Lighthouse 用の Chrome 拡張機能は、Lighthouse をローカルで実行する便利な方法です。残念ながら、サポートが複雑でした。 Chrome DevTools の [Lighthouse] パネルの方がユーザー エクスペリエンスに優れている（レポートは他のパネルと統合される）ため、Chrome 拡張機能を簡素化することでエンジニアリングのオーバーヘッドを削減できると考えています。

この拡張機能では、Lighthouse をローカルで実行する代わりに、PageSpeed Insights API を使用するようになりました。これだけでは十分ではないユーザーもいます。主な違いは次のとおりです。

• PageSpeed Insights は非公開のウェブサイトを監査できません。これは、ローカルの Chrome インスタンスではなくリモート サーバー経由で実行されるためです。非公開ウェブサイトを監査する必要がある場合は、DevTools の [Lighthouse] パネルまたは Node CLI を使用します。
• PageSpeed Insights では、最新の Lighthouse リリースが使用される保証はありません。最新リリースを使用する場合は、Node CLI を使用します。ブラウザ拡張機能のアップデートは、リリースから約 1 ～ 2 週間後に行われます。
• PageSpeed Insights は Google API です。これを使用すると、Google API 利用規約に同意したことになります。利用規約に同意しない場合や、同意できない場合は、DevTools の [Lighthouse] パネルまたは Node CLI を使用します。

幸いなことに、プロダクト ストーリーをシンプルにすることで、他のエンジニアリングの問題に集中できるようになりました。その結果、Lighthouse Firefox 拡張機能をリリースしました。

予算

Lighthouse 5.0 では、各リソースタイプ（スクリプト、画像、CSS など）の量に関するしきい値を追加できるパフォーマンス バジェットが導入されました。

Lighthouse 6.0 では予算指標のサポートが追加され、FCP などの特定の指標にしきい値を設定できるようになりました。現時点では、予算を利用できるのは Node CLI と Lighthouse CI のみです。

ソースの場所のリンク

Lighthouse で検出されたページの問題の一部は、ソースコードの特定の行まで遡り、レポートには関連するファイルと行が正確に記載されます。DevTools でこれを簡単に探索できるように、レポートで指定された場所をクリックすると、関連ファイルが [ソース] パネルに表示されます。

来たるべきもの

Lighthouse では、次のような新機能を提供するために、ソースマップの収集に関する試験運用を開始しました。

• JavaScript バンドル内の重複するモジュールを検出する
• 最新のブラウザに送信されるコード内の過剰なポリフィルまたは変換を検出します。
• 未使用の JavaScript の監査を強化して、モジュール レベルの粒度を提供
• ツリーマップで、対応が必要なモジュールがハイライト表示されます。
• 「ソースの場所」が設定されたレポート アイテムの元のソースコードを表示する。

Lighthouse の今後のバージョンでは、これらの機能がデフォルトで有効になる予定です。現時点では、次の CLI フラグを使用して、Lighthouse の試験運用版の監査を表示できます。

lighthouse https://web.dev --view --preset experimental

ありがとうございました

Lighthouse のご利用とフィードバックのご提供に感謝申し上げます。お寄せいただいたフィードバックは Lighthouse の改善に役立てさせていただきます。また、Lighthouse 6.0 によってウェブサイトのパフォーマンス向上が容易になることを願っております。

今後のご対応

• Chrome Canary を開き、[Lighthouse] パネルを実行します。
• Node CLI（npm install -g lighthouse && lighthouse https://yoursite.com --view）を使用します。
• プロジェクトで Lighthouse CI を実行します。
• Lighthouse の監査ドキュメントをご確認ください。
• ウェブをもっと快適に利用しましょう。

Google はウェブに情熱を注いでおり、デベロッパー コミュニティと協力してウェブを改善するためのツールを開発しています。Lighthouse はオープンソース プロジェクトです。入力ミスの修正からドキュメントのリファクタリング、新しい監査まで、あらゆることにご協力いただいたすべてのコントリビューターに感謝いたします。寄付に興味はありますか？ Lighthouse GitHub リポジトリをご覧ください。