Home Blogs Lighthouse 6.0スコア監査:ウェブサイトを準備するためのチェックリスト
Applications

Lighthouse 6.0スコア監査:ウェブサイトを準備するためのチェックリスト

About The Author

Outline

Google Lighthouseは、多くのウェブサイトが単一のスコアでパフォーマンスを測定するためのデファクトツールとなっている: The Lighthouse Performance Score。 新しいバージョンであるLighthouse 6.0は、Chrome Canary、PageSpeed Insights、GSC ConsoleのNPMで利用できるようになった。 7月中旬までに、Lighthouse 6.0はChrome 84のChromeユーザーに完全に展開される。 今はあなたの場所がLighthouse 6.0のスコア監査の新しいバージョンの準備ができていることを保障する時間である。

Lighthouse 6.0には、パフォーマンススコアを計算するための新しい重み付け式と同様に、新しいメトリクスと減価償却済みメトリクスが付属している。 この新バージョンは、Google Page ExperienceのアップデートでGoogleのランキングアルゴリズムにCore Web Metricsが追加されることを発表したことと併せて、検索大手が知覚速度、つまりユーザーがページをロードしたときに知覚する速度を強調していることを明確に示している。 より速いユーザーがロードするためにあなたのサイトを知覚するほど、あなたのランクが高く、あなたが受け取るより多くのコンバージョン。

最適化に必要な6つのLighthouse指標

Googleはユーザーがウェブをどのように体験するかを気にしている。 2つのウェブサイトは全く同時に読み込みを終えるかもしれないが、ページ上のコンテンツの表示方法に基づいて、1つはより速く読み込まれるように見えるかもしれない。 両方のサイトの読み込みが同時に終了したが、Googleは後者の方がより速く知覚できるサイトを好む。

Lighthouse 6.0のスコアは、6つのユーザー中心の速度指標の加重平均に基づいている。 First Contentful Paint (FCP)、Speed Index (SI)、Largest Contentful Paint (LCP)は、バージョン6では、知覚された読み込み速度を測定し、ウェブサイトのLighthouseスコアで合計重量を55%保持している。 スコアの他の40%は応答性を測定する指標に基づいており、これはユーザーの速度に対する認識に影響を与えるもう1つの側面である。 これには、Total Blocking Time(TBT)とTime to Interactive(TTI)が含まれる。 スコアの最後の5%は、累積レイアウトシフト(CLS)と呼ばれる視覚的安定性を測定する指標に基づいている。

Lighthouse 5.7のスコアからのFirst Meaningful Paint (FMP)とFirst CPU Idle (FCI)は、ユーザー中心の観点から速度を測定するためのより良い指標に置き換えられた。 これらはLighthouse 6.0で最大のContentful Paint (LCP)とTotal Blocking Time (TBT)である。

灯台5.7 重量 Lighthouse 6.0 重量
First Contentful Paint(FCP)(ファースト・コンテンツフル・ペイント) 20% First Contentful Paint(FCP)(ファースト・コンテンツフル・ペイント) 15%
スピードインデックス(SI) 27% スピードインデックス(SI) 15%
最初の有意義なペイント(FMP) 7% 最大コンテンツ表示時間(LCP) 25%
最初のCPUアイドル(FCI) 13% 合計ブロック時間(TBT) 25%
インタラクティブになるまでの時間(TTI) 33% インタラクティブになるまでの時間(TTI) 15%
- - 累積レイアウトシフト数(CLS) 5%

Lighthouse 6.0の準備でWebサイトを監査する際に焦点を当てる6つの速度の指標は次のとおりである。 メトリクスは、ページをロードするときに測定される順序でレイアウトされる。

達成すべき速度をカバーする簡略化されたチェックリストと、指標ごとの最適化テクニックは、この記事の最後にある。

最初のコンテンツフルペイント

FCPは、ユーザーが画面上の任意のページコンテンツを見ることができる最初のポイントをマークする。 このコンテンツには、テキスト、画像、グラフィック、またはSVGファイルが含まれる。 FCPはLighthouse 5.7で20%のウェイトを持っていたが、Lighthouse 6.0のスコアよりも15%のウェイトしか持っていなかった。

上のフィルムストリップでは、最初のページのロードのFCPは0.6秒で測定されている。 これは、TheTieBar.comのホームページに最初にコンテンツが表示されるときであるが、すべてのコンテンツが表示されているときではないことに気づくだろう。 これは最初と最大の満足な塗料の重要な区別である。 LCPは、上折りの内容が表示されているときに0.9秒で測定される。

Lighthouse 6.0のスコア監査を通過する際には、ページの平均FCPが2秒以下であることを確認する。これは75パーセンタイルのメトリックのしきい値であり、Googleによって高速と見なされているため。 2秒から4秒の間のFCPは中程度の速度と見なされ、4秒を超えるFCPは50パーセンタイルを下回って低速と分類される。

FCPのロードが遅すぎる場合は、次のいずれかが原因である可能性がある。

  1. レンダリングブロックリソースが多すぎる
  2. 大きなCSSファイル
  3. サードパーティのオリジンへの安全な接続がない
  4. サーバの応答時間が長い
  5. 複数ページリダイレクト
  6. キャッシュされていない静的リソース
  7. DOMサイズが大きすぎる

FCPを最適化するには、次の点を考慮する。

  1. 重要なリソースをインライン化し、重要でないリソースを延期し、レンダリングブロッキングURLの影響を減らすために未使用のものを削除する。
  2. CSSから不要な文字をすべて削除して、ファイルのサイズを小さくする。
  3. preconnectを使用して、重要なサードパーティオリジンへの早期接続を確立する。
  4. サーバーのアプリケーションロジックを最適化するか、サーバーハードウェアをアップグレードしてメモリを増やすことで、サーバーの応答時間を短縮する。
  5. 1ページ以上のリダイレクトを避ける。
  6. HTTPキャッシングを使用して静的リソースをキャッシュする。
  7. DOMサイズを小さくするには、ノードの総数が1,500未満、深さが32未満、子ノードが60未満の親ノードを持つ。

スピードインデックス

SIはページ読み込みの視覚的な進行を測定し、コンテンツがどれだけ速く描かれるかの総合スコアを計算する。 Lighthouse 5.7では、SIはウェブサイトのパフォーマンススコアよりも27%のウェイトを持っていた。 Lighthouse 6.0では、これは半減少し、ページのパフォーマンススコアの15%に影響を与える。 Googleはこれを重要な知覚指標と見なしており、画像表示が遅いページはぎこちないと認識される可能性がある。

Lighthouseはブラウザに読み込まれるページのフィルムストリップをキャプチャし、フレームごとに視覚的な進行を分析することでSIを測定している。 ページの可視部分が表示される平均時間によってSIが決定される。 このメトリックは、デバイスの画面サイズによって異なる。

Lighthouse 6.0のスコア監査を経て、4.3s以下でSIを目指す。 この速度は75パーセンタイルにランクされており、Googleでは速いと見なされている。 SIが4.3秒から5.8秒の間のページは中程度であり、5.8秒より遅いページは50パーセンタイルを下回り、遅いと見なされる。

より遅いSI時間は、次のことに起因する傾向がある。

  1. メインスレッドのロード時間が4秒を超える
  2. JavaScriptの実行時間が3.5秒を超える
  3. 大きなフォントファイルは見えないテキストのフラッシュ(FOIT)を引き起こす。

SI時間を短縮するには、以下を考慮する。

  1. コード分割を実装し、未使用のコードを削除し、コードを圧縮して、メインスレッドの負荷とJavaScriptの実行時間を削減する。
  2. FOITを回避するために、Webfontのロード中にテキストが表示されたままになるようにする。

最大のコンテンツフルペイント

LCPはLighthouse 6.0に追加された新しいメトリックであり、サイトのパフォーマンススコアで25%の重みを受ける。 LCPはLighthouse 5.7のFirst Meaningful Paint (FMP)を置き換える。 どちらのメトリックも最大のコンテンツ要素が表示される時間を測定するが、FMPは一貫性のない結果を生成することで悪名高く、特定のウェブブラウザでのみ標準化できる。

LCPは、最大のコンテンツ要素が画面上に完全に表示されるタイミングを測定する。 測定されたコンテンツ要素には、ブロックレベルの要素、画像(SVGファイル内の画像を含む)、およびビデオが含まれる。 これは、ほとんどのユーザーがページが完全に読み込まれていると認識し、購入する可能性が高いポイントインタイムをマークするため、eコマースWebサイトにとって非常に重要な指標である。

上の例では、LCPは0.9秒であり、メイン画像が完全に塗りつぶされている。 このメトリックは、ユーザーがページが完全にロードされていると認識しているが、コンテンツが折りより下にロードされている可能性があるという明確な瞬間を捉える。

Layer0(現在のEdgio)のようなパフォーマンスの高いウェブサイトは、LCPを1秒未満で配信する。 2.5秒までのLCPは高速であると見なされ、このメトリックの75パーセンタイルでランク付けされる。 2.5秒から4秒のLCPは中程度で改善が必要であると考えられ、4秒を超えるLCPは50パーセンタイルを下回っており、Googleによって遅いと考えられている。

低速なLCPは通常、次の1つまたは複数に起因する。

  1. サーバーのレスポンス時間の遅さ
  2. JavaScriptおよびCSSのレンダリングブロック
  3. リソースのロード時間が長い
  4. クライアント側のレンダリングの問題

Lighthouse 6.0スコア監査中に、希望するLCPよりも遅いことがわかった場合は、次の点を考慮する。

  1. 利用可能な最も近いCDNにトラフィックをルーティングし、アセットをキャッシュし、HTMLページをキャッシュファーストで提供し、サードパーティ接続を早期に確立することで、サーバーの応答時間を最適化する。
  2. 不要なCSSを削除し、重要でないCSSを延期し、インラインクリティカルCSSを削除することでCSSを減らす。 JavaScriptファイルを圧縮することでJavaScriptのブロック時間を短縮する。
  3. リソースのロード時間を短縮し、イメージファイルとテキストファイルを最適化および圧縮し、重要なリソースをプリロードする。
  4. サーバーサイドレンダリングとプリレンダリングを使用して、クライアント側レンダリングを最適化する。

合計ブロック時間

TBTは、13%の重量を保持していたLighthouse 5.7のFCIを置き換える。 Lighthouse 6.0では、TBTはページの応答性を測定し、パフォーマンススコアの25%を占める。 TBTは信頼できるインタラクティブになる前のページの非インタラクティブ性の重要度を測定する。

ページが読み込まれるのを待っていて、最後に準備ができているように見える。 表示したい商品をタップしても何も起こらない。 もう一度タップするか? この待ち時間は文字通り消費者のストレスを引き起こすことが知られている。 基本的に、TBTはページの非インタラクティブ性のために消費者がストレスを感じる時間の長さである。

出典:Web.de V

このメトリックは、最初に表示されたコンテンツ要素(FCP)とユーザーがページを完全に操作できる時間(TTI)の間の「ブロックされた」時間(50ms以上かかるタスク)の合計を計算することによって測定される。 例えば上の画像では、メインスレッドでは5つのタスクが実行されているが、50msを超えるタスクは3つだけである。 最初は200ms、2番目は40ms、3番目は105ms。 TBTは(200+40+105)345msである。

50ミリ秒を超えるタスクは、ユーザーがページが遅い、または悪いことに非アクティブであることに気付き、ページを離れるのに十分な長さになる。 これを回避するには、300ms未満のTBTを高速と見なすことを目指す。300msから600msの間のTBTは中程度の速度と見なされ、改善が必要である。 600msより遅いTBTは50パーセンタイルを下回るため、遅いと見なされる。

長いタスクは、通常、次の1つまたは複数によって引き起こされる。

  1. メインスレッドを250ms以上ブロックするサードパーティのコード
  2. JavaScriptの実行時間が3.5秒以上かかる
  3. ロード中にメインスレッドが4秒以上ビジー状態になっている
  4. 大量のネットワーク要求と大きな転送サイズ

このメトリックを改善するには、次の点を考慮する。

  1. scriptタグのasyncまたはdefer属性を使用してサードパーティJavaScriptを効率的にロードし、重要なサードパーティオリジンへの早期接続を確立し、遅延読み込みを使用する。
  2. JavaScriptの実行を高速化し、メインスレッドの負荷を軽減するには、コード分割を実装し、未使用のコードを削除し、コードを圧縮する。
  3. CSSとJavaScriptを最適化して、リソース数と転送サイズを削減する。

インタラクティブになるまでの時間

TTIはLighthouse 5.7から引き継がれた3番目の指標であるが、GoogleはLighthouse 6.0で重量を33%から15%に減らした。 TTIはTBTのコンパニオンメトリクスであり、ページが確実にインタラクティブになるまでにかかる時間を測定する。 Lighthouseは、最初のcontent要素が表示され、その初期スクリプト(もしあれば)がロードされ、50ms以内にユーザー入力に応答することができるときに、ページが確実にインタラクティブであると見なしている。

ユーザにとって、TTIが遅いとページが非アクティブになったり壊れたりしているように感じることがある。 ページはインタラクティブに見えるが、実際にはメインスレッドがブロックされている(TBTで測定)ためではない。 Lighthouse 6.0のWebサイトを監査するときは、5.2秒以内にTTIが高速であると見なされるようにする。 5.2秒から7.3秒のTTIは中程度の速度と見なされ、7.3秒より遅いTTIは遅いと見なされ、サイトにとどまる消費者の意欲に影響を与える。

Lighthouse 6.0スコア監査でTTI速度が低いことが示された場合は、次のいずれかが原因である可能性がある。

  1. ペイロードサイズが大きく、スクリプトの解析時間が長い
  2. リソースのロード時間が長い
  3. サードパーティ製のコードが250ms以上メインスレッドをブロック
  4. 重要なリクエストチェーン
  5. メインスレッドの速度とJavaScriptの実行時間が遅い
  6. リソース数が多い、または転送サイズが大きい

TTI時間を短縮するには、JavaScriptを最適化する必要がある。 これに含まれるもの:

  1. JavaScriptファイルを縮小および圧縮して、ペイロードサイズとスクリプト解析時間を短縮する。
  2. プリロード要求やプリコネクトの追加により、ロード時間を短縮
  3. scriptタグのasync属性またはdefer属性を使用し、遅延読み込みを使用して、サードパーティJavaScriptを効率的にロードする。
  4. クリティカルリソースの数を減らし、残りのリソースがロードされる順序を最適化することで、クリティカルリクエストチェーンのパフォーマンスへの影響を軽減する。
  5. コード分割を実装し、未使用のコードを削除し、コードを圧縮して、メインスレッドの負荷とJavaScriptの実行時間を削減する。
  6. CSSとJavaScriptを最適化して、リソース数と転送サイズを削減する。

累積レイアウトシフト

CLSはLighthouse 6.0で導入された3番目の新しい計量であり、Lighthouse 5.7からの計量を置き換えない唯一のものである。 CLSはLighthouse 6.0のスコアの最後の5%を占め、視覚的な安定性を測定する。

このメトリックは、ユーザーが予期しないレイアウトシフトを経験する頻度を測定する。 これは以前に経験したことがある:商品をタップしようとしているときに、BAMが突然、ページ上の他のものをタップする。 これらの経験は非常に迷惑であり、ユーザーにぎこちないように見られる場合もある。

CLSは、ページのライフスパン全体で発生した予期しないレイアウトシフトごとの個々のレイアウトシフトスコアの合計によって測定される。良好なCLSは0.1未満であり、パフォーマンスの点で75パーセンタイルにランクされる。 CLSが0.1から0.25の間であることは中等度と考えられ、0.25を超える測定値は50パーセンタイルを下回り、Googleは遅いと考えている。

Lighthouse 6.0のスコア監査中にCLSの不良を見つけた場合は、次のいずれかが原因である可能性が高い。

  1. 画像または動画のサイズ変更
  2. 読み込みが遅く、意図したサイズよりも大きく表示されるフォント

このメトリックを改善するには、次の点を考慮する。

  1. 画像とビデオ要素に正確な寸法を含める
  2. ポップアップ広告やバナーを避ける
  3. FOIT/FOUTの原因となるフォントを避ける

LighthouseのスコアはGoogleがあなたの場所について考えているものを示す

ページのLighthouse Performance Scoreは、Googleがそのページをどのように速度で認識しているかを示す。 Lighthouse 6.0の各指標は、ユーザーがどのように速度を知覚するかを測定するGoogleの最善の試みを反映している。 スコアが基準を下回った場合、ユーザーだけでなく検索大手自体にも遅いと認識され、収益とSEOに悪影響を与える。

Googleはサーチエンジンの結果のページのより速くそしてより高く場所をランク付けする。 SEO以外にも、サイトの速度はコンバージョンと収益に大きな影響を与えることがわかっている。 例えばアマゾンは、ページ読み込みに1秒の遅れが生じた場合、同社は年間16億ドルの損失を被る可能性があることを発見した。

要点

この最新バージョンのLighthouseは、知覚速度の指標に重点を置いていることを示している。 Lighthouse 6.0のスコアリングメトリックは、訪問者がページを完全にロードしたと認識する速度を測定する(バックグラウンドでプロセスを実行している場合でも)。

First Contentful Paint、Speed Index、Largest Contentful Paintの3つの指標は、知覚されたロード速度を測定し、パフォーマンススコアの55%を占めた。 2秒のFCP、2.5秒のLCP、4.3秒以下のSIを目指す。

パフォーマンススコアの他の40%は、ページの応答性を測定する知覚的メトリックに基づいている。 これらには、合計ブロッキング時間と対話時間が含まれる。 高速なLighthouse 6.0スコア監査では、300ms未満でTBTが表示され、5.2秒未満でTTIが表示される。

最後に、誰もテキストや画像が画面に飛び込んだり出たりするのを好まない。 Cumulative Layout Shiftは、Lighthouse 6.0監査で考慮すべき6番目のメトリックである。 CLSの測定値が0.1未満になるようにしておくと、パフォーマンススコアに保持されている重量の5%を完全に受け取ることができる。

Lighthouse 6.0スコア監査で達成すべき速度を網羅した簡単なチェックリストと、指標ごとの最適化テクニックを入手するには、以下のフォームに記入してください。