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

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

Addy Osmani
Addy Osmani

本日は、Lighthouse、PageSpeed、DevTools の新しいツール機能についてご紹介します。Web Vitals でサイトを改善する方法を特定するのに役立ちます。

Lighthouse は、ウェブページの品質向上に役立つオープンソースの自動化ツールです。復習としてご利用ください。デバッグツールの Chrome DevTools スイートから入手でき、公開されているウェブページや認証が必要なウェブページに対して実行できます。PageSpeed InsightsCIWebPageTest にも Lighthouse があります。

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

また、PageSpeed Insights の要素のスクリーンショットのサポートも追加しました。これにより、ページ単発のパフォーマンスに関する問題を見つけやすくなりました。

ページのレイアウト シフトに関与している DOM ノードがハイライト表示された要素のスクリーンショット

Core Web Vitals の測定

Lighthouse では、Largest Contentful PaintCumulative Layout ShiftTotal Blocking TimeFirst Input Delay のラボプロキシ)などの Core Web Vitals の指標合成して測定できます。これらの指標には、読み込み、レイアウトの安定性、操作の準備状況が反映されます。今後の Core Web Vitals で強調されている First Contentful Paint などの指標もあります。

Lighthouse レポートの [Metrics] セクションには、これらの指標のラボ バージョンが含まれています。これは、ユーザー エクスペリエンスのどの側面に注意を払う必要があるかを示す概要ビューとして使用できます。

Lighthouse のパフォーマンス指標
DevTools のパフォーマンス パネルの [Web Vitals] レーン
DevTools の [Performance] パネルの新しい [Web Vitals] オプションには、上記の Layout Shift(LS)などの指標モーメントをハイライト表示したトラックが表示されます。

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

Web Vitals の改善点を特定する

Largest Contentful Paint 要素を特定する

LCP は、読み込み時に感じられることを測定したものです。ページの読み込み中に、主要な(つまり「最大」の)コンテンツが読み込まれ、ユーザーに表示される時点をマークします。

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

Largest Contentful Paint 要素

この要素が画像の場合、この情報は画像の読み込みを最適化するのに役立ちます。Lighthouse では、画像の圧縮やサイズ変更を改善できるかどうか、またはより最適な最新の画像形式で配信できるかどうかを把握するためのさまざまな画像最適化監査が用意されています。

適切なサイズの画像に関する監査

また、Annie Sullivan の LCP Bookmarklet を使用すると、赤色の長方形で 1 回のクリックで LCP 要素をすばやく特定できます。

ブックマークレットで LCP 要素をハイライト表示する

遅れて検出されたイメージをプリロードして LCP を改善

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

最大の Contentful Paint イメージをプリロードする

LCP イメージのプリロードについてよくある質問をいくつか取り上げ、簡単に説明します。

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

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

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

<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 画像の読み込みが遅れる可能性があります。「Largest Contentful Paint イメージが遅延読み込みされました」という監査で LCP 画像が誤って遅延読み込みされている場合は、Lighthouse でハイライト表示されます。

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 が気に入っている以下の機能です。

Layout Shift Generator は

レイアウト シフトの問題をサイト全体で把握できるように、Search Console の Core Web Vitals レポートを活用しています。これにより、サイト内で CLS が高いページの種類を確認できます(この例では、どのテンプレートに時間を費やす必要があるかを自己識別できます)。

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

ディメンションのない画像から CLS を識別する

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

明示的な幅と高さのない画像要素の監査

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

広告からの CLS の識別

Lighthouse のパブリッシャー広告を使用すると、ページ内の広告の読み込みエクスペリエンスを改善できます。レイアウト シフトへの貢献や、ユーザーがページを使用できるようになるまでの時間がかかる時間のかかるタスクなどが該当します。Lighthouse では、コミュニティ プラグインで有効にできます。

広告関連の監査で、リクエストまでの時間短縮とレイアウト シフトの改善が見込める

広告は、ウェブ上のレイアウト シフトに最も大きく貢献する要素の一つです。次の点に注意してください。

  • ビューポートの上部に固定されていない広告を配置する場合は注意する
  • 広告スロットで可能な限り大きなサイズを予約することでシフトを排除する

非合成アニメーションを避ける

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

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

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

First Input Delay / Total Blocking Time / Long Tasks のデバッグ

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

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

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

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

サードパーティ サービスをモニタリングに利用することを検討している場合は、これらの費用を可視化するための Calibre のメインスレッド実行タイムライン ビジュアルも非常に気に入っています。インタラクティビティに影響する長いタスクに寄与している親タスクと子タスクの両方が強調表示されます。

メインスレッドの実行タイムラインのビジュアル Calibre には、

ネットワーク リクエストをブロックして、Lighthouse 内の変更前と変更後の影響を確認可能に

Chrome DevTools では、ネットワーク リクエストのブロックがサポートされており、個々のリソースが削除または利用できなくなったことによる影響を確認できます。これは、合計ブロック時間(TBT)や操作可能になるまでの時間などの指標に対する個々のスクリプト(サードパーティの埋め込みやトラッカーなど)のコストを理解するのに役立ちます。

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

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

DevTools Network パネルでスクリプトを右クリックし、Block Request URL をクリックしてブロックします。Intersection Observer のポリフィルについては、以下を行います。

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

次に、Lighthouse を再実行します。今回は、合計ブロック時間(400 ミリ秒 => 300 ミリ秒)に伴い、パフォーマンス スコアが改善され(70/100)、それが確認できます。

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

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

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

このようなウィジェットのパフォーマンスを改善するパターンの 1 つは、ユーザー操作時の遅延読み込みです。これを行うには、ウィジェットの軽量プレビュー(ファサード)をレンダリングし、ユーザーが操作した場合にのみ完全バージョンを読み込みます。Lighthouse では、ファサードで遅延読み込みできるサードパーティ リソース(YouTube 動画の埋め込みなど)を推奨する監査を実施しています。

監査により、高価なサードパーティのリソースの一部を置き換え可能であることを強調する

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

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

Core Web Vitals を超えて

最新バージョンの Lighthouse と PageSpeed Insights では、Core Web Vitals を強調するだけでなく、ソースマップを有効にしている場合に JavaScript を多用するウェブ アプリケーションの読み込み速度を改善するための具体的なガイダンスも提供しています。

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

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

Mercedes Mehling 氏によるヒーロー画像Unsplash より)。