Google Lighthouse: ユーザーエクスペリエンスと検索エンジンの可視性を高めるための倫理的なハッカーのマニュアル (2024)

Google Lighthouse は、開発者向けに Web ページのパフォーマンスをゲーム化し、向上させる最も効率的な方法の 1 つとして際立っています。Lighthouse を利用すると、全体的な有効性、アクセシビリティ、SEO、および Google が推奨する「ベスト プラクティス」の観点から Web ページを評価できます。すべてボタンを押すだけで実行できます。

これらのテストは、フロントエンド フレームワークのデフォルトのパフォーマンスを評価したり、綿密な再編成によって達成されたパフォーマンスの向上を宣伝したりするために使用できます。ソーシャル メディアで完璧な Lighthouse 評価を表示することは間違いなく満足感をもたらします。それは、盛大な祝賀会にふさわしい、名誉ある成果です。

Lighthouse が私たちのような開発者の間でパフォーマンスに関する会話を刺激しているという事実は、勝利です。しかし、この問題の重要性を無視するわけではありませんが、Web パフォーマンスははるかに複雑です。この記事では、Google Lighthouse のパフォーマンス評価の背後にある方法論を探り、この知識を活用して、その結果を有利に操作しようとします。 すべては楽しみと探求の精神で – 結局のところ、Lighthouse はパフォーマンスの問題を診断するための信頼できる大まかなガイドとして機能します。Lighthouse を楽しみながら、正当に得られるスコアを超えて改善されたスコアを提示するために、どれだけ Lighthouse を出し抜くことができるか観察してみましょう。

しかしその前に、データを詳しく見てみましょう。

フィールドデータは不可欠

ローカル パフォーマンス評価は、Web サイトのパフォーマンスが良い方向に進んでいるかどうかに関する貴重な洞察を提供しますが、現実を完全に反映するものではありません。インターネットは無限の多様性の領域であり、Web サイトにアクセスする個人が使用するデバイス、インターネット速度、画面サイズ、ブラウザー、ブラウザー バージョンなど、ページのパフォーマンスやユーザー インタラクションに影響を与える可能性のあるさまざまなデバイス、インターネット速度、画面サイズ、ブラウザー バージョンを私たちは把握できていない可能性があります。

Sentry のようなアプリケーション パフォーマンス モニタリング ツールによって、実際のユーザーが自分のデバイスで Web サイトにアクセスして収集した大量のフィールド データは、制御された環境下で高性能な開発者マシンを使用して単一のサンプルから取得したラボ データと比較して、Web サイトのパフォーマンスのより正確な評価を提供します。2021 年に Philip Walton が公開した HTTP アーカイブのデータでは、「Lighthouse で 100 点を獲得したページのほぼ半数が、推奨される Core Web Vitals しきい値を満たしていない」ことが強調されています。

Web パフォーマンスは、単一のコア Web 重要指標や Lighthouse パフォーマンス評価の範囲を超えています。私たちの議論は、私たちが扱う基本的なデータの種類を超えています。

ウェブパフォーマンスは統計情報以上のものを含む

速度 ウェブパフォーマンスに関する議論では、ページの読み込み速度が主な焦点となることがよくあります。これは考慮すべき重要な要素ですが、速度はビジネス目標や売上目標に大きく左右されることを認識する必要があります。2018年にGoogleが発表したレポートによると、ページの読み込み時間が3秒を超えると直帰率が32%上昇する可能性が高くなり、読み込み時間が10秒を超えると123%に急上昇します。したがって、売上コンバージョン率を高めるには、ページの読み込みを高速化する必要があります。直帰率を下げる主な目的は、ページ読み込みを高速化することです。 読み込み中.

しかし、「読み込み速度が速い」とは具体的に何を意味するのでしょうか? ウェブページの読み込み速度を物理的に加速できない限界があります。人間と、人間と人間をつなぐサーバーは世界中に分散しており、現代のインターネット インフラストラクチャは、特定の時間に限られた量のデータしか送信できません。

問題の核心は、ページの読み込みが単一の瞬間を表すわけではないということです。「速度とは何か?」という記事で、Google はページの読み込みインシデントを次のように説明しています。

これは、単一の指標で完全に網羅できるものではありません。読み込みプロセス中のさまざまなインスタンスが、ユーザーがそれを「速い」と認識するかどうかに影響を与える可能性があり、1 つだけに焦点を当てると、残りの時間枠で発生する否定的なイベントを見逃す可能性があります。

ここで重要な用語は 経験本物のウェブパフォーマンスは メトリクス そして 速度、より重点を置く 私たちがどのように認識するか ユーザーとして、ページの読み込みとページの操作性について考えます。これにより、Google Lighthouse がパフォーマンス評価を計算する方法についての会話に自然とつながります (これは、想像されるほど純粋な速度に関するものではありません)。

Google Lighthouse のパフォーマンス スコアはどのように決定されますか?

Google Lighthouseパフォーマンススコアの計算には、コアウェブバイタルメトリック（例：First Contentful Paint（FCP）、Largest Contentful Paint（LCP）、Cumulative Layout Shift（CLS））とその他の速度関連メトリック（例：Speed Index（SI）、Total Blocking Time（TBT））から得られたスコアの加重統合が含まれます。 ページの読み込みタイムライン全体にわたって明らか.

以下に、これらの指標が全体のスコア内でどのように重み付けされるかの内訳を示します。

各メトリックへの重みの割り当てにより、Google が優れたユーザー エクスペリエンスに貢献するさまざまな要素をどのように優先するかについての洞察が得られます。

1. ウェブページはユーザーの入力に迅速に応答する必要がある

主な加重指標は 合計ブロック時間 (TBT)、その後の持続時間を調べるゲージ ファースト コンテンツ ペイント (FCP) メイン スレッドが長時間ブロックされ、ユーザー コマンドへの迅速な応答が妨げられる可能性があるインスタンスを特定します。メイン スレッドで JavaScript タスクが 50 ミリ秒以上発生すると、メイン スレッドは「ブロックされている」とみなされます。TBT を削減すると、Web サイトが実際のユーザー アクション (キーボード入力、マウス クリックなど) に応答することが保証されます。

2. ウェブページは予期せぬ視覚的な変動なく、関連コンテンツを表示する必要がある

続いて重視されるLighthouse指標には、 最大のコンテンツペイント (LCP) そして 累積レイアウトシフト (CLS)LCPは、ページの主要コンテンツが読み込まれたときの読み込みプロセスの分岐点を示します。 おそらく ロードされており、したがって 貴重な.

主要なコンテンツの読み込みが完了したと推定される時点で、シームレスなユーザーエンゲージメントを確保し、予期しない視覚的混乱を防ぐために、視覚的な一貫性を維持することが重要です。突然の視覚的動きの影響を受けない（CLS）。理想的なLCP測定は、2.5秒未満の持続時間です（これは、Webサイトを常に最適化するための努力を考慮すると、予想よりも大幅に長いです）。 できるだけ早く).

3. Webページ上のコンテンツの読み込み

の ファースト コンテンツ ペイント (FCP) メトリックは、ユーザーが画面上のコンテンツを識別できるページ読み込みプロセスの最初の瞬間を表します。 スピードインデックス（SI） ページが「完了」状態に達するまでの読み込みプロセス中にコンテンツが視覚的にどれだけ速く表示されるかを測定します。

ページの評価は、HTTP アーカイブのパフォーマンス統計を使用した実際の Web サイトの速度測定に基づいています。優れた FCP メトリックは 1.8 秒未満、優れた SI メトリックは 3.4 秒未満です。これらのベンチマークは、速度について考えるときに予想されるよりも高い値です。

純粋なスピードよりも使いやすさを優先

Google Lighthouse のパフォーマンス評価では、速度よりも使いやすさが重視されていることは間違いありません。SI と FCP が並外れた速度を示したとしても、LCP のレンダリングが遅れ、複雑な画像や外部コンテンツによって視覚的な変化が生じるために CLS が発生する場合、FCP の表示がわずかに遅れるが CLS が発生しないシナリオと比較して、全体的なパフォーマンス評価は劣ります。つまり、JavaScript がメイン スレッドを 50 ミリ秒以上妨害してページの応答性を妨げると、ページの FCP の表示がわずかに遅れる場合よりもパフォーマンス評価に悪影響が及びます。

各メトリックの重み付けが最終的なパフォーマンス評価にどのように影響するかをよりよく理解するには、Lighthouse スコア計算ツールのスライド コントロールを試してみてください。次の表は、個々のメトリックの重み付けの偏りが全体的なパフォーマンス評価に与える影響を示した単純な表で、速度よりもページの使いやすさと応答性が優先されていることを示しています。

Google Lighthouse の全体的なパフォーマンス スコアは、HTTP アーカイブの実際の Web サイト パフォーマンス データのパフォーマンス メトリックから得られる Lighthouse スコア分布内の位置に基づいて、各生のメトリック値を 0 ～ 100 の範囲のスコアに変換することによって計算されます。この数学的に集約されたデータから、2 つの重要なポイントが浮かび上がります。

1. Lighthouse のパフォーマンス スコアは、単独ではなく、実際の Web サイト パフォーマンス データに基づいてコンテキスト化されます。
2. スコアリングに対数正規分布を利用すると、個々のメトリック値と合計スコアの相関は非線形になり、パフォーマンスの低いスコアを大幅に向上させることはできるものの、すでに高いスコアをさらに向上させることはより困難になることがわかります。

developer.chrome.com で対数正規分布曲線のグラフ表現を使用して、メトリック スコアの確認方法について詳しく調べます。

Google Lighthouse を出し抜くことは可能でしょうか?

Google が Web パフォーマンスに関する議論で、速度よりも使いやすさを重視していることに感心しています。これは、開発者が恣意的な指標を追求するよりも本物の体験を優先することを奨励しています。とはいえ、2024 年の今日、Google Lighthouse を騙して、デザインが悪く役に立たないページを優れたページとして認識させることは可能かどうか、私は考えました。

私は白衣と科学用ゴーグルを身に着けて調査に乗り出しました。すべてのテストが実行されました。

• Chromium Lighthouseプラグインを採用し、
• Arcブラウザを使用したシークレットウィンドウでは、
• 「ナビゲーション」と「モバイル」の設定を選択する（別途指定されている場合を除く）、
• 私が研究室環境で行ったものです（つまり、実際のデータはありません）。

私の実験は制御された環境で行われたため、この投稿の冒頭のアドバイスとは矛盾していましたが、実験は興味深い試みであることがわかりました。Lighthouse スコアは、複雑な Web パフォーマンス パズルの 1 つの要素 (ただし、小さな要素) にすぎないことを理解していただければ幸いです。さらに、実際のデータがないため、これらの結果の妥当性に疑問が生じる可能性があります。

FCP と LCP スコアを操作する戦略

TL;DR: 読み込み時に最小限の LCP 適格コンテンツを表示し、Lighthouse 評価が完了するまで FCP および LCP スコアを高めます。

FCPは、ユーザーが画面上のコンテンツを認識できるページ読み込みプロセスの初期段階を示します。一方、LCPは、読み込みタイムラインで主要なページコンテンツ（最大のテキストや画像要素など）が読み込まれたと思われる時点を示します。迅速なLCPは、ページに対するユーザーの信頼を強化するのに役立ちます。 利点ここで心に留めておくべき重要な用語は、「可能性が高い」と「有益」です。

LCP要素の識別

Lighthouse が LCP 用に考慮する Web ページ上の要素のカテゴリは次のとおりです。

• <img> タグ
• <image> タグ内の <svg> 鬼ごっこ
• タグ
• 背景画像が読み込まれた要素は、 url() 関数（CSSグラデーションを除く）
• テキストノードまたはインラインレベルのテキスト要素を含むブロックレベル要素

続く要素は 省略 有用なコンテンツが不足しているという推定により、LCP の検討対象から除外されるもの:

• 透明度がゼロの要素（ユーザーには見えない）
• ビューポート全体を覆い隠す要素（背景要素など）
• プレースホルダー画像、または限界エントロピーを持つ情報量の少ない画像 (例: 単色の画像)。

しかし、このシナリオでは、画像やテキスト要素が有益であると判断する概念は非常に主観的であり、一般的に機械アルゴリズムが確実に判断できる範囲を超えています。たとえば、私が作成したページには、 <h1> タグは、10秒が経過すると、JavaScriptによってDOMにさらに説明的なコンテンツが挿入され、その後、 <h1> 鬼ごっこ。

実験によると、Lighthouse は見出しタグを最大のコンテンツ ペイント (LCP) コンポーネントと見なします。この段階に達すると、ページの読み込みタイムラインは終了しますが、主要なコンテンツはまだ完全には読み込まれていません。それにもかかわらず、Lighthouse はコンテンツが 10 秒のウィンドウ内に読み込まれた可能性が高いと想定します。驚くべきことに、見出しがピリオドなどの単純な句読点に置き換えられた場合でも、Lighthouse は依然として 100 点のフル スコアを与えます。これはさらに価値が低くなります。

このトライアルでは、クライアント側の JavaScript でページ コンテンツを読み込む場合、スケルトン ローダー画面の表示は控えた方がよいことが示されています。これは、このような画面を表示するには、ページ上の追加要素を読み込む必要があるためです。このプロセスには時間がかかることを認識し、ネットワーク リクエストをメイン スレッドから Web ワーカーに転送して合計ブロック時間への影響を回避することで、最小限の実行可能な LCP コンポーネントを含む汎用の「スプラッシュ スクリーン」を使用して、ファースト コンテンツ ペイント (FCP) スコアを向上させることができます。このアプローチにより、Lighthouse は、ページが実際よりもはるかに速くユーザー フレンドリーであるという印象を受けます。

必要なのは、FCP を表す正当な LCP コンポーネントを含めることだけです。2024 年にクライアント側の JavaScript 経由でメイン ページのコンテンツを読み込むことはお勧めしませんが (コンテンツ配信ネットワークから静的 HTML を提供するか、できるだけ多くのコンテンツをサーバー上に構築することを推奨します)、Lighthouse のパフォーマンス スコアに関係なく、この「ハック」を使用することは、ユーザー エクスペリエンスを向上させるためにもお勧めできません。さらに、この方法は、DOM にメイン コンテンツがない場合、検索ボットがメイン コンテンツを見つけることができないため、検索エンジンのインデックス作成には役立たない可能性があります。

私は、ページの有用性をさらに低下させるために、LCP を装ったさまざまなランダムな画像で同様のテストを実行しました。しかし、より小さなファイル サイズ (ページの読み込み速度を向上させるためにサードパーティの画像 API を介してさらに縮小され、「次世代」画像形式に変換された) を使用すると、Lighthouse はこれらの画像を「プレースホルダー画像」または「エントロピーが低い」画像として認識しました。その結果、これらの画像は LCP コンポーネントとして認識されず、LCP が操作されにくくなるという望ましい結果となりました。

シークレット モードで Chromium DevTools を使用してデモ ページを確認し、結果を直接確認してください。

ただし、この戦略は他の多くのシナリオではそれほど効果的ではない可能性があります。例として、Discord はブラウザでアプリケーションのハードリフレッシュを実行するときに「スプラッシュ スクリーン」方式を採用していますが、パフォーマンス スコアは 29 と残念な結果になっています。

DOM を挿入した私のデモとは対照的に、LCP コンポーネントは、スプラッシュ スクリーン自体の要素ではなく、スプラッシュ スクリーンの背後に隠されたコンテンツとして識別されました。これは、私がテストしたフォーカスされたテキスト チャネルに 1 つ以上の大きな画像が存在したためと考えられます。認証後にのみアクセスできるアプリケーションは、検索エンジンによってインデックスされる必要がないため、Lighthouse スコアの重要性は低いと言えます。

アプリがユーザー生成コンテンツを提供する他の多くの状況では、特に画像に関して、LCP コンポーネントを完全に制御することが困難な場合があります。

たとえば、Web ページ上のすべての画像のサイズを制御できる場合は、興味深いハックや「最適化」（引用符で囲む）を利用して、システムを操作できる可能性があります。これは、2021 年に RentPath によって実証されました。開発者は、Web ページ上の画像のサムネイルを拡大することで、Lighthouse のパフォーマンス スコアを 17 ポイント向上させることができました。開発者は、JavaScript 経由での読み込みに大幅に時間がかかったページ上の Google マップ タイルの代わりに、LCP コンポーネントをより大きなサムネイルの 1 つとして扱うように Lighthouse に影響を与えることに成功しました。

重要なポイントは、LCP 要素に注意を払い、それを制御できれば、RentPath と同様のハックや独自のハック、あるいは本物の機能強化を通じて、より高い Lighthouse パフォーマンス スコアを達成できるということです。この記事ではスプラッシュ スクリーン アプローチをハックと表現しましたが、このタイプのエクスペリエンスが有意義で楽しいユーザー エクスペリエンスを提供できないという意味ではありません。パフォーマンスとユーザー エクスペリエンスはどちらも、読み込みプロセスと意図を理解することにかかっています。

CLS スコアを操作する戦略

要約: 十分なデータがあるという前提で、Lighthouse テストが完了するまで、レイアウト シフトの原因となるコンテンツの読み込みを延期します。Transform を使用する CSS アニメーションは、DOM に新しい要素を追加する場合を除いて、通常は CLS を引き起こしません。

CLS は小数点スケールで評価され、0.1 未満のスコアは良好、0.25 を超えるスコアは不良とみなされます。Lighthouse は、ビューポートのサイズと、レンダリングされた 2 つのフレーム間の不安定な要素の移動を考慮して、ユーザーのセッション中に発生する予期しないレイアウト シフトの最も重要なシリーズに基づいて CLS を計算します。レイアウト シフトの個々のインスタンスは重要ではないかもしれませんが、シフトが連続して発生すると、スコアに悪影響を及ぼします。

ページが読み込み時に煩わしいレイアウトシフトを引き起こすことがわかっている場合は、ページの読み込みが完了するまでレイアウトシフトを延期して、LighthouseにCLSの問題がないと想定させることができます。個人的な例では、デモページは、新しく追加されたテキスト要素がJavaScriptを介して元のコンテンツをすぐに上方にシフトさせるにもかかわらず、CLSスコア0.143を返します。DOMに新しいノードを追加するスクリプトを、 タイムアウトを設定する() 機能により、Lighthouse は CLS の発生を検出できません。

別のデモ ページでは、追加の要素がユーザーの操作なしに任意に表示されるため、前のページよりも実用的でもユーザー フレンドリーでもない可能性があるにもかかわらず、100 という完璧なパフォーマンス スコアを達成しています。

ページ ロード テストでレイアウト シフトを延期することは可能ですが、この回避策は、前述のように、より重要な要素であるフィールド データや長期的なユーザー エクスペリエンスには効果的ではありません。レイアウト シフトを延期したページで Lighthouse を使用して「時間範囲」テストを実行すると、約 0.186 という不十分な CLS スコアが正確に報告されます。

デモのような混沌としたユーザー エクスペリエンスを意図的に作成する場合は、CSS アニメーションと変換を活用して、戦略的にコンテンツをページ上に表示することができます。Google の CLS ガイドでは、「コンテンツが 1 つの位置から別の位置へスムーズに遷移すると、ユーザーの理解が深まり、状態の変化をガイドできます」と述べられており、コンテキストに応じたユーザー エクスペリエンスの重要性が改めて強調されています。

次のデモページでは、CSS変換を利用して 規模（） テキスト要素をアニメーション化するには 0 に 1 ページ上で再配置します。ドキュメントの準備ができたときに、テキスト ノードがすでに DOM に存在するため、これらの変換によって CLS がトリガーされることはありません。実験中に、ページが JavaScript を使用して読み込まれた後にテキスト要素が DOM に動的に挿入され、アニメーション化されると、Lighthouse が CLS を検出し、それに応じて評価することに気付きました。

スピードインデックススコアを操作することはできません

スピード インデックス スコアは、ページがレンダリングされる際の視覚的な進行に基づいて計算されます。ページの読み込みシーケンスの早い段階でコンテンツが速く読み込まれるほど、結果はより好ましいものになります。

スピード インデックスを欺いて読み込みシーケンスが遅いと認識させる特定の戦略を採用することは可能です。逆に、コンテンツの読み込みを人工的に高速化する現実的な方法はありません。スピード インデックス スコアを高める唯一の方法は、Web ページを改良して、できるだけ多くのコンテンツを迅速に読み込むことです。この方法は、現在の Web シーンでは完全に実用的ではないかもしれませんが (主にデザイナーの役割を危険にさらすため)、次の方法でスピード インデックスを低下させることに全力を尽くすことができます。

• 静的HTMLウェブページをCDNから直接配信する
• ページから画像を省略し、
• CSSを削減または削除し、
• JavaScript または外部依存関係の読み込みを停止します。

TBTスコアを実際に操作することはできない

TBT は、FCP 後、メイン スレッドが JavaScript アクティビティによって妨害され、ユーザー操作への応答が妨げられていた合計時間を測定します。理想的な TBT スコアは 200 ミリ秒未満です。

JavaScript を多用する Web アプリケーション (シングルページ アプリケーションなど) では、複雑な状態計算や DOM 調整をページの読み込み中にクライアント側で実行し (レンダリングされた HTML を送信する前にサーバー側で実行するのではなく)、TBT スコアが低くなる傾向があります。このようなシナリオでは、Lighthouse 評価が終了するまですべての JavaScript を延期することで、TBT スコアを変更できる可能性があります。ただし、FCP および LCP の要件を満たし、ユーザーに今後のアクティビティを通知するために、プレースホルダー コンテンツまたは読み込み画面を提供する必要があります。さらに、使用中のフロントエンド フレームワークをナビゲートするための作業も必要になります (ページ読み込みシーケンス内の不確定な時点で、最終的に別の React アプリケーションを読み込むプレースホルダー ページを読み込むことは避けてください)。

興味深いのは、高度な JavaScript 機能がクライアント側のアクティビティで依然として普及している一方で、現在の Web 環境におけるイノベーションによって、TBT スコアが基準を下回る事態の発生を軽減するための共同の取り組みが促進されていることです。多数のフロントエンド フレームワークと最新のホスティング サービスを組み合わせると、クライアント側の JavaScript を使わずにページをレンダリングし、複雑なロジックをオンデマンドで実行することができます。クライアント側から JavaScript を排除することが目的ではありませんが、JavaScript の展開を減らす可能性は無数にあり、それによってページの読み込み中にメイン スレッドで過度の計算タスクが発生するリスクが軽減されます。

要約: Lighthouseは単なるおおよそのガイドに過ぎない

Google Lighthouse は、特定の Web サイトのすべての欠陥を特定することはできません。Lighthouse のパフォーマンス メトリックは、ユーザー アクションへの応答性という観点からページのユーザビリティを優先しますが、2024 年におけるすべてのユーザビリティまたはアクセシビリティの問題を包括的に特定するものではありません。

2019 年、マヌエル・マツゾビッチ氏は、Lighthouse が好意的に認識した、デザインの悪い Web ページを意図的に作成する実験を行いました。私は、5 年後に Lighthouse のパフォーマンスが向上するだろうと推測しましたが、そうではありませんでした。

この最後のデモ ページでは、CSS と JavaScript によって入力イベントが無効になり、ページがユーザーの操作に応答しなくなります。5 秒後、JavaScript によって動作が変更され、ボタンの操作が可能になります。驚くべきことに、このページはパフォーマンスとアクセシビリティの両方で満点を維持しています。

ユーザビリティ評価と論理的推論の代わりとして Lighthouse のみに依存することはお勧めできません。

追加の気まぐれな冒険

人生のあらゆる側面において、システムを操作する戦略が存在します。以下に示すのは、Lighthouse のパフォーマンス スコアを人為的に高め、他のすべてを上回る、実証済みで保証された戦術です。

• 高速かつ最上位のハードウェアのみで Lighthouse 評価を実施します。
• インターネット接続が最適であることを確認し、必要に応じて場所を変更します。
• 前述の高速ハードウェアと優れたインターネット接続を使用して収集された、実際の使用状況データを組み込まずに、ラボ データのみを活用します。
• この記事で詳しく説明した独創的なハックをすべて活用して、知人、同僚、インターネット上の見知らぬ人に感銘を与える望ましい結果が得られるまで、さまざまなラボ条件下で評価を繰り返します。

重要: Web パフォーマンスに関する洞察を得て、Web サイトの最適化スキルを向上させるには、Sentry のようなアプリケーション監視ツールの導入を検討してください。Lighthouse を予備的な指標として、Sentry を究極の生産データ取得、効率的な Web バイタル ツールとして考えてください。

最後に、教育目的の完全なデモ Web サイトへのリンクを示します。