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

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

公開日: 2021 年 5 月 11 日

今回は、Lighthouse、PageSpeed、DevTools の新しいツール機能について説明します。これらの機能は、サイトの Web Vitals を改善する方法を特定するのに役立ちます。

ツールについておさらいすると、Lighthouse はウェブページの品質を改善するためのオープンソースの自動化ツールです。Lighthouse は、Chrome DevTools のデバッグツール スイートに含まれており、公開されているウェブページや認証が必要なウェブページに対して実行できます。Lighthouse は、PageSpeed Insights、CI、WebPageTest でも利用できます。

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

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

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

Core Web Vitals を測定する

Lighthouse は、Core Web Vitals の指標(Largest Contentful Paint、Cumulative Layout Shift、Total Blocking Time(First Input Delay のラボ プロキシ))を合成的に測定できます。これらの指標は、読み込み、レイアウトの安定性、インタラクションの準備状況を反映しています。Core Web Vitals の将来で取り上げられている First Contentful Paint などの他の指標も表示されます。

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

Lighthouse のパフォーマンス指標
DevTools のパフォーマンス パネルのウェブに関する指標レーン
DevTools の [Performance] パネルに新しく追加された [Web Vitals] オプションでは、指標の瞬間をハイライト表示するトラックが表示されます。上の図では、Layout Shift(LS)がハイライト表示されています。

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

ウェブに関する指標を改善できる箇所を特定する

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">

link 属性に追加された imagesrcset 属性と imagesizes 属性により、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 画像の読み込みが遅れる可能性があります。LCP 画像が誤って遅延読み込みされている場合、Lighthouse は「Largest Contentful Paint の画像が遅延読み込みされました」という監査でそのことを強調表示します。

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 のウェブに関する主な指標レポートが非常に役立ちます。これにより、CLS が高いサイトのページの種類を確認できます(この場合、時間を費やす必要があるテンプレートの部分を自己識別するのに役立ちます)。

CLS の問題を表示している Search Console

寸法のない画像から CLS を特定する

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

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

画像のサイズとアスペクト比を考慮することの重要性については、Setting Height And Width On Images Is Important Again をご覧ください。

広告による CLS の特定

Publisher Ads for Lighthouse を使用すると、ページ上の広告の読み込みエクスペリエンスを改善する機会を見つけることができます。これには、レイアウト シフトや長いタスクへの貢献も含まれます。これにより、ユーザーがページを使用できるようになるまでの時間を短縮できます。Lighthouse では、コミュニティ プラグインを介してこれを有効にできます。

リクエスト時間とレイアウト シフトを削減する機会を強調する広告関連の監査

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

  • ビューポートの上部付近に追尾広告でない広告を配置する場合は注意する
  • 広告スロットに可能な限り大きなサイズを予約して、ずれをなくす

合成されていないアニメーションは使用しないでください

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

Chrome は、コンポジットできなかったアニメーションを検出すると、DevTools トレースに報告します。Lighthouse はこれを読み取り、コンポジットされなかったアニメーションを含む要素とその理由を一覧表示します。これらは、コンポジットされていないアニメーションを回避する監査で確認できます。

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

First Input Delay / Total Blocking Time / 長いタスクをデバッグする

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

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

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 の [ネットワーク] パネルでスクリプトを右クリックし、[Block Request URL] をクリックしてブロックできます。ここでは、Intersection Observer のポリフィルに対してこれを行います。

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

次に、Lighthouse を再実行します。今回は、パフォーマンス スコアが改善され(70/100)、Total Blocking Time も改善されています(400 ミリ秒 => 300 ミリ秒)。

コストの高いネットワーク リクエストをブロックした後のビュー

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

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

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

コストの高いサードパーティ リソースの一部を置き換えられることを示す監査

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

サードパーティ JavaScript の監査の費用を削減する

Core Web Vitals の先へ

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

これには、ユーザー エクスペリエンスに必要のないポリフィルや重複への依存を減らすなど、ページ内の JavaScript のコストを削減するための監査のコレクションが含まれます。

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