\n
\n
\n
\n \n

プレゼンテーション遅延によるInteraction to Next Paint (INP)の問題

\n \n

このページは、Interaction to Next Paint (INP)シリーズの一部です。INPは、ユーザーの操作から次の視覚的な更新が行われるまでの総時間を測定します。プレゼンテーション遅延は、インプット遅延処理時間に続く、INPの3番目で最後のフェーズです。INPについて初めて学ぶ場合は、まずINPの問題を特定して改善する方法のガイドを先にお読みください。

\n\n \n

簡単に説明すると、Interaction to Next Paint (INP)は、ユーザーがページを操作した後に、視覚的な変化が画面に表示されるまでの時間を測定します。このINPは、「インプット遅延」、「処理時間」、「プレゼンテーション遅延」の3つの要素に分解できます。

\n \n \n

プレゼンテーション遅延はINP全体の最大の要因であり、平均してINP全体の時間の約42%を占めています。レンダリングパイプラインを最適化し、HTML構造を簡素化することが、INPを改善するための最大の手段です。

\n\n \n
[include]toc.html[/include]
\n\n

プレゼンテーション遅延の仕組み

\n

プレゼンテーションは操作の最後のフェーズです。プレゼンテーション遅延は、操作の後にブラウザが視覚的な更新をレンダリングするのにかかる時間を表します。イベントハンドラーの実行が完了した時点から始まり、視覚的な変化を含む次のフレームがペイントされた時点で終了します。プレゼンテーション遅延は、レイアウトの複雑さ、DOMの大きさ、および必要なレンダリング処理の量など、さまざまな要因によって左右されます。

\n

inp 3 stage processing time highlighted

\n \n

Interaction to Next Paint (INP)は、「インプット遅延」、「処理時間」、「プレゼンテーション遅延」の3つのサブパーツに分解できます。

\n\n

プレゼンテーション遅延とINP

\n \n

プレゼンテーション遅延はINPの最後のフェーズです。平均して、プレゼンテーション遅延はINP全体の時間の約42%を占めており、操作の遅延を引き起こす最大の要因となっています。

\n

inp distribution input delay highlighted

\n

CoreDashでは、1時間あたり数百万件のCore Web Vitalsデータポイントを収集しています。そのデータに基づくと、プレゼンテーション遅延はInteraction to Next Paintの42%を占めています。これは、処理時間(40%)よりも多く、インプット遅延(18%)よりも大幅に長い割合です。最大の要因であるにもかかわらず、プレゼンテーション遅延はアプリケーションコードではなくブラウザのレンダリングパイプラインが関係するため、最も最適化が難しいフェーズであることが多いです。

\n\n

プレゼンテーション遅延の例: スマートフォンで靴を探すためにECサイトを閲覧しているとします。製品画像をタップして詳細を表示しようとしましたが、使用しているスマートフォンが少し古いため、処理が追いつきません。\n\n画像をタップします(操作)。スマートフォンがリクエストを処理して画面を更新するまでに時間がかかります(処理時間)。ウェブサイトは、拡大画像と詳細情報を含む新しいページをレンダリングする必要があります。最終的に、新しい製品の詳細と画像が画面に表示されるまでに、明らかに認識できるほどの時間がかかります(プレゼンテーション遅延)。このINPの遅延はユーザーに不満を与えるため、修正することが重要です。

\n\n

プレゼンテーション遅延が長くなる原因

\n \n

プレゼンテーション遅延には、イベントハンドラーの実行が完了してから画面にピクセルが表示されるまでにブラウザが行うすべての処理が含まれます。これには、スタイルの再計算、レイアウトの計算、ペイント、コンポジット処理が含まれます。プレゼンテーション遅延が長くなる原因には、いくつかの要因があります。

\n\n

DOMサイズの肥大化

\n \n

DOMが大きかったり、ネストが深かったりすることは、プレゼンテーション遅延が長くなる最も一般的な原因の1つです。操作の後にブラウザがページの視覚的状態を更新する必要があるたびに、スタイルの再計算、レイアウトの計算、影響を受ける要素の再ペイントを行う必要があります。これらの各ステップのコストは、影響を受けるDOMノードの数に比例して増加します。

\n

Googleは、DOM要素数を1,400未満に抑え、最大深度を32レベル、親ノードあたりの子要素数を60個以下にすることを推奨しています(LighthouseのDOMサイズ監査を参照)。DOMがこれらのしきい値を超えると、ブラウザは操作のたびにスタイルの再計算とレイアウトの計算により多くの時間を費やすことになります。

\n

次のシナリオを考えてみましょう。ユーザーがボタンをクリックして、コンテナ要素のCSSクラスを切り替えます。そのコンテナに5,000個の子孫ノードがある場合、実際に視覚的に変化する要素がごく一部であっても、ブラウザは潜在的にすべてのノードのスタイルを再計算しなければなりません。このスタイルの再計算は次のペイントの前に同期的に発生するため、プレゼンテーション遅延が直接的に増加します。

\n

DOMを削減するための具体的な方法については、過大なDOMサイズの修正のガイドを参照してください。

\n\n

過度なレイアウト処理

\n \n

レイアウト(「リフロー」とも呼ばれます)は、ブラウザがページ上のすべての表示要素の位置と寸法を計算するプロセスです。DOMを変更したり、幾何形状に影響を与えるCSSプロパティ(width、height、margin、padding偏、top、left)を変更する操作の後、ブラウザは更新されたフレームをペイントする前にレイアウトを実行する必要があります。

\n

プレゼンテーション遅延に特に悪影響を与える2つのパターンがあります。

\n

強制同期レイアウトは、JavaScriptがレイアウトを無効化するDOMの変更を行った後に、offsetHeightgetBoundingClientRect()などのレイアウトプロパティを読み取るときに発生します。ブラウザは正確な値を返すために、イベントハンドラー内で同期的にレイアウトを実行することを強制されます。このレイアウト処理は処理時間の一部となりますが、その後のDOM変更によってトリガーされる後続のレイアウトはプレゼンテーション遅延の一部となります。

\n

レイアウトスラッシングは、DOMへの書き込みとレイアウトプロパティの読み取りをループ内で繰り返すパターンです。読み取りが行われるたびにブラウザはレイアウトを再計算せざるを得なくなり、書き込みが行われるたびにレイアウトが再び無効化されます。これにより、1回の操作あたり数十回から数百回もの不要なレイアウト計算が発生する可能性があります。以下は、レイアウトスラッシングの例とその修正方法です。

\n
// 悪い例:ループ内でのレイアウトスラッシング\nfunction resizeItems() {\n  const items = document.querySelectorAll('.item');\n  items.forEach(item => {\n    // 読み取り(レイアウトを強制)\n    const parentWidth = item.parentElement.offsetWidth;\n    // 書き込み(レイアウトを無効化)\n    item.style.width = parentWidth + 'px';\n  });\n}\n\n// 良い例:読み取りと書き込みをそれぞれバッチ処理する\nfunction resizeItems() {\n  const items = document.querySelectorAll('.item');\n  // 最初にすべての値を読み取る\n  const widths = Array.from(items).map(\n    item => item.parentElement.offsetWidth\n  );\n  // その後、すべての値を書き込む\n  items.forEach((item, i) => {\n    item.style.width = widths[i] + 'px';\n  });\n}
\n\n

シングルページアプリケーション(SPA)におけるクライアントサイドレンダリング

\n \n

HTMLのクライアントサイドレンダリングは、特にシングルページアプリケーション(SPA)において、プレゼンテーション遅延に大きな影響を与える可能性があります。ユーザーの操作によってルート変更や大規模なUI更新がトリガーされると、SPAフレームワークは以下の処理を行う必要があります。

\n
    \n
  1. 仮想DOMの差分比較(diffing)アルゴリズムを実行して、変更箇所を特定する
  2. \n
  3. 差分結果 of DOM変更を実際のDOMに適用する
  4. \n
  5. 影響を受けるすべての要素に対してスタイルの再計算とレイアウトをトリガーする
  6. \n
  7. 更新されたフレームをペイントする
  8. \n
\n

Reactアプリケーションでは、仮想DOMの調停(reconciliation)プロセスは処理時間の一部ですが、結果として生じるDOM変更とそのレンダリングコストはプレゼンテーション遅延に含まれます。コンポーネントツリーによって生成されるDOMノードが多くなるほど、調停とそれに続くレンダリング処理の負荷が高くなります。

\n

ReactおよびNext.jsアプリケーションでこれを軽減するには:

\n
    \n
  • React.memo()を使用して、同じpropsを受け取る子コンポーネントの不要な再レンダリングを防ぎます。
  • \n
  • useDeferredValue()を負荷の高い再レンダリングをトリガーする値に使用し、Reactがより緊急性の高い更新を優先できるようにします。
  • \n
  • コンポーネントツリーを浅く保ちます。深くネストされたコンポーネント階層は深くネストされたDOMを生成し、調停とブラウザのレンダリングの両方のコストを増加させます。
  • \n
  • 次のような仮想化ライブラリ(react-window@tanstack/react-virtualなど)を長いリストに使用して、DOMに表示項目のみが含まれるようにします。
  • \n
\n\n

プレゼンテーション遅延の削減

\n\n

DOMサイズの最小化

\n

プレゼンテーション遅延の改善で最も効果的なのは、DOMを小さく保つことです。

\n
    \n
  • 未使用のHTML要素、特に深くネストされたラッパーdiv要素を削除します。
  • \n
  • 長いリストにはリスト仮想化を使用します(表示されている項目と少量のバッファのみをレンダリングします)。
  • \n
  • 可能な限り、深くネストされた構造をフラットにします。
  • \n
  • レイアウトにはネストされたdiv要素の代わりにCSS GridやFlexboxを使用します。
  • \n
\n \n
// DOMサイズを削減するために長いリストを仮想化する\n// 改善前:DOM内に10,000個の項目\n\n<ul>\n  {allItems.map(item => \n     <li key=\"{item.id}\">{item.name}</li>)\n   }\n</ul>\n\n// 改善後:DOM内には表示されている項目のみ(react-windowを使用)\nimport { FixedSizeList } from 'react-window';\n<fixedsizelist height=\"{600}\" \n               itemcount=\"{allItems.length}\" \n               itemsize=\"{50}\" width=\"100%\">  \n  {({ index, style }) => (\n    <div style=\"{style}\">{allItems[index].name}</div>\n  )}\n</fixedsizelist>\n
\n\n \n

content-visibilityを使用して画面外のコンテンツを遅延レンダリングする

\n

CSSのcontent-visibilityプロパティは、ユーザーがその近くにスクロールするまで画面外コンテンツのレンダリングをスキップするようブラウザに指示します。これにより、スタイルの再計算とレイアウトの範囲をページの表示部分のみに限定し、操作時のレンダリング処理の量を削減します。

\n
/* ファーストビュー以下のセクションにcontent-visibilityを適用 */\n.below-fold-section {\n  content-visibility: auto;\n  contain-intrinsic-size: auto 500px;\n}\n\n/* 長いリストの個々の項目に適用 */\n.list-item {\n  content-visibility: auto;\n  contain-intrinsic-size: auto 80px;\n}
\n

contain-intrinsic-sizeプロパティは推定の高さを提供し、ブラウザがコンテンツをレンダリングせずにスクロールバーのサイズを正しく計算できるようにします。これにより、ユーザーがスクロールしてコンテンツが表示される際のレイアウトシフトを防ぎます。

\n

レンダリングコストを削減するその他のCSS最適化戦略については、未使用のCSSの削除のガイドを参照してください。

\n\n

操作によってトリガーされるレイアウト処理を最小限に抑える

\n

操作を設計する際は、レイアウトをトリガーしないCSSプロパティを優先してください。例えば、transformopacityなどのプロパティは、レイアウトやペイントをトリガーせずにGPUコンポジターで処理できます。topleftwidth、またはheightをアニメーション化する代わりに、transform: translate()transform: scale()使用してください。レイアウトをトリガーするCSSプロパティの完全なリストについては、web.devのレンダリングパフォーマンスガイドを参照してください。

\n

CSSのwill-changeプロパティを使用して、要素がアニメーション化されることをブラウザにヒントとして伝えます。これにより、ブラウザは要素に対して個別のコンポジターレイヤーを作成し、そのレンダリングをページの他の部分から分離できます:

\n
/* 要素を独自のコンポジターレイヤーに昇格させる */\n.animated-element {\n  will-change: transform, opacity;\n}\n\n/* displayの代わりにopacityで可視性を切り替える */\n.modal {\n  opacity: 0;\n  pointer-events: none;\n  transform: translateY(10px);\n  transition: opacity 0.2s, transform 0.2s;\n}\n\n.modal.active {\n  opacity: 1;\n  pointer-events: auto;\n  transform: translateY(0);\n}
\n\n

長いプレゼンテーション遅延の特定

\n

長いプレゼンテーション遅延を特定するには、Chromeのパフォーマンスプロファイラーを使用できます。DevTools(Ctrl+Shift+I)を開き、Performanceタブに移動して記録を開始し、ページを操作します。

\n

その後、操作のタイムラインを分析して、プレゼンテーション遅延を含むさまざまなフェーズを可視化できます。イベントハンドラーの実行終了後に発生するレンダリング更新を調査することで、長いプレゼンテーション遅延の原因となっているボトルネックをピンポイントで特定できます。タイムライン上で「Recalculate Style(スタイルの再計算)」、「Layout(レイアウト)」、「Paint(ペイント)」の大きなエントリを探してください。これらは、プレゼンテーション遅延フェーズ中にブラウザが行う処理を表しています。

\n

inp presentation delay devtools

\n\n

RUMデータによるプレゼンテーション遅延の特定

\n
Real User Monitoring (RUM)は、Interaction to Next Paintや、プレゼンテーション遅延を含むそのサブパーツといった、重要なCore Web Vitals関連指標のリアルタイム更新を提供します。CoreDashなどのRUMツールは、各INP操作を3つのフェーズに分解するため、特定のページやユーザーセグメントにおいてプレゼンテーション遅延がボトルネックになっているかどうかを確認できます。
\n\n \n

Long Animation Frames (LoAF)によるプレゼンテーション遅延の測定

\n

Long Animation Frames (LoAF) APIは、ユーザー操作中のレンダリング遅延の原因を正確に示します。このAPIは、処理時間とプレゼンテーション遅延を分離するためのタイミングデータを提供し、どのスクリプトがレンダリングを遅らせているかを特定するのに役立ちます。

\n

プレゼンテーション遅延を理解するための重要なLoAFプロパティは以下の通りです:

\n
    \n
  • renderStart:ブラウザがレンダリングフェーズ(スタイルの再計算、レイアウト、ペイント)を開始した時間
  • \n
  • styleAndLayoutStart:スタイルとレイアウトの計算が開始された時間
  • \n
  • duration:ロングアニメーションフレームの総時間
  • \n
  • blockingDuration:スクリプトによってフレームがブロックされた時間
  • \n
\n

LoAFは現在Chromiumのみ(Chrome 123以降)でサポートされています。他のブラウザでは、Chrome DevToolsのPerformanceパネルのトレースを使用してレンダリング処理を分析してください。

\n

スクリプト実行の終了からフレームの終了までの差が、純粋なレンダリングコストであり、これがプレゼンテーション遅延に相当します。このデータを観察してログに記録する方法は以下の通りです:

\n
// LoAF APIを使用してプレゼンテーション遅延を測定する\nconst observer = new PerformanceObserver((list) => {\n  for (const entry of list.getEntries()) {\n    if (entry.duration > 50) {\n      const scriptEnd = Math.max(\n        ...entry.scripts.map(s => s.startTime + s.duration)\n      );\n      const presentationDelay = (\n        entry.startTime + entry.duration\n      ) - Math.max(scriptEnd, entry.renderStart);\n\n      console.log('Presentation delay breakdown:', {\n        totalDuration: entry.duration,\n        renderStart: entry.renderStart,\n        styleAndLayoutStart: entry.styleAndLayoutStart,\n        estimatedPresentationDelay: presentationDelay,\n        scriptCount: entry.scripts.length\n      });\n    }\n  }\n});\n\nobserver.observe({\n  type: 'long-animation-frame',\n  buffered: true\n});
\n

CoreDashなどのRUMツールはLoAFデータを統合し、どのスクリプトやDOM変更がレンダリング遅延の原因になっているかを、完全なスクリプトアトリビューションとともに表示します。

\n\n \n

他のINPフェーズの確認

\n

INPをコントロールするには、他の2つのフェーズにも対処する必要があります:

\n
    \n
  • Input Delay:イベントハンドラーが実行を開始するまでの待ち時間を最小限に抑えます。インプット遅延は通常、最も短いフェーズですが、メインスレッドがビジー状態になるページの起動時に急増します。
  • \n
  • Processing Time:操作中に実行されるイベントハンドラーコードを最適化します。ほとんどのページでは、ここに最適化作業の大部分の労力を費やすことで効果が得られます。
  • \n
\n

完全な診断ワークフローについては、INP問題の特定と修正のガイドを参照してください。追加のレンダリング最適化戦略については、過大なDOMサイズの修正未使用のCSSの削除のガイドを参照してください。全体の概要については、INPのハブページに戻ってください。

\n\n
\n
[include]sidebarcwv.html[/include]
\n
\n
\n [include]blogfooter.html[/include]" }" /> \n
\n
\n
\n \n

プレゼンテーション遅延によるInteraction to Next Paint (INP)の問題

\n \n

このページは、Interaction to Next Paint (INP)シリーズの一部です。INPは、ユーザーの操作から次の視覚的な更新が行われるまでの総時間を測定します。プレゼンテーション遅延は、インプット遅延処理時間に続く、INPの3番目で最後のフェーズです。INPについて初めて学ぶ場合は、まずINPの問題を特定して改善する方法のガイドを先にお読みください。

\n\n \n

簡単に説明すると、Interaction to Next Paint (INP)は、ユーザーがページを操作した後に、視覚的な変化が画面に表示されるまでの時間を測定します。このINPは、「インプット遅延」、「処理時間」、「プレゼンテーション遅延」の3つの要素に分解できます。

\n \n \n

プレゼンテーション遅延はINP全体の最大の要因であり、平均してINP全体の時間の約42%を占めています。レンダリングパイプラインを最適化し、HTML構造を簡素化することが、INPを改善するための最大の手段です。

\n\n

プレゼンテーション遅延:ボタンをクリックした際、結果が表示されるまでにほんの少し時間がかかりすぎると感じたことはありませんか?それがInteraction to Next Paint (INP)の動作です。プレゼンテーション遅延は操作プロセスの最後のステップであり、クリック処理が完了した後、視覚的な変化が表示される前に発生します。

\n
[include]toc.html[/include]
\n\n

プレゼンテーション遅延の仕組み

\n

プレゼンテーションは操作の最後のフェーズです。プレゼンテーション遅延は、操作の後にブラウザが視覚的な更新をレンダリングするのにかかる時間を表します。イベントハンドラーの実行が完了した時点から始まり、視覚的な変化を含む次のフレームがペイントされた時点で終了します。プレゼンテーション遅延は、レイアウトの複雑さ、DOMの大きさ、および必要なレンダリング処理の量など、さまざまな要因によって左右されます。

\n

inp 3 stage processing time highlighted

\n \n

Interaction to Next Paint (INP)は、「インプット遅延」、「処理時間」、「プレゼンテーション遅延」の3つのサブパーツに分解できます。

\n\n

プレゼンテーション遅延とINP

\n \n

プレゼンテーション遅延はINPの最後のフェーズです。平均して、プレゼンテーション遅延はINP全体の時間の約42%を占めており、操作の遅延を引き起こす最大の要因となっています。

\n

inp distribution input delay highlighted

\n

CoreDashでは、1時間あたり数百万件のCore Web Vitalsデータポイントを収集しています。そのデータに基づくと、プレゼンテーション遅延はInteraction to Next Paintの42%を占めています。これは、処理時間(40%)よりも多く、インプット遅延(18%)よりも大幅に長い割合です。最大の要因であるにもかかわらず、プレゼンテーション遅延はアプリケーションコードではなくブラウザのレンダリングパイプラインが関係するため、最も最適化が難しいフェーズであることが多いです。

\n\n

プレゼンテーション遅延の例: スマートフォンで靴を探すためにECサイトを閲覧しているとします。製品画像をタップして詳細を表示しようとしましたが、使用しているスマートフォンが少し古いため、処理が追いつきません。\n\n画像をタップします(操作)。スマートフォンがリクエストを処理して画面を更新するまでに時間がかかります(処理時間)。ウェブサイトは、拡大画像と詳細情報を含む新しいページをレンダリングする必要があります。最終的に、新しい製品の詳細と画像が画面に表示されるまでに、明らかに認識できるほどの時間がかかります(プレゼンテーション遅延)。このINPの遅延はユーザーに不満を与えるため、修正することが重要です。

\n\n

プレゼンテーション遅延が長くなる原因

\n \n

プレゼンテーション遅延には、イベントハンドラーの実行が完了してから画面にピクセルが表示されるまでにブラウザが行うすべての処理が含まれます。これには、スタイルの再計算、レイアウトの計算、ペイント、コンポジット処理が含まれます。プレゼンテーション遅延が長くなる原因には、いくつかの要因があります。

\n\n

DOMサイズの肥大化

\n \n

DOMが大きかったり、ネストが深かったりすることは、プレゼンテーション遅延が長くなる最も一般的な原因の1つです。操作の後にブラウザがページの視覚的状態を更新する必要があるたびに、スタイルの再計算、レイアウトの計算、影響を受ける要素の再ペイントを行う必要があります。これらの各ステップのコストは、影響を受けるDOMノードの数に比例して増加します。

\n

Googleは、DOM要素数を1,400未満に抑え、最大深度を32レベル、親ノードあたりの子要素数を60個以下にすることを推奨しています(LighthouseのDOMサイズ監査を参照)。DOMがこれらのしきい値を超えると、ブラウザは操作のたびにスタイルの再計算とレイアウトの計算により多くの時間を費やすことになります。

\n

次のシナリオを考えてみましょう。ユーザーがボタンをクリックして、コンテナ要素のCSSクラスを切り替えます。そのコンテナに5,000個の子孫ノードがある場合、実際に視覚的に変化する要素がごく一部であっても、ブラウザは潜在的にすべてのノードのスタイルを再計算しなければなりません。このスタイルの再計算は次のペイントの前に同期的に発生するため、プレゼンテーション遅延が直接的に増加します。

\n

DOMを削減するための具体的な方法については、過大なDOMサイズの修正のガイドを参照してください。

\n\n

過度なレイアウト処理

\n \n

レイアウト(「リフロー」とも呼ばれます)は、ブラウザがページ上のすべての表示要素の位置と寸法を計算するプロセスです。DOMを変更したり、幾何形状に影響を与えるCSSプロパティ(width、height、margin、padding偏、top、left)を変更する操作の後、ブラウザは更新されたフレームをペイントする前にレイアウトを実行する必要があります。

\n

プレゼンテーション遅延に特に悪影響を与える2つのパターンがあります。

\n

強制同期レイアウトは、JavaScriptがレイアウトを無効化するDOMの変更を行った後に、offsetHeightgetBoundingClientRect()などのレイアウトプロパティを読み取るときに発生します。ブラウザは正確な値を返すために、イベントハンドラー内で同期的にレイアウトを実行することを強制されます。このレイアウト処理は処理時間の一部となりますが、その後のDOM変更によってトリガーされる後続のレイアウトはプレゼンテーション遅延の一部となります。

\n

レイアウトスラッシングは、DOMへの書き込みとレイアウトプロパティの読み取りをループ内で繰り返すパターンです。読み取りが行われるたびにブラウザはレイアウトを再計算せざるを得なくなり、書き込みが行われるたびにレイアウトが再び無効化されます。これにより、1回の操作あたり数十回から数百回もの不要なレイアウト計算が発生する可能性があります。以下は、レイアウトスラッシングの例とその修正方法です。

\n
// 悪い例:ループ内でのレイアウトスラッシング\nfunction resizeItems() {\n  const items = document.querySelectorAll('.item');\n  items.forEach(item => {\n    // 読み取り(レイアウトを強制)\n    const parentWidth = item.parentElement.offsetWidth;\n    // 書き込み(レイアウトを無効化)\n    item.style.width = parentWidth + 'px';\n  });\n}\n\n// 良い例:読み取りと書き込みをそれぞれバッチ処理する\nfunction resizeItems() {\n  const items = document.querySelectorAll('.item');\n  // 最初にすべての値を読み取る\n  const widths = Array.from(items).map(\n    item => item.parentElement.offsetWidth\n  );\n  // その後、すべての値を書き込む\n  items.forEach((item, i) => {\n    item.style.width = widths[i] + 'px';\n  });\n}
\n\n

シングルページアプリケーション(SPA)におけるクライアントサイドレンダリング

\n \n

HTMLのクライアントサイドレンダリングは、特にシングルページアプリケーション(SPA)において、プレゼンテーション遅延に大きな影響を与える可能性があります。ユーザーの操作によってルート変更や大規模なUI更新がトリガーされると、SPAフレームワークは以下の処理を行う必要があります。

\n
    \n
  1. 仮想DOMの差分比較(diffing)アルゴリズムを実行して、変更箇所を特定する
  2. \n
  3. 差分結果 of DOM変更を実際のDOMに適用する
  4. \n
  5. 影響を受けるすべての要素に対してスタイルの再計算とレイアウトをトリガーする
  6. \n
  7. 更新されたフレームをペイントする
  8. \n
\n

Reactアプリケーションでは、仮想DOMの調停(reconciliation)プロセスは処理時間の一部ですが、結果として生じるDOM変更とそのレンダリングコストはプレゼンテーション遅延に含まれます。コンポーネントツリーによって生成されるDOMノードが多くなるほど、調停とそれに続くレンダリング処理の負荷が高くなります。

\n

ReactおよびNext.jsアプリケーションでこれを軽減するには:

\n
    \n
  • React.memo()を使用して、同じpropsを受け取る子コンポーネントの不要な再レンダリングを防ぎます。
  • \n
  • useDeferredValue()を負荷の高い再レンダリングをトリガーする値に使用し、Reactがより緊急性の高い更新を優先できるようにします。
  • \n
  • コンポーネントツリーを浅く保ちます。深くネストされたコンポーネント階層は深くネストされたDOMを生成し、調停とブラウザのレンダリングの両方のコストを増加させます。
  • \n
  • 次のような仮想化ライブラリ(react-window@tanstack/react-virtualなど)を長いリストに使用して、DOMに表示項目のみが含まれるようにします。
  • \n
\n\n

プレゼンテーション遅延の削減

\n\n

DOMサイズの最小化

\n

プレゼンテーション遅延の改善で最も効果的なのは、DOMを小さく保つことです。

\n
    \n
  • 未使用のHTML要素、特に深くネストされたラッパーdiv要素を削除します。
  • \n
  • 長いリストにはリスト仮想化を使用します(表示されている項目と少量のバッファのみをレンダリングします)。
  • \n
  • 可能な限り、深くネストされた構造をフラットにします。
  • \n
  • レイアウトにはネストされたdiv要素の代わりにCSS GridやFlexboxを使用します。
  • \n
\n \n
// DOMサイズを削減するために長いリストを仮想化する\n// 改善前:DOM内に10,000個の項目\n\n<ul>\n  {allItems.map(item => \n     <li key=\"{item.id}\">{item.name}</li>)\n   }\n</ul>\n\n// 改善後:DOM内には表示されている項目のみ(react-windowを使用)\nimport { FixedSizeList } from 'react-window';\n<fixedsizelist height=\"{600}\" \n               itemcount=\"{allItems.length}\" \n               itemsize=\"{50}\" width=\"100%\">  \n  {({ index, style }) => (\n    <div style=\"{style}\">{allItems[index].name}</div>\n  )}\n</fixedsizelist>\n
\n\n \n

content-visibilityを使用して画面外のコンテンツを遅延レンダリングする

\n

CSSのcontent-visibilityプロパティは、ユーザーがその近くにスクロールするまで画面外コンテンツのレンダリングをスキップするようブラウザに指示します。これにより、スタイルの再計算とレイアウトの範囲をページの表示部分のみに限定し、操作時のレンダリング処理の量を削減します。

\n
/* ファーストビュー以下のセクションにcontent-visibilityを適用 */\n.below-fold-section {\n  content-visibility: auto;\n  contain-intrinsic-size: auto 500px;\n}\n\n/* 長いリストの個々の項目に適用 */\n.list-item {\n  content-visibility: auto;\n  contain-intrinsic-size: auto 80px;\n}
\n

contain-intrinsic-sizeプロパティは推定の高さを提供し、ブラウザがコンテンツをレンダリングせずにスクロールバーのサイズを正しく計算できるようにします。これにより、ユーザーがスクロールしてコンテンツが表示される際のレイアウトシフトを防ぎます。

\n

レンダリングコストを削減するその他のCSS最適化戦略については、未使用のCSSの削除のガイドを参照してください。

\n\n

操作によってトリガーされるレイアウト処理を最小限に抑える

\n

操作を設計する際は、レイアウトをトリガーしないCSSプロパティを優先してください。例えば、transformopacityなどのプロパティは、レイアウトやペイントをトリガーせずにGPUコンポジターで処理できます。topleftwidth、またはheightをアニメーション化する代わりに、transform: translate()transform: scale()使用してください。レイアウトをトリガーするCSSプロパティの完全なリストについては、web.devのレンダリングパフォーマンスガイドを参照してください。

\n

CSSのwill-changeプロパティを使用して、要素がアニメーション化されることをブラウザにヒントとして伝えます。これにより、ブラウザは要素に対して個別のコンポジターレイヤーを作成し、そのレンダリングをページの他の部分から分離できます:

\n
/* 要素を独自のコンポジターレイヤーに昇格させる */\n.animated-element {\n  will-change: transform, opacity;\n}\n\n/* displayの代わりにopacityで可視性を切り替える */\n.modal {\n  opacity: 0;\n  pointer-events: none;\n  transform: translateY(10px);\n  transition: opacity 0.2s, transform 0.2s;\n}\n\n.modal.active {\n  opacity: 1;\n  pointer-events: auto;\n  transform: translateY(0);\n}
\n\n

長いプレゼンテーション遅延の特定

\n

長いプレゼンテーション遅延を特定するには、Chromeのパフォーマンスプロファイラーを使用できます。DevTools(Ctrl+Shift+I)を開き、Performanceタブに移動して記録を開始し、ページを操作します。

\n

その後、操作のタイムラインを分析して、プレゼンテーション遅延を含むさまざまなフェーズを可視化できます。イベントハンドラーの実行終了後に発生するレンダリング更新を調査することで、長いプレゼンテーション遅延の原因となっているボトルネックをピンポイントで特定できます。タイムライン上で「Recalculate Style(スタイルの再計算)」、「Layout(レイアウト)」、「Paint(ペイント)」の大きなエントリを探してください。これらは、プレゼンテーション遅延フェーズ中にブラウザが行う処理を表しています。

\n

inp presentation delay devtools

\n\n

RUMデータによるプレゼンテーション遅延の特定

\n
Real User Monitoring (RUM)は、Interaction to Next Paintや、プレゼンテーション遅延を含むそのサブパーツといった、重要なCore Web Vitals関連指標のリアルタイム更新を提供します。CoreDashなどのRUMツールは、各INP操作を3つのフェーズに分解するため、特定のページやユーザーセグメントにおいてプレゼンテーション遅延がボトルネックになっているかどうかを確認できます。
\n\n \n

Long Animation Frames (LoAF)によるプレゼンテーション遅延の測定

\n

Long Animation Frames (LoAF) APIは、ユーザー操作中のレンダリング遅延の原因を正確に示します。このAPIは、処理時間とプレゼンテーション遅延を分離するためのタイミングデータを提供し、どのスクリプトがレンダリングを遅らせているかを特定するのに役立ちます。

\n

プレゼンテーション遅延を理解するための重要なLoAFプロパティは以下の通りです:

\n
    \n
  • renderStart:ブラウザがレンダリングフェーズ(スタイルの再計算、レイアウト、ペイント)を開始した時間
  • \n
  • styleAndLayoutStart:スタイルとレイアウトの計算が開始された時間
  • \n
  • duration:ロングアニメーションフレームの総時間
  • \n
  • blockingDuration:スクリプトによってフレームがブロックされた時間
  • \n
\n

LoAFは現在Chromiumのみ(Chrome 123以降)でサポートされています。他のブラウザでは、Chrome DevToolsのPerformanceパネルのトレースを使用してレンダリング処理を分析してください。

\n

スクリプト実行の終了からフレームの終了までの差が、純粋なレンダリングコストであり、これがプレゼンテーション遅延に相当します。このデータを観察してログに記録する方法は以下の通りです:

\n
// LoAF APIを使用してプレゼンテーション遅延を測定する\nconst observer = new PerformanceObserver((list) => {\n  for (const entry of list.getEntries()) {\n    if (entry.duration > 50) {\n      const scriptEnd = Math.max(\n        ...entry.scripts.map(s => s.startTime + s.duration)\n      );\n      const presentationDelay = (\n        entry.startTime + entry.duration\n      ) - Math.max(scriptEnd, entry.renderStart);\n\n      console.log('Presentation delay breakdown:', {\n        totalDuration: entry.duration,\n        renderStart: entry.renderStart,\n        styleAndLayoutStart: entry.styleAndLayoutStart,\n        estimatedPresentationDelay: presentationDelay,\n        scriptCount: entry.scripts.length\n      });\n    }\n  }\n});\n\nobserver.observe({\n  type: 'long-animation-frame',\n  buffered: true\n});
\n

CoreDashなどのRUMツールはLoAFデータを統合し、どのスクリプトやDOM変更がレンダリング遅延の原因になっているかを、完全なスクリプトアトリビューションとともに表示します。

\n\n \n

他のINPフェーズの確認

\n

INPをコントロールするには、他の2つのフェーズにも対処する必要があります:

\n
    \n
  • Input Delay:イベントハンドラーが実行を開始するまでの待ち時間を最小限に抑えます。インプット遅延は通常、最も短いフェーズですが、メインスレッドがビジー状態になるページの起動時に急増します。
  • \n
  • Processing Time:操作中に実行されるイベントハンドラーコードを最適化します。ほとんどのページでは、ここに最適化作業の大部分の労力を費やすことで効果が得られます。
  • \n
\n

完全な診断ワークフローについては、INP問題の特定と修正のガイドを参照してください。追加のレンダリング最適化戦略については、過大なDOMサイズの修正未使用のCSSの削除のガイドを参照してください。全体の概要については、INPのハブページに戻ってください。

\n\n
\n
[include]sidebarcwv.html[/include]
\n
\n
\n [include]blogfooter.html[/include]" }" /> \n
\n
\n
\n \n

プレゼンテーション遅延によるInteraction to Next Paint (INP)の問題

\n \n

このページは、Interaction to Next Paint (INP)シリーズの一部です。INPは、ユーザーの操作から次の視覚的な更新が行われるまでの総時間を測定します。プレゼンテーション遅延は、インプット遅延処理時間に続く、INPの3番目で最後のフェーズです。INPについて初めて学ぶ場合は、まずINPの問題を特定して改善する方法のガイドを先にお読みください。

\n\n \n

簡単に説明すると、Interaction to Next Paint (INP)は、ユーザーがページを操作した後に、視覚的な変化が画面に表示されるまでの時間を測定します。このINPは、「インプット遅延」、「処理時間」、「プレゼンテーション遅延」の3つの要素に分解できます。

\n \n \n

プレゼンテーション遅延はINP全体の最大の要因であり、平均してINP全体の時間の約42%を占めています。レンダリングパイプラインを最適化し、HTML構造を簡素化することが、INPを改善するための最大の手段です。

\n\n

プレゼンテーション遅延:ボタンをクリックした際、結果が表示されるまでにほんの少し時間がかかりすぎると感じたことはありませんか?それがInteraction to Next Paint (INP)の動作です。プレゼンテーション遅延は操作プロセスの最後のステップであり、クリック処理が完了した後、視覚的な変化が表示される前に発生します。

\n
[include]toc.html[/include]
\n\n

プレゼンテーション遅延の仕組み

\n

プレゼンテーションは操作の最後のフェーズです。プレゼンテーション遅延は、操作の後にブラウザが視覚的な更新をレンダリングするのにかかる時間を表します。イベントハンドラーの実行が完了した時点から始まり、視覚的な変化を含む次のフレームがペイントされた時点で終了します。プレゼンテーション遅延は、レイアウトの複雑さ、DOMの大きさ、および必要なレンダリング処理の量など、さまざまな要因によって左右されます。

\n

inp 3 stage processing time highlighted

\n \n

Interaction to Next Paint (INP)は、「インプット遅延」、「処理時間」、「プレゼンテーション遅延」の3つのサブパーツに分解できます。

\n\n

プレゼンテーション遅延とINP

\n \n

プレゼンテーション遅延はINPの最後のフェーズです。平均して、プレゼンテーション遅延はINP全体の時間の約42%を占めており、操作の遅延を引き起こす最大の要因となっています。

\n

inp distribution input delay highlighted

\n

CoreDashでは、1時間あたり数百万件のCore Web Vitalsデータポイントを収集しています。そのデータに基づくと、プレゼンテーション遅延はInteraction to Next Paintの42%を占めています。これは、処理時間(40%)よりも多く、インプット遅延(18%)よりも大幅に長い割合です。最大の要因であるにもかかわらず、プレゼンテーション遅延はアプリケーションコードではなくブラウザのレンダリングパイプラインが関係するため、最も最適化が難しいフェーズであることが多いです。

\n\n

プレゼンテーション遅延の例: スマートフォンで靴を探すためにECサイトを閲覧しているとします。製品画像をタップして詳細を表示しようとしましたが、使用しているスマートフォンが少し古いため、処理が追いつきません。\n\n画像をタップします(操作)。スマートフォンがリクエストを処理して画面を更新するまでに時間がかかります(処理時間)。ウェブサイトは、拡大画像と詳細情報を含む新しいページをレンダリングする必要があります。最終的に、新しい製品の詳細と画像が画面に表示されるまでに、明らかに認識できるほどの時間がかかります(プレゼンテーション遅延)。このINPの遅延はユーザーに不満を与えるため、修正することが重要です。

\n\n

プレゼンテーション遅延が長くなる原因

\n \n

プレゼンテーション遅延には、イベントハンドラーの実行が完了してから画面にピクセルが表示されるまでにブラウザが行うすべての処理が含まれます。これには、スタイルの再計算、レイアウトの計算、ペイント、コンポジット処理が含まれます。プレゼンテーション遅延が長くなる原因には、いくつかの要因があります。

\n\n

DOMサイズの肥大化

\n \n

DOMが大きかったり、ネストが深かったりすることは、プレゼンテーション遅延が長くなる最も一般的な原因の1つです。操作の後にブラウザがページの視覚的状態を更新する必要があるたびに、スタイルの再計算、レイアウトの計算、影響を受ける要素の再ペイントを行う必要があります。これらの各ステップのコストは、影響を受けるDOMノードの数に比例して増加します。

\n

Googleは、DOM要素数を1,400未満に抑え、最大深度を32レベル、親ノードあたりの子要素数を60個以下にすることを推奨しています(LighthouseのDOMサイズ監査を参照)。DOMがこれらのしきい値を超えると、ブラウザは操作のたびにスタイルの再計算とレイアウトの計算により多くの時間を費やすことになります。

\n

次のシナリオを考えてみましょう。ユーザーがボタンをクリックして、コンテナ要素のCSSクラスを切り替えます。そのコンテナに5,000個の子孫ノードがある場合、実際に視覚的に変化する要素がごく一部であっても、ブラウザは潜在的にすべてのノードのスタイルを再計算しなければなりません。このスタイルの再計算は次のペイントの前に同期的に発生するため、プレゼンテーション遅延が直接的に増加します。

\n

DOMを削減するための具体的な方法については、過大なDOMサイズの修正のガイドを参照してください。

\n\n

過度なレイアウト処理

\n \n

レイアウト(「リフロー」とも呼ばれます)は、ブラウザがページ上のすべての表示要素の位置と寸法を計算するプロセスです。DOMを変更したり、幾何形状に影響を与えるCSSプロパティ(width、height、margin、padding偏、top、left)を変更する操作の後、ブラウザは更新されたフレームをペイントする前にレイアウトを実行する必要があります。

\n

プレゼンテーション遅延に特に悪影響を与える2つのパターンがあります。

\n

強制同期レイアウトは、JavaScriptがレイアウトを無効化するDOMの変更を行った後に、offsetHeightgetBoundingClientRect()などのレイアウトプロパティを読み取るときに発生します。ブラウザは正確な値を返すために、イベントハンドラー内で同期的にレイアウトを実行することを強制されます。このレイアウト処理は処理時間の一部となりますが、その後のDOM変更によってトリガーされる後続のレイアウトはプレゼンテーション遅延の一部となります。

\n

レイアウトスラッシングは、DOMへの書き込みとレイアウトプロパティの読み取りをループ内で繰り返すパターンです。読み取りが行われるたびにブラウザはレイアウトを再計算せざるを得なくなり、書き込みが行われるたびにレイアウトが再び無効化されます。これにより、1回の操作あたり数十回から数百回もの不要なレイアウト計算が発生する可能性があります。以下は、レイアウトスラッシングの例とその修正方法です。

\n
// 悪い例:ループ内でのレイアウトスラッシング\nfunction resizeItems() {\n  const items = document.querySelectorAll('.item');\n  items.forEach(item => {\n    // 読み取り(レイアウトを強制)\n    const parentWidth = item.parentElement.offsetWidth;\n    // 書き込み(レイアウトを無効化)\n    item.style.width = parentWidth + 'px';\n  });\n}\n\n// 良い例:読み取りと書き込みをそれぞれバッチ処理する\nfunction resizeItems() {\n  const items = document.querySelectorAll('.item');\n  // 最初にすべての値を読み取る\n  const widths = Array.from(items).map(\n    item => item.parentElement.offsetWidth\n  );\n  // その後、すべての値を書き込む\n  items.forEach((item, i) => {\n    item.style.width = widths[i] + 'px';\n  });\n}
\n\n

シングルページアプリケーション(SPA)におけるクライアントサイドレンダリング

\n \n

HTMLのクライアントサイドレンダリングは、特にシングルページアプリケーション(SPA)において、プレゼンテーション遅延に大きな影響を与える可能性があります。ユーザーの操作によってルート変更や大規模なUI更新がトリガーされると、SPAフレームワークは以下の処理を行う必要があります。

\n
    \n
  1. 仮想DOMの差分比較(diffing)アルゴリズムを実行して、変更箇所を特定する
  2. \n
  3. 差分結果 of DOM変更を実際のDOMに適用する
  4. \n
  5. 影響を受けるすべての要素に対してスタイルの再計算とレイアウトをトリガーする
  6. \n
  7. 更新されたフレームをペイントする
  8. \n
\n

Reactアプリケーションでは、仮想DOMの調停(reconciliation)プロセスは処理時間の一部ですが、結果として生じるDOM変更とそのレンダリングコストはプレゼンテーション遅延に含まれます。コンポーネントツリーによって生成されるDOMノードが多くなるほど、調停とそれに続くレンダリング処理の負荷が高くなります。

\n

ReactおよびNext.jsアプリケーションでこれを軽減するには:

\n
    \n
  • React.memo()を使用して、同じpropsを受け取る子コンポーネントの不要な再レンダリングを防ぎます。
  • \n
  • useDeferredValue()を負荷の高い再レンダリングをトリガーする値に使用し、Reactがより緊急性の高い更新を優先できるようにします。
  • \n
  • コンポーネントツリーを浅く保ちます。深くネストされたコンポーネント階層は深くネストされたDOMを生成し、調停とブラウザのレンダリングの両方のコストを増加させます。
  • \n
  • 次のような仮想化ライブラリ(react-window@tanstack/react-virtualなど)を長いリストに使用して、DOMに表示項目のみが含まれるようにします。
  • \n
\n\n

プレゼンテーション遅延の削減

\n\n

DOMサイズの最小化

\n

プレゼンテーション遅延の改善で最も効果的なのは、DOMを小さく保つことです。

\n
    \n
  • 未使用のHTML要素、特に深くネストされたラッパーdiv要素を削除します。
  • \n
  • 長いリストにはリスト仮想化を使用します(表示されている項目と少量のバッファのみをレンダリングします)。
  • \n
  • 可能な限り、深くネストされた構造をフラットにします。
  • \n
  • レイアウトにはネストされたdiv要素の代わりにCSS GridやFlexboxを使用します。
  • \n
\n \n
// DOMサイズを削減するために長いリストを仮想化する\n// 改善前:DOM内に10,000個の項目\n\n<ul>\n  {allItems.map(item => \n     <li key=\"{item.id}\">{item.name}</li>)\n   }\n</ul>\n\n// 改善後:DOM内には表示されている項目のみ(react-windowを使用)\nimport { FixedSizeList } from 'react-window';\n<fixedsizelist height=\"{600}\" \n               itemcount=\"{allItems.length}\" \n               itemsize=\"{50}\" width=\"100%\">  \n  {({ index, style }) => (\n    <div style=\"{style}\">{allItems[index].name}</div>\n  )}\n</fixedsizelist>\n
\n\n \n

content-visibilityを使用して画面外のコンテンツを遅延レンダリングする

\n

CSSのcontent-visibilityプロパティは、ユーザーがその近くにスクロールするまで画面外コンテンツのレンダリングをスキップするようブラウザに指示します。これにより、スタイルの再計算とレイアウトの範囲をページの表示部分のみに限定し、操作時のレンダリング処理の量を削減します。

\n
/* ファーストビュー以下のセクションにcontent-visibilityを適用 */\n.below-fold-section {\n  content-visibility: auto;\n  contain-intrinsic-size: auto 500px;\n}\n\n/* 長いリストの個々の項目に適用 */\n.list-item {\n  content-visibility: auto;\n  contain-intrinsic-size: auto 80px;\n}
\n

contain-intrinsic-sizeプロパティは推定の高さを提供し、ブラウザがコンテンツをレンダリングせずにスクロールバーのサイズを正しく計算できるようにします。これにより、ユーザーがスクロールしてコンテンツが表示される際のレイアウトシフトを防ぎます。

\n

レンダリングコストを削減するその他のCSS最適化戦略については、未使用のCSSの削除のガイドを参照してください。

\n\n

操作によってトリガーされるレイアウト処理を最小限に抑える

\n

操作を設計する際は、レイアウトをトリガーしないCSSプロパティを優先してください。例えば、transformopacityなどのプロパティは、レイアウトやペイントをトリガーせずにGPUコンポジターで処理できます。topleftwidth、またはheightをアニメーション化する代わりに、transform: translate()transform: scale()使用してください。レイアウトをトリガーするCSSプロパティの完全なリストについては、web.devのレンダリングパフォーマンスガイドを参照してください。

\n

CSSのwill-changeプロパティを使用して、要素がアニメーション化されることをブラウザにヒントとして伝えます。これにより、ブラウザは要素に対して個別のコンポジターレイヤーを作成し、そのレンダリングをページの他の部分から分離できます:

\n
/* 要素を独自のコンポジターレイヤーに昇格させる */\n.animated-element {\n  will-change: transform, opacity;\n}\n\n/* displayの代わりにopacityで可視性を切り替える */\n.modal {\n  opacity: 0;\n  pointer-events: none;\n  transform: translateY(10px);\n  transition: opacity 0.2s, transform 0.2s;\n}\n\n.modal.active {\n  opacity: 1;\n  pointer-events: auto;\n  transform: translateY(0);\n}
\n\n

長いプレゼンテーション遅延の特定

\n

長いプレゼンテーション遅延を特定するには、Chromeのパフォーマンスプロファイラーを使用できます。DevTools(Ctrl+Shift+I)を開き、Performanceタブに移動して記録を開始し、ページを操作します。

\n

その後、操作のタイムラインを分析して、プレゼンテーション遅延を含むさまざまなフェーズを可視化できます。イベントハンドラーの実行終了後に発生するレンダリング更新を調査することで、長いプレゼンテーション遅延の原因となっているボトルネックをピンポイントで特定できます。タイムライン上で「Recalculate Style(スタイルの再計算)」、「Layout(レイアウト)」、「Paint(ペイント)」の大きなエントリを探してください。これらは、プレゼンテーション遅延フェーズ中にブラウザが行う処理を表しています。

\n

inp presentation delay devtools

\n\n

RUMデータによるプレゼンテーション遅延の特定

\n
Real User Monitoring (RUM)は、Interaction to Next Paintや、プレゼンテーション遅延を含むそのサブパーツといった、重要なCore Web Vitals関連指標のリアルタイム更新を提供します。CoreDashなどのRUMツールは、各INP操作を3つのフェーズに分解するため、特定のページやユーザーセグメントにおいてプレゼンテーション遅延がボトルネックになっているかどうかを確認できます。
\n\n \n

Long Animation Frames (LoAF)によるプレゼンテーション遅延の測定

\n

Long Animation Frames (LoAF) APIは、ユーザー操作中のレンダリング遅延の原因を正確に示します。このAPIは、処理時間とプレゼンテーション遅延を分離するためのタイミングデータを提供し、どのスクリプトがレンダリングを遅らせているかを特定するのに役立ちます。

\n

プレゼンテーション遅延を理解するための重要なLoAFプロパティは以下の通りです:

\n
    \n
  • renderStart:ブラウザがレンダリングフェーズ(スタイルの再計算、レイアウト、ペイント)を開始した時間
  • \n
  • styleAndLayoutStart:スタイルとレイアウトの計算が開始された時間
  • \n
  • duration:ロングアニメーションフレームの総時間
  • \n
  • blockingDuration:スクリプトによってフレームがブロックされた時間
  • \n
\n

LoAFは現在Chromiumのみ(Chrome 123以降)でサポートされています。他のブラウザでは、Chrome DevToolsのPerformanceパネルのトレースを使用してレンダリング処理を分析してください。

\n

スクリプト実行の終了からフレームの終了までの差が、純粋なレンダリングコストであり、これがプレゼンテーション遅延に相当します。このデータを観察してログに記録する方法は以下の通りです:

\n
// LoAF APIを使用してプレゼンテーション遅延を測定する\nconst observer = new PerformanceObserver((list) => {\n  for (const entry of list.getEntries()) {\n    if (entry.duration > 50) {\n      const scriptEnd = Math.max(\n        ...entry.scripts.map(s => s.startTime + s.duration)\n      );\n      const presentationDelay = (\n        entry.startTime + entry.duration\n      ) - Math.max(scriptEnd, entry.renderStart);\n\n      console.log('Presentation delay breakdown:', {\n        totalDuration: entry.duration,\n        renderStart: entry.renderStart,\n        styleAndLayoutStart: entry.styleAndLayoutStart,\n        estimatedPresentationDelay: presentationDelay,\n        scriptCount: entry.scripts.length\n      });\n    }\n  }\n});\n\nobserver.observe({\n  type: 'long-animation-frame',\n  buffered: true\n});
\n

CoreDashなどのRUMツールはLoAFデータを統合し、どのスクリプトやDOM変更がレンダリング遅延の原因になっているかを、完全なスクリプトアトリビューションとともに表示します。

\n\n \n

他のINPフェーズの確認

\n

INPをコントロールするには、他の2つのフェーズにも対処する必要があります:

\n
    \n
  • Input Delay:イベントハンドラーが実行を開始するまでの待ち時間を最小限に抑えます。インプット遅延は通常、最も短いフェーズですが、メインスレッドがビジー状態になるページの起動時に急増します。
  • \n
  • Processing Time:操作中に実行されるイベントハンドラーコードを最適化します。ほとんどのページでは、ここに最適化作業の大部分の労力を費やすことで効果が得られます。
  • \n
\n

完全な診断ワークフローについては、INP問題の特定と修正のガイドを参照してください。追加のレンダリング最適化戦略については、過大なDOMサイズの修正未使用のCSSの削除のガイドを参照してください。全体の概要については、INPのハブページに戻ってください。

\n\n
\n
[include]sidebarcwv.html[/include]
\n
\n
\n [include]blogfooter.html[/include]" }" />

JavaScriptのスクロールライブラリを、1行のCSSに置き換えてください。scroll-behavior: smoothにより、パフォーマンスが向上し、Interaction to Next Paint (INP)が高速化します。

Create a beautiful smooth scrolling experience that does not affect the Core Web Vitals

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-02-28

Core Web Vitalsは、実際のユーザー体験を測定するGoogleの3つの指標です。Largest Contentful Paint (LCP)は読み込み速度(良好:2.5秒未満)、Interaction to Next Paint (INP)は応答性(良好:200ミリ秒未満)、Cumulative Layout Shift (CLS)は視覚的安定性(良好:0.1未満)を測定します。Googleは、実際の訪問者データの75パーセンタイルでこれらを評価します。

Core Web Vitalsの概要

Core Web Vitalsは、単なる任意の、あれば良いという指標ではありません。Googleがウェブサイトの読み込み、インタラクティブ性、視覚的安定性のパフォーマンスを評価するために使用する基準です。Core Web Vitalsを構成する3つの指標は、Largest Contentful Paint (LCP)、Interaction to Next Paint (INP)、Cumulative Layout Shift (CLS)です。Googleは、サイトのCore Web VitalsをGoodNeeds Improvement、またはPoorとして評価します。

これらに合格するかどうかは、成功と凡庸さの分かれ目になり得ます。これらを最適化しないことは、ユーザーのオンライン体験を軽視していることと同じです。

2025 Web Almanacによると、3つすべてのCore Web Vitalsに合格しているのは、わずかモバイルページの48%デスクトップページの56%のみです。これは、モバイルではウェブの半分以上が不合格であることを意味します。

core web vitals lcp inp cls

Core Web Vitalsとは?

GoogleのCore Web Vitalsは、ウェブサイトのユーザー体験を測定する3つの指標(Largest Contentful PaintInteraction to Next PaintCumulative Layout Shift)です。これらの指標は、世界中のChromeブラウザから収集された実際のユーザーデータに基づいており、ユーザー体験における3つのフィールドの側面に焦点を当てています。

  • Loading:ページコンテンツの読み込み速度
  • インタラクティブ性:ブラウザがユーザーの入力に応答する速さ
  • 視覚的安定性:ブラウザでの読み込み時におけるコンテンツの安定性

Core Web Vitalsは固定されたものではありません。Googleは継続的に指標を更新しています。直近では、2024年3月にInteraction to Next Paint (INP)が、応答性の指標としてFirst Input Delay (FID)に代わって導入されました。INPは最初の1回だけでなく、ページ上のすべてのインタラクションを測定するため、応答性のテストとしてはるかに厳しくなっています。

Core Web Vitalsの合格基準

Core Web Vitalsの各指標には、Googleが定めたしきい値に基づいて、Good、Needs Improvement、またはPoorの評価が割り当てられます。Core Web Vitalsに合格するには、Google CrUXデータセット of URLレベルにおいて、訪問者の少なくとも75%がLCP、INP、CLSで「good」スコアを獲得している必要があります。URLレベルのデータが利用できない場合、GoogleはURLグループやoriginレベルのデータにfallbackすることがあります。


良好 改善が必要 不良
Largest Contentful Paint 2.5秒未満 2.5秒 - 4.0秒 4.0秒超
Interaction to Next Paint 200ms未満 200ms - 500ms 500ms超
Cumulative Layout Shift 0.1未満 0.1 - 0.25 0.25超

なぜ75パーセンタイルなのか?

Googleは、ページがCore Web Vitalsに合格するかどうかを判定するために、実際のユーザーデータの75パーセンタイル (p75) を使用します。これは、合格するにはページアクセスの75%が「good」な体験である必要があるという意味です。75パーセンタイルが選ばれたのはバランスを考慮した結果です。中央値(遅い半数を無視する)とは異なり、大半のユーザーの体験を捉えつつ、低速なネットワークによる少数の例外的なアクセスによって不合格にならない程度の基準となっています。

実質的には、高速なデバイスや回線を使用しているユーザーだけでなく、大半の訪問者に対してサイトのパフォーマンスが優れている必要があるということです。


Core Web Vitalsの3つの指標

各指標が何を測定し、なぜ重要である観点は以下の通りです:

Largest Contentful Paint (LCP):読み込み

largest contentful paint

Largest Contentful Paint (LCP)は、サイトの読み込み速度を表す指標です。

LCP要素自体は、画面の表示領域内に描画された、最大の単一の「contentful」(コンテンツを伴う)要素です。contentfulとは、どのような要素でもLCP候補になれるわけではないことを意味します。要素には意味のあるコンテンツが必要です。その定義はかなり厳格であり、対象となる LCP候補は、ユーザーが最初にページにアクセスした時点を基準として、viewport内に表示されている画像テキストブロック、または動画です。

Largest Contentful Paint (LCP)の値は、ページのリクエストから、画面の表示領域(ファーストビュー)に最大のコンテンツ要素が表示されるまでのミリ秒単位の時間です。良好なLCPスコアは2.5秒未満です。2025 Web Almanacによると、良好なLCPを達成しているのはモバイルページのわずか62%であり、合格するのが最も難しいCore Web Vitalとなっています。

Largest Contentful Paint (LCP)が採用されているのは、訪問者のユーザー体験に焦点を当てているからです。LCPが発生すると、訪問者はページの読み込みが完了したと判断します(実際にはそうではない場合もあります)。LCPは、「ページのコンテンツはいつ表示されるのか?」という疑問に答えるために作成されました。

LCPを改善する最も効果的な方法には、LCP画像をプリロードしてfetchpriority="high"を指定することや、WebPやAVIFなどのモダンなフォーマットで画像ファイルサイズを最適化することが挙げられます。詳細については、Largest Contentful Paint最適化ガイドを参照してください。


Interaction to Next Paint (INP):応答性

interaction to next paint

Interaction to Next Paint (INP)は、サイトの応答性を表します。この指標は、ウェブページとのインタラクションが発生した後に、ブラウザがどれだけ迅速にレイアウトを更新できるかを測定します。

INPは、クリック、タップ、キー入力といった個別のユーザーインタラクションを追跡します。スクロールやホバーなどの連続的なインタラクションは、INPでは測定されません。対象となる各インタラクションは、入力の瞬間からJavaScriptの処理を経て、画面上の最終的な表示更新までの時間が計測されます。

Interaction to Next Paintの値は、各ユーザーインタラクションからページ上の最終的な表示変更までの時間差です。すべてのインタラクションの中で最も遅いもの(or インタラクション数が多いページでは98パーセンタイル)によって、最終的なInteraction to Next Paint (INP)指標が決定されます。

INPは純粋なfield指標であり、実際のユーザー入力が必要なため、Lighthouseなどのlabツールでは測定できません。Lighthouseにおいては、Total Blocking Time指標がInteraction to Next Paintと強く相関します。INPは通常、Total Blocking Timeよりも(はるかに)低くなりますが、TBTを改善することでINPも向上します。最も効果的な戦略の1つは、重要ではないJavaScriptを非同期化(defer)して、ユーザーインタラクション中にmain threadをブロックしないようにすることです。

世界全体で、2025 Web Almanacによるとモバイルページの77%が良好なINPスコア(200ms未満)を達成しています。INPは2024年3月にFirst Input Delay (FID)に代わってCore Web Vitalsの対象となり、大幅に厳しい指標であることが証明されました。詳細なガイドは、Interaction to Next Paint最適化ガイドを参照してください。

Cumulative Layout Shift (CLS):視覚的安定性

cumulative layout shift

Cumulative Layout Shift (CLS)は、Core Web Vitalsの視覚的な安定性を表す部分です。Cumulative Layout Shift (CLS)は、コンテンツの描画中や新しいコンテンツの表示時に発生する、ページ上での要素の予期しない位置ずれを測定します。

CLSの値は2つの割合に基づいています。インパクト割合と、ディスタンス 割合です。要素が視覚的に不安定な場合、そのサイズが変化し、他のコンテンツが押し下げられて位置がずれます。距離はviewportに対するピクセル比率です。影響は、影響を受けた要素のviewportに対する比率です。

CLSの主な原因には、明示的なwidth属性およびheight属性を持たない画像、広告やクッキーバナーのように動的に挿入されるコンテンツ、およびfallbackとは異なるサイズで置き換わるウェブフォントがあります。適切なfont-display設定でフォントをセルフホストすることにより、フォント起因 of CLSを低減できます。世界全体で、2025 Web Almanacによるとモバイルページの81%が良好なCLSスコアを達成しており、最も合格率の高いCore Web Vitalとなっています。詳細なガイドは、Cumulative Layout Shift最適化ガイドを参照してください。

なぜCore Web Vitalsが重要なのか?

では、なぜCore Web Vitalsを最適化すべきなのでしょうか。

  • ユーザー体験の向上。読み込みの高速化、迅速な応答、レイアウトのズレの低減。これらは訪問者が実際に実感できるものです。Core Web Vitalsに合格したサイトは、直帰率が低く、コンバージョン率が高くなります(ソース:Google)。
  • 検索エンジン最適化 (SEO)。GoogleはCore Web Vitalsをランキング要因に設定しました。合格しただけで平凡なページが1位になるわけではありませんが、2つのページが同じキーワードで競合する場合、より高速なページが優位に立ちます。
  • モバイルパフォーマンス。トラフィックの大部分はモバイル経由です。ユーザーの70%が購入前にスマートフォンで商品を調査し、62%はモバイルフレンドリーなサイトを提供する企業と取引する可能性が高くなります。
  • 競合に対する優位性。ほとんどの競合他社はCore Web Vitalsの最適化を行っていません。これはチャンスです。2つのサイトが同じキーワードで競合しており、自社サイトの読み込みと応答が速ければ、Googleが上位に評価する理由になります。
  • その他。上記のメリットに加えて、Core Web Vitalsは豊富にドキュメント化されています(これはGoogleの公表されているランキング要因としては極めて稀なことです)。Google広告を利用している場合、品質スコアが改善され、広告単価を抑えることができます。さらに、Core Web Vitalsの合格は、Googleのトップニュース枠に掲載されるための必須要件の1つです。

現実世界での影響:Vodafoneのケーススタディ

Core Web Vitalsのビジネスインパクトは机上の空論ではありません。Vodafone ItalyがLargest Contentful Paintを31%改善した際、売上高が8%増加、リード数が15%増加、カート遷移率が11%改善しました。表示が速いページは、売上を増やします(ソース:web.devケーススタディ)。

Field DataとLab Data

Field dataとlab dataは異なるものを測定します。これらを混同すると、誤った数値を最適化することになります。

Field data(Real User MonitoringまたはRUMデータとも呼ばれます)は、実際の環境でサイトを利用する訪問者から取得されます。これには、デバイスの性能、ネットワーク速度、位置情報、ブラウジング動作の違いが含まれます。GoogleのCrUXデータセットは、オプトインしたChromeユーザーからfield dataを収集しています。Core Web Vitalsは、field dataのみを使用して測定されます。

Lab dataは、固定された環境でシミュレートされたデバイスを用いて行われる、管理されたテストから得られます。LighthouseやWebPageTestなどのツールがlab dataを生成します。ラボテストは再現性があり、特定の課題を診断するのに適していますが、実際の多様なユーザー体験を反映することはできません。

なぜSEOにおいてField Dataが重要なのか?

Googleは検索順位の評価基準として、CrUXデータセットのfield dataを使用してCore Web Vitalsを測定します。Lighthouseで100点満点を獲得したからといって、Core Web Vitalsの合格が保証されるわけではありません。Lighthouseは単一のシミュレートされたアクセスしかテストしないからです。実際のユーザーは、より低速なデバイスや遠隔地のネットワークを利用していたり、Lighthouseでは再現できない方法でページを操作している可能性があります。

だからこそ、CoreDashのようなReal User Monitoringソリューションを用いてCore Web Vitalsを監視することが、サイトの実態を最も正確に把握する方法になります。RUMデータにより、デバイスタイプ、地域、ページテンプレート、さらには個別の要素ごとに課題を特定し、labツールでは得られない具体的なインサイトを導き出すことができます。

Core Web Vitalsを測定する

Core Web Vitalsはユーザー体験の3つのフィールド側面に焦点を当てているため、field dataでしか測定できません。Lighthouseのような合成テストやラボテストは、ページが遅い理由を分析する手がかりにはなりますが、Core Web Vitalsそのものを測定しているわけではありません。

測定ツールの比較

ツール データタイプ CWVを測定可能か? 主な用途
CrUX (Chrome User Experience Report) Field はい(公式) SEO評価、オリジン/URLレベルの傾向把握
PageSpeed Insights Field + Lab はい(CrUX経由) CrUXデータとLighthouse診断を組み合わせた簡易チェック
Lighthouse Lab only いいえ 特定のパフォーマンス問題 of 診断
Chrome DevTools Lab only いいえ 本番環境でのデバッグ、ネットワーク分析、パフォーマンスプロファイリング
CoreDash (RUM) Field はい リアルタイム監視、要因特定、デバイスおよびページレベルの分析
Google Search Console Field (CrUX) はい サイト全体のCWVステータスの監視

CrUXデータ

Core Web VitalsはGoogleによって測定され、CrUXデータセットに記録されます。CrUXはWeb Vitalsプログラムの公式データセットです。このデータセットにアクセスするには、いくつかの方法があります:

  1. CrUXダッシュボードは、CrUXデータをクエリして対話型のダッシュボードに描画し、PDFレポートのエクスポートを可能にするData Studioダッシュボードです。
  2. BigQuery上のCrUXは、CrUXが収集したすべてのオリジンレベルのデータを一般公開されたデータベースとして提供します。データが存在するすべてのオリジンの検索、CrUXの全指標の分析、利用可能なすべてのディメンションによる絞り込みが可能です。完全な指標のヒストグラムがBigQueryテーブルに保存されており、実験的指標を含むパフォーマンス分布を視覚化できます。
  3. CrUX APIは、ページやオリジンごとのCrUXデータにプログラムからアクセスできるようにします。デバイスタイプ、通信接続タイプ、および指標による絞り込みも可能です。
  4. PageSpeed Insightsは、CrUXデータを用いて実際のユーザーパフォーマンスを提示し、Lighthouseによる改善案を併せて表示します。

CoreDash RUM data

RUMデータ

RUMデータは、Real User Monitoringによって収集されます。RUMデータは、CrUXデータセットを補完する最高の手段です。CrUXデータセットは完全に匿名化されているため、詳細な要因分析には適していません。また、CrUXデータは28日間のローリング集計期間を持っています。そのため、多くのCore Web Vitalsの専門家はリアルユーザー指標に依存しています。CrUXデータと同様に、実際のユーザーデータがCore Web Vitalsの測定に使用されます。

CoreDashのようなRUMソリューションは、CrUXデータ単体に対して多くのメリットを提供します。これには、リアルタイムのレポート(28日間の集計遅延なし)、個々のページ、デバイスタイプ、国、ブラウザごとのフィルタリング機能、および問題の原因となっている具体的な要素を特定する詳細なアトリビューションデータが含まれます。これにより、RUMデータはCore Web Vitalsの課題を効率的に診断して修正するために不可欠な存在となっています。

CoreDash RUM data

Lighthouse

Lighthouseは強力なツールです。しかし、これだけは理解しておいてください。LighthouseはCore Web Vitalsを測定していません!Lighthouseはいわゆるlabツールです。Lighthouseは特定の固定された条件下で分析を実行します。ページ間を移動せず、リソースをキャッシュせず、ウェブサイトとインタラクションを行わず、実際のユーザー環境を再現することもしません。

それでも、Lighthouseは優れたツールです。正しく使用すれば、ページにおけるCore Web Vitalsの課題を数多く特定できます。

Lighthouse分析を行う最適な方法は、ブラウザからPageSpeed Insightsを使用するか、Lighthouseコマンドラインツールを利用することです。

lighthouse audit

実際のユーザーデータが示す事実

2025 Web Almanacは、ウェブ全体におけるCore Web Vitalsのパフォーマンスを幅広く調査しています。モバイルにおける各指標の世界的なパフォーマンスは以下の通りです。

指標 モバイルGood率 推移(2024年〜2025年) 主なインサイト
LCP 62% +3パーセントポイント 依然として最も合格が困難な指標。CWV全体のボトルネックとなっています。
INP 77% +3パーセントポイント 2024年3月のFIDからの移行後、順調に改善しています。
CLS 81% +9パーセントポイント すべての指標の中で最大の改善。モバイルで最高のスコアです。
TTFB (diagnostic) 44% +2パーセントポイント 依然として数値がほとんど改善しておらず、ウェブにおける最大の構造的課題です。
FCP (diagnostic) 55% +4パーセントポイント TTFBのパフォーマンスに比例して推移します。

注:TTFBとFCPは診断指標であり、Core Web Vitalsではありません。これらはLCPおよび読み込みパフォーマンス全体に大きな影響を与えるため、ここに掲載しています。詳細は、Time to First ByteガイドおよびFirst Contentful Paintガイドを参照してください。

Core Web Vitalsの改善方法

Core Web Vitalsは常に進化する指標であり、改善は一度限りの作業ではありません。優位性を保つには、開発プロセス自体にパフォーマンス改善を組み込む必要があります。具体的には、field指標を追跡し、デグレーションを迅速に修正し、毎回のリリースで小さな改善を重ねることです。

3つのCore Web Vitalsは互いに影響し合っており、1つの指標を改善することが、他の指標に対してプラスまたはマイナスの副作用をもたらすことがあります。以下のガイドラインは、それぞれのCore Web Vitalsを理解して改善を始めるための最適なスタート地点です:

3つのCore Web Vitalsそのものに加えて、全体的なパフォーマンスにおいて2つの診断用指標が極めて重要な役割を果たします:

  • Time to First Byte (TTFB)の最適化:TTFBは読み込みパフォーマンスの基盤です。TTFBが遅いと、良好なLCPスコアを達成することはほぼ不可能になります。まずはCDNを適切に設定することから始めてください。
  • First Contentful Paint (FCP)の最適化:FCPは、最初のコンテンツが画面に表示されるまでの時間を測定します。これは体感の読み込み速度を示す初期のシグナルになります。

すべての最適化領域を網羅したステップバイステップのガイドは、当社のCore Web Vitalsチェックリストを使用してください。

GoogleのページエクスペリエンスとCore Web Vitals

Core Web Vitalsは、Googleのページエクスペリエンススコアの一部です。ページエクスペリエンスとは、モバイルおよびデスクトップデバイスにおいて、単なる情報としての価値を超え、ユーザーがウェブページを操作した際の体験をどのように感じたかを測定するシグナルの集まりです。

google page experience core web vitals

サイトのページエクスペリエンスデータおよびCore Web Vitalsデータは、Google Search Consoleアカウントの「体験」セクションで確認できます。

ページエクスペリエンスレポート search console page experience
Core Web Vitals search console page experience cwv

CoreDashはMCPを標準搭載。

ClaudeでもどのAI agentでも繋がります。「先週火曜のINPスパイクはなぜ?」と聞けます。

仕組みを見る

Core Web Vitalsに関するよくある質問

Core Web Vitalsについて学ぶ

Core Web Vitalsの専門家になるためには、何を学ぶべきですか?

専門家を目指すのですね。素晴らしいことです。しかし、この先は険しい道のりになります!Core Web Vitalsのいくつかの部分は簡単に修正できますが、他の部分は非常に難しく、長年の経験が必要です。専門家になるには、基本的に4つの能力を習得する必要があります。

第1に、ブラウザの動作を完全に理解すること。レンダリングプロセスがどのように進み、リソースがどのようにスケジュールされ、JavaScriptがいつ実行され、描画(paint)プロセスで何が起こるかです。

第2に、JavaScriptを習得すること。私は開発者にコードが遅い理由を説明するのに多くの時間を割いています。遅いコードはInteraction to Next Paintに悪影響を与えます。ほとんどの場合、JavaScriptコードはLargest Contentful PaintやFirst Contentful Paintにも影響します。

第3に、HTMLとCSSの専門家であること。アプリケーションの構築方法は重要です。処理には常に高速な方法と遅い方法が存在します。

第4に、ネットワークとウェブサーバーの仕組みを理解すること。高速なネットワーク、適切なHTTPヘッダー、そして状況に応じた正しいプロトコルは、Core Web Vitalsに大きな違いをもたらします。大企業向けにアドバイスをするのであれば、十分に準備をして臨む必要があります。

Core Web Vitalsを改善する

Core Web Vitals改善用のプラグインは機能しますか?

WP Rocketなど、Core Web Vitalsの改善を謳うプラグインやツールは数多く存在します。これらのツールについて思うところは山ほどありますが、ここでは詳細を割愛します。実際のところ、Core Web Vitalsが改善することもありますが、ほとんど効果がないこともあります。

すべては、修正しようとしている「Core Web Vitalsの課題」の性質によります。画像のlazy loadingの設定漏れや、スクリプトのdefer指定の忘れが原因でしょうか?そうであれば、これらのツールでCore Web Vitalsが劇的に改善する可能性があります。一方で、表示遅延の原因が「ページのレイアウトを変更する重要なスクリプト」(スライダープラグインなど)や「過剰なDOMサイズ」である場合、これらのプラグインはメリットよりも害をもたらすことが多いです。

基本的に、プラグインは優秀なプログラマーなら数時間で解決できるような簡易的な問題しか修正できません。より複雑な問題は修正できず、かえって悪化させる可能性さえあります。

モバイルとデスクトップのどちらを優先すべきですか?

素晴らしい質問です。基本的にはモバイルを優先してください。

モバイルのCore Web Vitalsに合格できれば、デスクトップのCore Web Vitalsに合格するのもずっと容易になります(すでに合格していない場合)。一般的なモバイルデバイスは、デスクトップと比較して帯域幅が狭く、メモリやCPUパワーも劣るため、処理速度が遅いからです。

ただし、いくつかの例外はあります。デスクトップは表示されるviewportが大きいため、モバイルのLCP要素がテキストであっても、デスクトップではページ下部の画像がLargest Contentful Paint要素になることがあります。また、デスクトップは画面が大きく表示要素も多いため、小さなレイアウトシフトが発生する確率も高くなります。

測定:CrUX、RUM、および合成データ

URLレベルのデータが利用できない場合、GoogleはどのようにCore Web Vitalsを評価しますか?

Googleは主に、検索順位の評価基準としてChrome User Experience Report (CrUX)のURLレベルのデータを使用します。特定のURLのデータがない場合、Google Search Consoleで識別される「類似したURLグループ」のデータが参照されることがあります。URLレベルとグループレベルのデータの双方が不足している場合、Googleは順位評価の対象として、originレベルのCore Web Vitalsデータを参照することがあります。

Core Web Vitalsのデータはリアルタイムですか?

いいえ、Core Web Vitalsのデータはリアルタイムではありません。実際のユーザーの挙動を収集するChrome User Experience (CrUX) Reportに基づいており、通常1日から2日程度の遅延があります。
データ自体のタイムラグはわずか(1〜2日)ですが、集計がローリング方式(28日間の移動平均)で行われるため、サイトの改善が最終的なスコアに影響するまでにはタイムラグがあります。そのため、改善を加えた直後にCore Web Vitalsの数値がすぐに好転することはありません。施した施策がスコアの数値を押し上げるまでには、通常数週間かかります。

なぜSearch Consoleや他のCrUXツールにデータが表示されないのですか?

多くの場合、対象サイトのfield dataが十分に蓄積されていないことが原因です。Googleが有意なパフォーマンス指標を生成するためには、一定以上のアクセス数とユーザーデータが必要になります。これは、新規サイト、Search Consoleに登録した直後のサイト、トラフィックが非常に少ないサイト、あるいはログインが必要なサイト(クローラーが巡回できずインデックス登録されていない可能性が高いページ)でよく発生します。

LighthouseのスコアはCore Web Vitalsに影響を与えますか?

いいえ、LighthouseのスコアはCore Web Vitalsに直接影響しません。GoogleはCrUXの実際のユーザーデータを利用してCore Web Vitalsを評価します。CrUXデータセットは、ユーザーがサイト上で体験した実際の数値を表すものです。
Lighthouseは、Core Web Vitalsに悪影響を及ぼす可能性のある潜在的課題を発見するために役立つツールです。最も重要なことは、実際のユーザーデータに基づいて、指標の数値を直接改善することに注力することです。

Core Web Vitalsに関する一般的な質問

3つのCore Web Vitalsとは何ですか?

3つのCore Web Vitalsは、読み込み速度を測定しGood基準が2.5秒未満であるLargest Contentful Paint (LCP)、応答性を測定しGood基準が200ms未満であるInteraction to Next Paint (INP)、および視覚的安定性を測定しGood基準が0.1未満であるCumulative Layout Shift (CLS)です。ページ全体としてGood評価を得るためには、3つの指標すべてで75パーセンタイルの数値をクリアする必要があります。

Core Web Vitalsは検索順位 of 評価要因(ランキングシグナル)ですか?

はい、Core Web Vitalsは公式にランキング要因として採用されています。Googleは2021年6月にこれらをページエクスペリエンスシグナルの一部に組み込みました。コンテンツの関連性が最重要の評価要因であることに変わりはありませんが、2つのページのコンテンツ品質が同等である場合、Core Web Vitalsがタイブレーカー(決定打)として機能します。競合の多い検索領域においては、Core Web Vitalsをクリアすることが明確な優位性につながります。Googleはページエクスペリエンスは数ある要因の1つに過ぎず、優れたコンテンツの価値を上回ることはないと明言していますが、合格していない場合は合格している競合他社に対して明確に不利になります。

Field dataとlab dataの違いは何ですか?

Field dataは、実際の利用環境でサイトにアクセスしたユーザーの挙動を、ブラウザ(主にChrome)を通じて収集したものです。デバイスの性能、回線環境、ユーザーの操作方法などの実態がすべて反映されます。Lab dataは、LighthouseやWebPageTestなどのシミュレートされた制御環境で実施されるテストの結果です。開発時における再現テストやデバッグに極めて有効ですが、実際のユーザー体験そのものを表してはいません。Googleは順位評価の基準として、field dataのみを使用します。そのため、Lighthouseで満点を取ってもCore Web Vitalsに合格できるとは限らず、逆にLighthouseのスコアが低くてもCore Web Vitalsをクリアできているケースもあります。

JavaScriptのスクロールライブラリを、1行のCSSに置き換えてください。scroll-behavior: smoothにより、パフォーマンスが向上し、Interaction to Next Paint (INP)が高速化します。 Core Web Vitals JavaScriptのスクロールライブラリを、1行のCSSに置き換えてください。scroll-behavior: smoothにより、パフォーマンスが向上し、Interaction to Next Paint (INP)が高速化します。