Lighthouse を使用したウェブに関する指標の最適化

Chrome のウェブツールのユーザー エクスペリエンスを改善する機会を見つける。

Addy Osmani 氏
Addy Osmani
Twitter GitHub

本日は、Lighthouse、PageSpeed、DevTools の新しい機能として、ウェブに関する指標に関するサイトの改善方法を特定するための新機能をご紹介します。

先ほど説明したとおり、Lighthouse はオープンソースの自動化ツールで、ウェブページの品質改善に役立ちます。このツールは Chrome DevTools のデバッグツール スイートに用意されており、公開されている任意のウェブページや認証が必要なウェブページに対して実行できます。Lighthouse は、PageSpeed Insights、CI、WebPageTest でもご利用いただけます。

Lighthouse 7.x には要素のスクリーンショットなどの新機能が含まれており、ユーザー エクスペリエンス指標（レイアウト シフトに影響しているノードなど）に影響を与える UI の一部を簡単に検査できます。

また、PageSpeed Insights に要素のスクリーンショットを追加できるようにしました。これにより、1 回限りのパフォーマンスでページが実行される問題を簡単に特定できます。

ページ内のレイアウト シフトの原因となっている DOM ノードがハイライト表示された要素のスクリーンショット

Core Web Vitals を測定する

Lighthouse では、ウェブに関する主な指標（Largest Contentful Paint、Cumulative Layout Shift、Total Blocking Time（First Input Delay のラボプロキシ）など）を合成的に測定できます。 これらの指標には、読み込み、レイアウトの安定性、操作準備状況が反映されます。今後の Core Web Vitals で強調されている First Contentful Paint などの他の指標もあります。

Lighthouse レポートの [指標] セクションには、これらの指標のラボ版が表示されます。このレポートは、ユーザー エクスペリエンスのどの部分に注意を払うべきかの概要ビューとして使用できます。

Lighthouse のパフォーマンス指標
DevTools のパフォーマンス パネルの [Web Vitals] レーン
DevTools の [パフォーマンス] パネルの新しい [ウェブに関する指標] オプションには、上記のレイアウト シフト（LS）などの指標の瞬間をハイライト表示するトラックが表示されます。

Chrome UX レポートや RUM にあるようなフィールド指標にはこの制限がなく、実際のユーザー エクスペリエンスを反映しているため、ラボデータを補完する有益な指標となります。フィールド データからは、ラボで得られるような診断情報は得られないため、この 2 つは密接に関連しています。

Web Vitals で改善できる部分を特定する

Largest Contentful Paint 要素を特定する

LCP は、知覚される読み込みエクスペリエンスの測定値です。ページの読み込み中に、メイン（つまり「最大」の）コンテンツが読み込まれてユーザーに表示されているポイントを示します。

Lighthouse では「Largest Contentful Paint 要素」の監査を実施し、どの要素が Largest Contentful Paint であったかを特定します。要素にカーソルを合わせると、メインのブラウザ ウィンドウで要素がハイライト表示されます。

Largest Contentful Paint 要素

この要素が画像の場合、この情報は画像の読み込みを最適化するための有用なヒントになります。Lighthouse では、画像最適化の監査が多数実施されており、より最適な最新の画像形式で画像の圧縮、サイズ変更、配信を改善できるかどうかを把握できます。

画像の適切なサイズの監査

また、Annie Sullivan による LCP ブックマークレットを使用すると、赤い長方形が含まれる LCP 要素をワンクリックですばやく特定できます。

ブックマークレットによる LCP 要素のハイライト表示

遅れて検出された画像をプリロードして LCP を改善する

Largest Contentful Paint を改善するには、重要なヒーロー画像がブラウザによって後から検出される場合に、その画像をプリロードします。遅延検出は、画像を検出可能にする前に JavaScript バンドルを読み込む必要がある場合に発生します。

Largest Contentful Paint 画像をプリロードする

LCP 画像のプリロードについてよく寄せられる質問がいくつかあります。

レスポンシブな画像をプリロードできますか？はい。たとえば、以下の srcset と sizes を使用して指定されたレスポンシブなヒーロー画像があるとします。

<img src="lighthouse.jpg"
          srcset="lighthouse_400px.jpg 400w,
                  lighthouse_800px.jpg 800w,
                  lighthouse_1600px.jpg 1600w" sizes="50vw" alt="A helpful
Lighthouse">

imagesrcset 属性と imagesizes 属性が link 属性に追加されたことで、srcset と sizes で使用されるのと同じ画像選択ロジックを使用してレスポンシブ画像をプリロードできます。

<link rel="preload" as="image" href="lighthouse.jpg"
           imagesrcset="lighthouse_400px.jpg 400w,
                        lighthouse_800px.jpg 800w,
                        lighthouse_1600px.jpg 1600w"
imagesizes="50vw">

LCP イメージが CSS バックグラウンドを介して定義されている場合、監査ではプリロードの機会もハイライト表示されますか？はい、できます。

CSS 背景または <img> のどちらを経由するかにかかわらず、LCP 画像としてフラグされた画像は、深さ 3 以上の滝で検出された場合に候補になります。

画面外画像の遅延読み込みと LCP でのこの問題の回避

初期のユーザー エクスペリエンスにとって重要ではないオフスクリーン画像は、遅延読み込みできます。これは、ユーザーが画像の近くをスクロールするまで画像のダウンロードを延期する手法です。これにより、重要なアセットのネットワーク競合を減らし、場合によっては LCP を改善できます。この場合は、[オフスクリーン イメージの遅延] 監査が役立ちます。

オフスクリーン画像の遅延読み込みを行う

Largest Contentful Paint の画像など、スクロールせずに見える範囲の重要な画像は遅延読み込みすべきではありません。LCP の画像の読み込みが遅れることがあります。Lighthouse では、「Largest Contentful Paint の画像の遅延読み込み」の監査で、LCP 画像が誤って遅延読み込みされている場合にハイライト表示されます。

LCP 画像の遅延読み込みを回避する

CLS への影響を特定する

Cumulative Layout Shift は視覚的な安定性の尺度です。ページのコンテンツが視覚的にどの程度変化しているかを定量化します。Lighthouse では、「大規模なレイアウト シフトを避ける」と呼ばれる、CLS のデバッグに関する監査を実施しています。

この監査では、ページの変化に最も寄与している DOM 要素がハイライト表示されます。左側の [要素] 列には DOM 要素のリストが表示され、右側には CLS 全体に対する貢献度が表示されます。

Lighthouse での大幅なレイアウト シフトの回避に関する監査では、CLS に影響している関連 DOM ノードがハイライト表示される。

Lighthouse 要素のスクリーンショット機能のおかげで、監査で指摘された主要な要素を視覚的にプレビューでき、クリックしてズームするだけでより明確に確認できるようになります。

要素のスクリーンショットをクリックすると、そのスクリーンショットが開きます

読み込み後の CLS では、要素が CLS に最も影響を及ぼした長方形で永続的に可視化できる場合があります。これは、SpeedCurve の Core Web Vitals ダッシュボードなどのサードパーティ ツールに搭載されている機能であり、Defaced の Layout Shift GIF Generator を使用すると非常に便利です。

レイアウト シフト ジェネレータ。シフトがハイライト表示されます。

サイト全体のレイアウト シフトの問題については、Search Console の Core Web Vitals レポートから多くの情報を得ることができました。これにより、CLS が高いページの種類を確認できます（この場合は、テンプレートのどの部分に時間を費やすべきかを自分で特定するのに役立ちます）。

Search Console に CLS の問題が表示されている

次元のない画像から CLS を識別する

サイズが指定されていない画像による Cumulative Layout Shift の発生を制限するには、画像要素と動画要素に幅と高さの属性を含めます。このアプローチにより、ブラウザは、画像の読み込み中にドキュメント内に適切な量のスペースを割り当てることができます。

幅と高さが明示的に指定されていない画像要素の監査

画像の寸法とアスペクト比を検討する重要性については、画像の高さと幅の設定が重要になるをご覧ください。

広告から CLS を特定する

Lighthouse によるパブリッシャー広告では、レイアウト シフトへの寄与や、ページがどれだけ早くユーザーが使用可能になる可能性がある時間のかかるタスクなど、広告の読み込みエクスペリエンスを改善できる可能性があります。Lighthouse では、コミュニティ プラグインを使用してこの機能を有効にできます。

広告関連の監査で、リクエストとレイアウト シフトにかかる時間を短縮できる機会を浮き彫りにする

ウェブのレイアウト シフトに最も寄与しているのは広告です。次のことを行ってください。

  • ビューポートの上部付近に非追尾広告を配置する場合の注意点
  • できるだけ大きなサイズの広告スロットを予約して、ずれが生じないようにする

合成されていないアニメーションを避ける

負荷の高い JavaScript タスクによってメインスレッドがビジー状態になっている場合、合成されていないアニメーションのローエンドのデバイスでは、ジャンクが発生することがあります。このようなアニメーションにより、レイアウト シフトが発生する可能性があります。

Chrome で合成できないアニメーションが検出されると、Lighthouse で読み取られたアニメーションが DevTools のトレースに報告され、アニメーション付きの要素とその理由の一覧を確認できます。これは、合成されていないアニメーションを避けるの監査で確認できます。

合成されていないアニメーションを回避するための監査

初回入力遅延 / 合計ブロック時間 / 長いタスクのデバッグ

初回入力は、ユーザーが最初にページを操作（リンクのクリック、ボタンのタップ、カスタムの JavaScript コントロールの使用など）してから、その操作に応じてブラウザが実際にイベント ハンドラの処理を開始できるまでの時間を測定します。長い JavaScript タスクは、この指標と、この指標である Total Blocking Time のプロキシに影響する可能性があります。

長いメインスレッド タスクを回避するための監査

Lighthouse では「長いメインスレッド タスクを回避する」という監査が行われ、メインスレッドで最も長いタスクが一覧表示されます。これは、入力遅延に最も影響している要因を特定するのに役立ちます。左側の列には、長いメインスレッド タスクを処理しているスクリプトの URL が表示されます。

右に、これらのタスクの実行時間が表示されます。長時間のタスクは、50 ミリ秒を超えて実行されるタスクです。これは、フレームレートまたは入力レイテンシに影響を与えるのに十分な時間、メインスレッドをブロックするとみなされます。

サードパーティのモニタリング サービスを検討する場合、これらのコストを可視化する Calibre のメインスレッド実行タイムラインのビジュアルも非常に気に入っています。インタラクティブ性に影響を与える長いタスクの原因となっている親タスクと子タスクの両方がハイライト表示されます。

Calibre では、メインスレッドの実行タイムラインを視覚的に

ネットワーク リクエストをブロックして、Lighthouse で変更前と影響を確認できるようにする

Chrome DevTools では、ネットワーク リクエストのブロックがサポートされており、個々のリソースが削除されたり利用できなくなったりした場合の影響を確認できます。これは、Total Blocking Time（TBT）や Time to Interactive などの指標に対する個々のスクリプト（サードパーティの埋め込みやトラッカーなど）の費用を把握するのに役立ちます。

ネットワーク リクエストのブロックは、Lighthouse でも機能します。それでは、Lighthouse レポートを見てパフォーマンス スコアは 63/100 で、TBT は 400 ミリ秒です。コードを調べると、このサイトは、必要のない Chrome の Intersection Observer ポリフィルを読み込むことがわかりました。ブロックしましょう！

ネットワーク リクエストのブロック

DevTools の [Network] パネルでスクリプトを右クリックし、Block Request URL をクリックしてブロックできます。ここでは、Intersection Observer のポリフィルを作成します。

DevTools でリクエスト URL をブロックする

次に、Lighthouse を再実行します。今回は、Total Blocking Time（400 ミリ秒 => 300 ミリ秒）のパフォーマンス スコアが改善されている（70/100）ことがわかります。

コストのかかるネットワーク リクエストをブロックした後の状況

コストのかかるサードパーティの埋め込みをファサードに置き換える

動画、ソーシャル メディアの投稿、ウィジェットをページに埋め込む場合は、サードパーティのリソースを使用するのが一般的です。デフォルトでは、ほとんどの埋め込みはすぐに積極的に読み込まれるため、ユーザー エクスペリエンスに悪影響を与える高額なペイロードが発生する可能性があります。これは、サードパーティが重要でない場合（ユーザーが表示する前にスクロールする必要がある場合など）には無駄です。

このようなウィジェットのパフォーマンスを向上させるパターンの 1 つとして、ユーザー操作で遅延読み込みすることが挙げられます。そのためには、ウィジェットの軽量プレビュー（ファサード）をレンダリングし、ユーザーが操作した場合にのみ完全版を読み込みます。Lighthouse では、YouTube 動画の埋め込みなど、ファサードで遅延読み込み可能なサードパーティのリソースをおすすめする監査を実施しています。

監査により、費用のかかるサードパーティ リソースの一部を置き換えることができることが示される

なお、メインスレッドを 250 ミリ秒を超えてブロックしているサードパーティのコードはハイライト表示されます。これにより、あらゆる種類のサードパーティ スクリプト（Google が作成したものを含む）を公開できます。スクリプトを表示するためにスクロールが必要な場合は、遅延読み込みや遅延読み込みを行う方が適切な場合があります。

サードパーティの JavaScript 監査のコストを削減する

ウェブに関する主な指標の枠を超える

Lighthouse と PageSpeed Insights の最新版では、ウェブに関する主な指標に注目するだけでなく、JavaScript を多用したウェブ アプリケーションの読み込み速度を改善するための具体的なガイダンスも提供しています（ソースマップを有効にしている場合）。

たとえば、ユーザー エクスペリエンスに不要なポリフィルや重複ページへの依存を減らすなど、ページの JavaScript の費用を削減するための監査項目が増えています。

Core Web Vitals ツールの詳細については、Twitter アカウント Lighthouse チームと DevTools の新機能で最新情報をご確認ください。

ヒーロー画像（Mercedes Mehling、Unsplash）