優れたソフトウェアと実用的なチュートリアル
最大コンテンツ描画可能数(LCP)は、ページ読み込みタイムラインにおいて、ページのメインコンテンツがほぼ読み込まれた時点を示すため、体感読み込み速度を測定する上で重要なユーザー中心の指標です。LCPが速いほど、ユーザーはページが有効であることを確信できます。
Web ページのメイン コンテンツがどれだけ速く読み込まれ、そのコンテンツがどれだけ速くユーザーに表示されるかを測定することは、Web 開発者にとって長い間の課題でした。
のような負荷またはDOMContentLoaded (DOMコンテンツがロードされました)これらの古いインジケーターは、必ずしもユーザーが画面で見たものとは一致していなかったため、あまり良くありませんでした。ファースト コンテンツ ペイント (FCP)これらの新しいユーザー中心のパフォーマンス指標は、読み込みエクスペリエンスのごく初期段階のみを捉えます。ページにスプラッシュ画面や読み込みインジケーターが表示されている場合、それらの瞬間はユーザーにとってあまり重要ではありません。
過去には以下のようなパフォーマンス指標を推奨してきました。最初の意味のあるペイント(FMP)そしてスピードインデックス スピードインデックス(SI) (両方の指標は Lighthouse ツールに含まれています) これらの指標は、最初のペイント後の読み込みエクスペリエンスをより詳細に把握するのに役立ちますが、複雑で解釈が難しく、間違っていることが多く、ページのメイン コンテンツが読み込まれた時点を特定できないことを意味します。
少ないほうが多いよりも良い場合もあります。W3C ウェブパフォーマンスワーキンググループGoogle との話し合いや Google が実施した調査に基づいて、ページのメイン コンテンツが読み込まれたタイミングをより正確に測定するには、最も大きな要素のレンダリングが完了したタイミングを確認することが分かりました。
LCPとは何ですか?
Largest Contentful Paint(LCP)指標はページに基づいていますまず読み込みを開始する可視領域内の最大可視領域は、その時点で報告されます。画像またはテキストブロックレンダリングが完了した相対時間。
良い LCP スコアとは何ですか?
優れたユーザーエクスペリエンスを提供するために、ウェブサイトは最大限のコンテンツペイントを維持するよう努めるべきである。2.5秒ほとんどのユーザーに対して推奨目標を達成できるようにするには、適切な測定しきい値は次のとおりです。75パーセンタイルこのしきい値はモバイルデバイスとデスクトップデバイスの両方に適用されます
これらの推奨値の背後にある研究と方法論の詳細については、以下を参照してください。コアウェブメトリックのメトリックしきい値を定義する
どのような要素が考慮されますか?
現在の最大コンテンツ描画可能 APIの規定によれば、最大限のコンテンツ描画が考慮される要素タイプは次のとおりです。
画像
要素- 埋め込まれている
svg
要素内部画像
要素 ビデオ
要素(カバー画像を使用)- 合格url()関数(使用するのではなくCSSグラデーション)背景画像が読み込まれた要素
- テキストノードまたはその他のインラインレベルのテキスト要素の子要素が含まれますブロックレベル要素。
初期段階ではシンプルさを保つため、意図的に要素の種類をこれらの数種類に限定しています。将来的には他の要素を追加する可能性があります(例:svg
、 ビデオ
)。
要素のサイズを決定するにはどうすればよいでしょうか?
最大コンテンツ描画可能領域として報告される要素のサイズは、通常、ビューポート内でユーザーに表示されるサイズです。要素がビューポートの外側にはみ出ている場合、または要素が切り取られている場合、あるいは要素に不可視領域が含まれている場合、オーバーフローこれらの部分は要素サイズにカウントされません。
のためにオリジナルサイズサイズ変更された画像要素の場合、指標に報告される要素サイズは、表示サイズと元のサイズのいずれか小さい方になります。例えば、元のサイズよりも大幅に小さく縮小された画像の場合は、画像の表示サイズのみが報告されますが、拡大または縮小されて大きくなった画像の場合は、元のサイズのみが報告されます。
テキスト要素の場合、メトリックではテキスト ノードのサイズ (すべてのテキスト ノードを含む最小の四角形) のみを考慮します。
すべての要素について、CSS で設定された余白、パディング、境界線は考慮されません。
どのテキストノードがどの要素に属しているかを判断するのは、時に難しい場合があります。特に、子要素にインライン要素とプレーンテキストノードの両方が含まれる場合や、ブロックレベル要素の一部である場合はなおさらです。重要なのは、各テキストノードは最も近いブロックレベルの祖先に(そしてその祖先にのみ)属しているということです。標準用語説明すると: 各テキストノードは包含ブロックの対応する要素。
最大のコンテンツペイントはいつ報告されますか?
Web ページは段階的に読み込まれることが多いため、ページ上の最大の要素が変更される場合があります。
この潜在的な変化を考慮するために、ブラウザは最大のコンテンツペイントタイプパフォーマンスエントリー最大のコンテンツ要素を識別する。しかし、後続のフレームをレンダリングした後、ブラウザは別のパフォーマンスエントリー。
例えば、テキストとヘッダー画像のあるページでは、ブラウザは最初にテキスト部分のみをレンダリングし、最大のコンテンツペイントアイテムの要素属性は通常、p
またはh1
最初の画像の読み込みが完了すると、ブラウザは2番目の画像を送信します。最大のコンテンツペイント要素属性は、画像
。
要素はレンダリングが完了し、ユーザーに表示されるようになった後にのみ、最大のコンテンツ要素とみなされることに注意してください。まだ読み込まれていない画像は「レンダリング済み」とはみなされません。フォントブロック期間ウェブフォントを使用するテキストノードでも同様です。この場合、小さい方の要素が最大のコンテンツ要素として報告される可能性がありますが、大きい方の要素のレンダリングが完了すると、別の要素によって大きい方の要素が最大のコンテンツ要素として報告されます。パフォーマンスエントリー対象者が報告します。
画像やフォントの遅延読み込みに加えて、新しいコンテンツが利用可能になると、ページはDOMに新しい要素を追加することがあります。新しい要素のいずれかが以前の最大のコンテンツ要素よりも大きい場合、ブラウザは新しい要素を報告します。パフォーマンスエントリー。
現在の最大のコンテンツ要素がビューポートから(または DOM から)削除された場合、より大きな要素のレンダリングが完了するまで、そのコンテンツ要素は引き続き最大のコンテンツ要素になります。
Chrome 88 より前では、削除された要素は最大のコンテンツ要素とはみなされず、現在の候補を削除するとブラウザは新しい要素をディスパッチしていました。最大のコンテンツペイントただし、この指標は、DOM要素が削除されることが多い画像カルーセルなどの一般的なUIパターンにおけるユーザーエクスペリエンスをより正確に反映するように更新されました。変更履歴 詳細についてはこちらをご覧ください。
ユーザーがページを操作(タップ、スクロール、キーを押すなど)すると、ブラウザはすぐに新しいアイテムの報告を停止します。これは、ユーザーの操作によってユーザーに表示されるコンテンツが頻繁に変更されるためです(スクロール時に特に当てはまります)。
分析目的のため、最も最近配布されたものだけを報告する必要があります。パフォーマンスエントリー。
ユーザーはバックグラウンド タブでページを開き、ページが最初に読み込まれたときよりもずっと後にそのタブにフォーカスを当てることができるため、ユーザーがタブにフォーカスを当てるまで、最大限のコンテンツ ペイントが行われない可能性があります。
読み込み時間とレンダリング時間
安全上の理由から、タイミング許可原点ヘッダーでは、画像のレンダリングタイムスタンプは公開されません。代わりに、画像の読み込み時間のみが公開されます(読み込み時間は既に他の多くのWeb APIで公開されているため)。
下に使用例レンダリング時間が利用できない要素の処理方法について説明します。ただし、常に設定することをお勧めします。タイミング許可原点ヘッダーが追加され、メトリックの精度が向上します。
要素のレイアウトと要素のサイズの変更をどのように処理しますか?
新しいパフォーマンスエントリの計算と配布にかかるコストを抑えるため、要素のサイズや位置を変更しても新しいLCP候補は生成されません。表示領域内の要素の初期サイズと位置のみが考慮されます。
つまり、最初はオフスクリーンでレンダリングされ、その後画面上に遷移した画像は、そのように報告されない可能性があります。また、最初はビューポート内でレンダリングされ、その後ビューポート外に押し出された要素も、当初のサイズはビューポート内にあると報告されます。
例
以下に、いくつかの人気サイトで最大のコンテンツ ペイントが発生する例をいくつか示します。
上記の2つのタイムラインでは、コンテンツの読み込みに伴って最大要素が変化しています。最初の例では、DOMに新しいコンテンツが追加され、最大要素が変化しています。2番目の例では、レイアウト変更により、以前は最大だったコンテンツが表示領域から削除されています。
遅延読み込みされたコンテンツは、ページ上に既に存在するコンテンツよりも大きくなることが多いですが、必ずしもそうとは限りません。次の2つの例は、ページが完全に読み込まれる前に表示される最大のコンテンツペイントを示しています。
最初の例では、Instagramのロゴは比較的早く読み込まれ、他のコンテンツが後から表示されても最大の要素として残っています。Google検索結果ページの例では、最大の要素は画像やロゴの読み込みが完了する前に表示されるテキストブロックです。個々の画像はすべてテキストよりも小さいため、読み込みプロセス全体を通して最大の要素として残っています。
Instagramのタイムラインの最初のフレームで、カメラアイコンが緑色の枠で囲まれていないことに気づいたかもしれません。これは、アイコンがsvg
要素、およびsvg
この要素は現在LCP候補とはみなされません。最初のLCP候補は2番目のフレーム内のテキストです。
LCPの測定方法
LCPは研究室測定または実際の以下のツールで測定および使用できます。
測定ツール
- Chrome ユーザー エクスペリエンス レポート
- PageSpeed Insights ウェブページ速度測定ツール
- Search Console(コアウェブ指標レポート)
- web-vitals JavaScript ライブラリ
実験器具
JavaScriptでLCPを測定する
JavaScriptでLCPを測定するには、最大コンテンツ描画可能 API 次の例は、パフォーマンスオブザーバー最大のコンテンツフルペイントエントリをリッスンし、コンソールにログを記録します。
新しいパフォーマンスオブザーバー((エントリリスト) => {
for (entryList.getEntries() の定数エントリ) {
console.log('LCP 候補:', entry.startTime, entry);
}
}).observe({type: 'largest-contentful-paint', buffered: true});
上記のコードは、最大のコンテンツペイントエントリはコンソールに記録されますが、JavaScriptでLCPを測定するのはより複雑です。詳細は以下をご覧ください。
上記の例では、記録された各最大のコンテンツペイントエントリは現在のLCP候補を表します。通常、最新のエントリによって生成されたstartTime値がLCP値となりますが、必ずしもそうとは限りません。最大のコンテンツペイントアイテムを使用して LCP を測定できます。
次のセクションでは、API がレポートする内容とメトリックの計算方法の違いについて説明します。
指標とAPIの違い
- API は、バックグラウンド タブに読み込まれたページの最大コンテンツ ペイント エントリを配布しますが、これらのページは LCP の計算時には無視する必要があります。
- API は、ページがバックグラウンドに移動した後も、largest-contentful-paint エントリを配布し続けます。ただし、これらのエントリは LCP の計算時には無視されます (要素は、ページが常にフォアグラウンドにある場合にのみ考慮されます)。
- ページが通過するとラウンドトリップキャッシュAPI は再開時に最大のコンテンツ ペイント エントリを報告しませんが、このような場合にはユーザーによる複数の異なるページ訪問となるため、LCP を測定する必要があります。
- APIはiframe内の要素を考慮しませんが、LCPを正しく測定するには、それらを考慮する必要があります。子フレームはAPIを使用して、これらの要素のlargest-contentful-paintエントリを親フレームに報告し、集計することができます。
開発者は、これらのニュアンスをすべて覚える代わりに、web-vitals JavaScript ライブラリLCP を測定するために、ライブラリはこれらの違いを自ら処理します (可能な場合)。
'web-vitals' から {getLCP} をインポートします。
// LCP が利用可能になったらすぐに測定してログに記録します。
getLCP(console.log);
JavaScript で LCP を測定する方法の完全な例については、getLCP() のソース コードを参照してください。
場合によっては(クロスドメインのiframeなど)、JavaScriptではLCPを測定できません。詳細については、web-vitalsライブラリをご覧ください。制限一部。
最大の要素が最も重要な要素ではない場合はどうなるでしょうか?
場合によっては、ページ上で最も重要な要素が最大の要素ではないこともあり、開発者は前者のレンダリング時間を測定することに関心があるかもしれません。要素タイミングAPIこれを実現するために、APIはカスタムインジケーター記事に記載されています。
LCPを改善する方法
LCP は主に次の 4 つの要因の影響を受けます。
- サーバーの応答時間が遅い
- JavaScriptとCSSはレンダリングをブロックします
- リソースの読み込み時間
- クライアント側レンダリング
LCPを改善する方法の詳細については、以下を参照してください。LCPの最適化LCP を向上させることができるその他の個別のパフォーマンス手法に関する詳細なガイダンスについては、以下を参照してください。
- PRPLモードを使用して即時ロードを実現する
- クリティカルレンダリングパスの最適化
- CSSを最適化する
- 画像を最適化する
- ウェブフォントを最適化する
- JavaScriptを最適化する(クライアント側でレンダリングされるウェブサイトの場合)