Chrome DevToolsのパフォーマンスパネルでLCPを診断します。
スロットリングしたトレースを記録し、LCPの4つのサブパートを確認して、最も時間がかかっているフェーズを見つけてください。
このガイドはLargest Contentful Paint (LCP)ハブの一部です。ここで扱うツールは、Chrome DevToolsのPerformanceパネル1つだけです。スロットリングを適用してトレースを記録し、LCPの4つのサブパートを確認します。どの問題を最初に修正すべきかが明確になります。
Table of Contents!
DevToolsの出番は最後です
Performanceパネルはlab dataのためのツールです。1台のデバイス、1つのネットワーク（あなたの環境）での、1回のページの読み込みを測定します。ですから、ここから始めるのは間違いであり、ここで仕上げるのが正解です。
field dataから始めてください。そもそもLCPが問題かどうかは、CrUXが教えてくれます。実際のユーザーにとってどのページや要素が遅いのかは、RUMデータが教えてくれます。このワークフローは、Fix & Identify LCP Issuesで順を追って解説しています。残る「なぜ遅いのか」という疑問には、DevToolsが答えてくれます。
field dataをスキップすると、たまたまテストしたページを、たまたま利用している接続環境で最適化することになります。私はほぼすべての監査でこのパターンを目にします。開発者のマシンでは合格し、CrUXのp75では不合格となり、誰もが混乱します。光回線に繋がった高速なノートPCを測定しているからです。ユーザーは電車の中でミドルレンジのAndroidを使っています。
ライブメトリクスビュー
DevToolsを開き（WindowsとLinuxはCtrl+Shift+I、MacはCmd+Option+I）、Performanceタブに移動します。パネルが空の状態で開くことはもうありません。記録を開始する前に、閲覧中のページのLCP、CLS、INPをローカルで測定し、ライブメトリクスビューに表示します。
LCPの作業において、このビューの3つの点が役立ちます。まず、LCP要素の名前が表示され、ホバーするとページ上のその要素がハイライトされます。ブラウザがどの画像や見出しを選んだか推測する必要はありません。さらに、このビューではfield dataを有効にできます。するとDevToolsがURLとオリジンのCrUXの数値を取得し、ローカルの測定値と並べて表示します。ローカルのLCPが0.8秒で、field dataのp75が3.1秒であれば、そのギャップが最初の発見です。あなたのマシンは代表的な環境ではなく、スロットリングは必須だということです。
簡単なヒント： DevToolsを開かずに任意のページでLCP要素をハイライトしたい場合は、無料のCore Web Vitals Visualizer Chrome拡張機能を使用してください。
記録の前にスロットリングを設定する
開発者のマシンでスロットリングを適用せずに取得したトレースは、無価値に近いです。素晴らしい数値が出ますが、ユーザーが体験するものとは一致しません。記録する前に、パネルでCPUとネットワークの両方のスロットリングを設定してください。
- CPU throttling: モバイルテストのデフォルトとして4x slowdownを使用してください。20xはローエンドデバイスに相当します。最近のChromeでは、使用中のマシンに合わせてプリセットを調整することも可能です。Calibrateオプションは、ハードウェアの速度に基づいてローティアおよびミドルティアのモバイルプリセットを生成します。高速なデスクトップでの4xと、古いノートPCでの4xは全く異なるデバイスになるため、これは重要です。
- Network throttling: Slow 4Gを使用してください。これはChromeが名前を変更する前にFast 3Gと呼ばれていたプリセットであり、Lighthouseがモバイル用にシミュレートするものです。Fast 4Gは、より良好な接続環境をテストするための軽めのオプションです。
field dataが有効になっていると、DevToolsは実際のユーザー体験に近いスロットリングプリセットを提案してくれます。それを使いましょう。これらの設定の背後にある完全な理由については、Core Web Vitalsのための最適なDevToolsネットワーク設定のガイドをご覧ください。
ページの読み込みを記録する
「Record and reload」ボタンをクリックします。Chromeは空白のページに移動し、トレースを開始してページを読み込みます。読み込み完了から数秒後に、自動的に記録を停止します。LCPの場合、記録中に何も操作する必要はありません。ページには触れないでください。
簡単なヒント： 拡張機能を無効にしたシークレットウィンドウで記録してください。拡張機能はすべてのページにスクリプトを注入し、それらのスクリプトはサイトとは無関係なlong taskとしてトレースに現れます。
LCP breakdownインサイトを読み解く
トレースが完了すると、左側のInsightsサイドバーにDevToolsの発見事項がリストされます。ここで見るべきはLCP breakdown（古いChromeではLCP by phaseと呼ばれます）です。LCPの時間を4つのサブパートに分割します。
| サブパート | 測定内容 | 修正方法 |
|---|---|---|
| Time to First Byte | ナビゲーションの開始から、HTMLレスポンスの最初のバイトが到達するまで | TTFBを改善する |
| Resource load delay | TTFBから、ブラウザがLCPリソースのダウンロードを開始するまで | Resource Load Delayを最適化する |
| Resource load duration | LCPリソースのダウンロードに費やした時間 | Resource Load Durationを最適化する |
| Element render delay | リソースのダウンロード完了から、要素が描画されるまで | Element Render Delayを最適化する |
webフォントのないテキストのLCPの場合、ダウンロードするものは何もないため、2つのリソースサブパートはゼロになります。つまりTTFBとrender delayがすべてです。
インサイトのサブパートにホバーすると、DevToolsはタイムライン上のその正確な区間をハイライトします。クリックするとタイムラインが拡大され、その区間に含まれるリクエストやタスクを確認できます。また、field dataを有効にしている場合（かつCrUXにサイトの画像LCPデータがある場合）、各labサブパートの横にCrUXのp75値が表示されます。この比較は、パネル内で最も過小評価されている機能です。半日かけて修正作業に没頭する前に、今見ているトレースが実際のユーザー体験と似ているかどうかを教えてくれます。
健全なbreakdownはどのようなものでしょうか。Googleのガイダンスによれば、2つのdelayサブパートはゼロに近く（それぞれLCPの10%未満）、時間のほぼすべてがTTFBと実際のダウンロードに費やされるべきです。何百万ものページの読み込みを対象とした私たちのCore Web Vitals調査は、現実がそこからどれほどかけ離れているかを示しています。TTFBが48%、load delayが24%、load durationはわずか10%、そしてrender delayが17%を占めています。もう一度言います。中央値のサイトでは、2つの待機フェーズの合計が、ダウンロード自体の4倍もの時間を無駄にしています。これらのフェーズでは何もダウンロードされていません。何もレンダリングされていません。ブラウザは、もっと早く始められたはずの作業を待っているだけです。だからこそ、この2つのサブパートが最初に改善を狙うべきポイントなのです。
LCP request discoveryインサイト
LCPが画像の場合、確認すべき2つ目のインサイトがあります。LCP request discoveryです。ここではLCPリクエストに対して3つのチェックを実行します。
fetchpriority="high"が画像（またはそのpreload）に適用されているか？- そのリクエストは初期のHTMLドキュメント内で検出可能か？
- lazy loadingが正しく適用されていないか？
失敗したチェックは、検出の問題を指摘しています。このインサイトはまた、タイムライン上に画像のダウンロードを開始できたはずのタイミングと、損失時間の見積もりを注釈として追加します。これら3つの失敗にはそれぞれ具体的な修正方法があり、すべてResource Load Delayガイドで解説しています。
自分でタイムラインを読み解く
インサイトは一般的なケースをカバーしています。それ以外については、トレースを直接読み解きます。LCPにおいて重要なトラックは3つあります。
Timingsトラックには、FCP、LCP、DCL、およびloadイベントのマーカーが表示されます。LCPマーカーは、要素が描画された瞬間です。あなたが診断するすべての事象は、このマーカーの左側で起きています。
Networkトラックには、すべてのリクエストが表示されます。LCPリソースを見つけて、所要時間だけでなく開始タイミングも確認してください。LCPが3秒で、リクエストが2.5秒の時点で始まっているなら、それは検出の問題です。いくら画像を圧縮しても救うことはできません。HTMLの最初の数バイトからその画像を検出可能にしておけば、ブラウザがheadをパースしている間にダウンロードが始まっていたはずです。
Mainトラックは、main threadの作業を示しています。long taskは隅に赤い三角形のフラグが付きます。探すべきパターンは、LCPリソースのダウンロードが終わっているのに、LCPマーカーが数百ミリ秒も右側にある状態です。このギャップがelement render delayであり、通常はフラグの付いたタスクのどれかが原因です。タスクにホバーして、どのスクリプトが原因かを確認してください。私の経験上、あなた自身のコードよりも、タグマネージャーや同意管理スクリプトであることが圧倒的に多いです。
見つけた問題を修正する
breakdownの中で最大のサブパートが、次に進むべき場所を決定します。TTFB、Resource Load Delay、Resource Load Duration、またはElement Render Delayのいずれかです。LCP要素が画像の場合、Optimize the LCP Imageガイドがこれら4つすべてを横断的にカバーします。
最後に1つ。プリレンダリングされたページでは、ユーザーがクリックする前にブラウザがすべての作業を終えているため、4つのサブパートはすべてほぼゼロになります。LCPの問題がランディングページではなくサイト内のナビゲーションにある場合、speculation rulesを使えば、診断自体を完全に省略できます。
