問題のステートメントと適用可能なコンテキスト
あるEコマースの商品ページにおいて、直近28日間のモバイルフィールドデータでp75 LCPが4.1秒、INPが320ミリ秒、CLSが0.06でした。デスクトップでは3つの指標すべてに合格しています。開発者のローカルLighthouse実行では、LCP 1.8秒、TBT 80ミリ秒、CLS 0.01と報告されています。この乖離をどのように整合させ、LCPとINPの根本原因を特定し、修正の順序を決定し、デプロイされた変更が実際のユーザー体験を向上させたことを証明するかを説明してください。
現在のCore Web Vitalsの「良好（Good）」しきい値を使用します。モバイルとデスクトップで個別に75パーセンタイルを計算し、LCPは2.5秒以下、INPは200ミリ秒以下、CLSは0.1以下とします。これらの数値は面接用の前提条件であり、実在する企業の測定値ではありません。目的は最適化チェックリストを暗唱することではありません。ユーザー分布、指標の構成要素、ブラウザの処理、および検証を、反証可能な診断チェーンへと結びつけることです。
この質問は、シニアフロントエンド、Webパフォーマンス、およびフルスタックの面接に適しています。候補者は、ネットワークウォーターフォール、メインスレッド、レイアウトを理解していると同時に、1回のLighthouse実行が実ユーザーデータを覆すことはできず、TBTはINPではないことを認識している必要があります。
面接官が評価しているポイント
第1に、候補者は行動を起こす前に証拠を正規化できるか？優れた回答は、フィールドデータが単一のURL、URLグループ、またはオリジン全体を表しているかを確認し、モバイルとデスクトップ、ルートテンプレート、デバイス層、ネットワーク、地域、およびリリースごとにセグメント化します。不十分な回答は、ローカルのLighthouseスコアが良好（グリーン）であることを理由に問題が存在しないと断定します。
第2に、候補者は各指標を個別のボトルネックにマッピングできるか？LCPはメインコンテンツがいつ表示されるかに関係します。INPはインタラクションから次のレンダリングフレームまでの遅延全体をカバーします。CLSは予期しない視覚的移動を対象とします。これらはメインスレッドとレンダリングのコストを一部共有していますが、「バンドルサイズを削減する」だけではすべての不合格を説明できません。
第3に、候補者はレイテンシの要因を特定（帰属）できるか？LCPは、TTFB、リソース読み込み遅延（resource load delay）、リソース読み込み時間（resource load duration）、および要素レンダリング遅延（element render delay）に分解できます。1回のインタラクションのレイテンシは、入力遅延（input delay）、処理時間（processing duration）、および表示遅延（presentation delay）に分解できます。修正は、パフォーマンスチェックリストから無作為に選ぶのではなく、異常な構成要素を対象にする必要があります。
第4に、候補者はフィールドツールとラボツールを正しく使用できるか？RUMとCrUXは実際のユーザーが体験していることを特定します。DevTools、Lighthouse、および再現可能な制約付きデバイスシナリオは、その理由を説明するのに役立ちます。実際のユーザー入力がなければ、LighthouseはINPを測定できません。TBTなどのラボシグナルは診断の補助となります。
第5に、候補者は単にデプロイを示すだけでなく、改善を証明できるか？リリース後、バージョンまたはロールアウトコホートごとに同条件（like-for-like）のRUM分布を比較し、エラーとビジネスのガードレールを確認し、28日間のローリングフィールドデータで変更を確認します。単一のスナップショット、平均値の低下、または1台の高速なスマートフォンは、p75が合格したことを証明するものではありません。
回答前に確認すべき質問
- フィールドデータのスコープは何か？ URL、URLグループ、オリジンの結果は異なる場合があります。4.1秒がオリジン全体のものである場合、商品ページが原因であるとまだ証明されていません。商品テンプレートのものである場合は、そのテンプレートのトラフィックをさらにセグメント化します。
- どのデバイス、ネットワーク、地域がモバイルサンプルを構成しているか？ ローエンドデバイスや特定の地域に限定された不合格には、異なる再現環境と優先順位が必要です。モバイルとデスクトップを合算すると問題が隠れてしまいます。
- 指標はいつ悪化したか？ リリース、サードパーティスクリプト、画像パイプライン、またはトラフィック構成の変化と一致させることで、仮説を絞り込めます。28日間のローリング値では、単一リリースの直接的な影響を正確に把握できません。
- 実際のLCP要素と遅いINPインタラクションは何か？ ヒーロー画像、見出しテキスト、クライアントレンダリングされたコンテナでは、それぞれ異なる修正が必要です。「カートに追加」、バリエーション選択、検索入力も、異なるメインスレッドパスを実行します。
- Lighthouseはどのように実行されたか？ デバイスとネットワークのスロットリング、キャッシュ、認証、ページデータ、およびテストされたユーザージャーニーは、低速なユーザー層を反映している必要があります。高速なノートPCでの1回のコールドロードは、モバイルの分布を表していません。
- チームはどのレイヤーを変更できるか？ フロントエンド専任チームであってもTTFBを定量化すべきですが、オリジンを直接修正できると思い込んではいけません。CDN、サーバーレンダリング、画像サービスがスコープ内にある場合、計画はクリティカルパス全体をカバーできます。
- リリースの成功は何によって定義されるか？ ここでは、エラー率、コンバージョン、アクセシビリティを安全に維持しながら、モバイルのp75指標3つすべてが良好である必要があります。間違ったヒーロー画像を早期に描画したり、重要なインタラクションをブロックしたりすることは成功ではありません。
30秒で答える要約
「まず、4.1秒と320ミリ秒がモバイルのURLレベルかオリジンレベルのフィールドデータかを確認し、ルートテンプレート、デバイス、ネットワーク、リリースごとにセグメント化します。LighthouseのTBTはINPではないため、ローカルの結果で実ユーザーの問題を否定することはできません。RUMを使用して実際のLCP要素と最も遅いインタラクションを特定し、同等のデバイスでネットワークとPerformanceトレースを取得します。LCPをTTFB、検出、ダウンロード、レンダリングに分解し、INPを入力、イベント処理、次フレーム表示に分解します。CLSは0.06ですでに合格しているため、初期投資ではなくリグレッションのガードレールとします。最後に段階的にロールアウトし、同条件のRUM p75とガードレールを比較し、28日間のCrUXウィンドウで確認します。」
ステップごとの詳細解説
ステップ1: フィールド結果とラボ結果がどちらも正しい理由を説明する
28日間のフィールドデータは、実際のユーザーのデバイス、ネットワーク、キャッシュ状態、ページライフサイクル、インタラクションを統合したものです。モバイルのp75 LCP 4.1秒は、該当するアクセスの最も遅い約4分の1が4.1秒以上であることを示します。これは「典型的なスマートフォン」が正確に4.1秒かかるという意味ではありません。デスクトップデータが合格していることは、CPUの制約、モバイルネットワーク、モバイルテンプレート、またはモバイルユーザージャーニーに問題が集中している可能性を示唆しています。
ローカルのLighthouseは制御された実験です。再現性があり、ウォーターフォールやリグレッションの検出に有用ですが、単一のデバイスおよびネットワーク構成を表しています。ユーザー入力がないため、Lighthouseは直接INPを生成できません。80ミリ秒のTBTは、メインスレッドのブロッキングに関するラボシグナルです。ページ起動時のTBTが低くても、ユーザーがバリエーションピッカーを開いたときに300ミリ秒のタスクが実行されることがあります。その逆も可能であり、ラボのTBTが高くても、実際のユーザーがほとんどインタラクションしないタイミングで発生している場合もあります。
まず、PageSpeed Insightsまたはデータプラットフォームで、結果がURL、オリジン、またはURLグループのデータであるかを確認し、モバイルとデスクトップを個別に調査します。次に、ファーストパーティRUMを使用して、ページテンプレート、デバイス層、実効接続タイプ（ECT）、地域、ナビゲーションタイプ、アプリケーションリリースごとにセグメント化します。各ディメンションには十分なサンプル数と防御可能なプライバシー境界が必要です。パフォーマンス診断を理由に、完全なクエリ文字列、入力されたテキスト、またはユーザー識別情報を収集することは正当化されません。
ステップ2: スコアを報告するだけでなく問題を帰属させるRUMを構築する
最小限の実装では、web-vitalsを通じて3つの指標すべてを報告できます。次のコードは8つの言語バージョンすべてで同一です。
import { onCLS, onINP, onLCP } from 'web-vitals';
function sendToAnalytics(metric) {
const body = JSON.stringify({
name: metric.name,
value: metric.value,
id: metric.id,
rating: metric.rating,
route: location.pathname,
});
(navigator.sendBeacon && navigator.sendBeacon('/rum', body)) ||
fetch('/rum', { body, method: 'POST', keepalive: true });
}
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);この例では可読性のためにlocation.pathnameを使用しています。本番コードでは、/products/:idなどの低カーディナリティのルートテンプレートにマッピングし、リリース、デバイス層、および必要な帰属（attribution）フィールドを添付する必要があります。クエリパラメータ、DOMテキスト、またはユーザー識別情報を送信しないでください。metric.idはページ訪問の指標イベントを区別するのに役立ちますが、受信サービスには依然として明示的なサンプリングと重複レポートの処理ルールが必要です。
nameとvalueのみを保存するだけでは、リグレッションを修正するのに不十分です。LCPには要素と4つのタイミング構成要素が必要です。INPにはインタラクション対象と3つのタイミング構成要素が必要です。CLSにはシフトした要素とライフサイクルフェーズが必要です。帰属ビルドまたは既存のRUM製品を使用して、それらのフィールドを追加します。集計時には、各ナビゲーションの最終指標からパーセンタイルを計算します。各コンポーネントのp75を個別に計算して加算してはなりません。それらのパーセンタイル観測値は異なるアクセスから取得された可能性があるためです。
ステップ3: 4つのタイミング構成要素でLCPを診断する
代表的な低速モバイルナビゲーションの1つでは、TTFB 0.6秒、リソース読み込み遅延（load delay）1.5秒、リソース読み込み時間（load duration）0.9秒、要素レンダリング遅延（render delay）1.3秒となり、合計LCPは4.3秒になります。これらの構成要素は同一のナビゲーションに属しているため、合算できます。これらは4つの独立したp75値ではありません。
最も疑わしい2つの大きな構成要素は、読み込み遅延とレンダリング遅延です。ヒーロー画像がクライアントJavaScriptの実行後にのみ挿入されているか、誤って遅延読み込み（lazy load）されていないかを確認します。画像の場合は、初期HTMLに<img>とそのsrcまたはsrcsetを配置し、正しいsizesを提供し、ファーストビュー（above-the-fold）のLCP画像を遅延読み込みせず、真にクリティカルなリソースにのみ高いfetchpriorityを使用します。CSSが唯一の検出パスである場合は、正確なプリロードを検討します。すべての大きな画像をプリロードすると、クリティカルなリソースが帯域幅を奪い合うことになります。
リソースのダウンロード完了後にもさらに1.3秒が経過しているため、画像をさらに圧縮してもレンダリング遅延に時間がシフトするだけになる可能性があります。同期JavaScript、クライアントレンダリングの阻害要因、ブロッキングスタイル、フォント、およびヒーローを非表示にする状態を確認します。表示されるヒーローコンテンツのサーバーレンダリング、クリティカルCSSの削減、非クリティカルなハイドレーションの遅延が役立ちますが、新しいトレースで対象コンポーネントが実際に減少したことを示す必要があります。0.6秒のTTFBも引き続き監視する価値があります。このサンプルでは測定された1.5秒および1.3秒の遅延よりも優先順位は低くなりますが、恒久的に最適化から除外されるわけではありません。
ステップ4: 3つのタイミング構成要素でINPを診断する
代表的な低速な「バリエーション選択」インタラクションの1つには350ミリ秒かかります。内訳は入力遅延140ミリ秒、イベント処理120ミリ秒、表示遅延90ミリ秒です。3つの構成要素は1回のインタラクションから得られているため、その合計には意味があります。フィールドのp75 INP 320ミリ秒は別個の集計値であり、このトレースで置き換えることはできません。
入力遅延は、ユーザーが操作したときにメインスレッドが他の処理ですでに占有されていたことを意味します。インタラクションの前から開始するPerformanceトレースを記録し、スクリプトの評価、サードパーティタグ、タイマー、またはハイドレーションのロングタスクを探します。中断可能な処理を小さなタスクに分割し、重要でない処理を遅延させ、起動時に集中させないようにします。現在のクリックハンドラーのみを短縮しても、そのハンドラーが開始されるまでに待機した140ミリ秒を取り除くことはできません。
処理時間はイベントコールバックに属します。在庫分析、レコメンデーションの更新、ロギングを行う前に、選択状態または読み込みフィードバックを次のフレームに反映させます。重複計算を排除し、状態更新の範囲を狭めます。表示遅延については、大規模なDOM更新、強制同期レイアウト（forced synchronous layout）、およびレイアウトスラッシング（layout thrashing）を調査します。DOMの読み取りと書き込みをグループ化し、このインタラクションのためにレイアウトおよび描画する必要がある領域を削減します。測定されたボトルネックを一度に1つずつ変更し、同じジャーニーを繰り返して3つのコンポーネントすべてを比較します。
ステップ5: すでに良好なCLSをリグレッションガードレールにする
0.06のCLSは0.1を下回っているため、不合格となっているLCPやINPよりも優先すべきではありません。ただし、ヒーローの早期読み込み、代替画像コンポーネント、または新しいインタラクションフィードバックがレイアウトシフトを引き起こす可能性があるため、保護が必要です。画像や動画にwidth、height、または安定したaspect-ratioを指定し、広告、レコメンデーション、非同期コンテンツ用のスペースを確保し、Webフォントとフォールバックフォントのサイズ差を制御します。
ラボのCLS 0.01とフィールドのCLS 0.06のギャップは有用な証拠です。デフォルトのLighthouse実行は主に読み込み時を対象としますが、実際のユーザーはスクロール中、コンポーネントを開くとき、または長いページをアクティブに保っているときに読み込み後のシフトを経験することがあります。RUM帰属とDevToolsのLayout Shiftsトラックを使用して、それらのジャーニーを再現します。クロスオリジンiframe内のレイアウトシフトはCrUXに表示される場合がありますが、トップページのWeb APIからは完全に帰属させることができないため、その乖離が見られる場合は埋め込みコンテンツを調査します。
ステップ6: 証拠に基づいて変更を順序付け、段階的にリリースする
「画像」と「JavaScript」のプロジェクトを別々に立ち上げて、すべてを並行して変更してはいけません。現在のトレースは、クライアント側でのヒーロー検出の遅れと起動時のロングタスクが、LCPの読み込み／レンダリング遅延とINPの入力遅延の両方を増加させている可能性を示唆しています。最初のバッチでは、1つの共通の仮説をテストできます。初期HTMLでヒーローを検出可能にし、ファーストスクリーンで不要なJavaScriptを遅延させます。変更を小さく保つことで因果関係の主張が検証可能なままとなり、両方の不合格指標が改善する可能性があります。
各変更に対して期待されるシグナルを記述します。ヒーローの検出可能性により、リソース読み込み遅延が削減されるはずです。起動時のロングタスクを減らすことで、LCPレンダリング遅延、INP入力遅延、およびラボTBTが低下するはずです。対応する構成要素が変化しない場合、偶然のスコア変化をその修正の成果として帰属させてはなりません。画像品質、エラー率、ページが使用可能になるまでの時間、コンバージョン、アクセシビリティはガードレールであり、パフォーマンスの数値が製品の品質低下を覆い隠さないようにします。
同等の古いバージョンまたは並行するベースラインを維持しながら、トラフィックコホートに対してリリースします。トラフィック構成が大幅に変化していないことを確認しながら、同じルート、モバイル母集団、リリースを比較します。デプロイがトラフィックの変化と重複する場合、前後比較のタイムラインは相関関係を示すだけであり、自動的な因果関係を示すものではありません。
ステップ7: 3層の証拠で課題をクローズする
第1層はマージ前のラボガードレールです。制約のあるモバイルプロファイル、キャッシュ状態、クリティカルなインタラクションを固定し、LCP、TBT、CLS、ネットワークウォーターフォール、Performanceトレースを記録します。これにより明白なリグレッションを捕捉できますが、実際のINPを代替することはできません。
第2層はリリース後のRUMです。サンプルサイズ、安定したサンプリング、指標イベントの重複排除を確認し、モバイル商品テンプレートのp75 LCP、INP、CLSを、それらの構成要素および製品ガードレールとともに比較します。短期的なRUMは方向性を素早く明らかにできます。サンプルが不十分な場合は、すべてのユーザーが合格していると主張するのではなく、信頼性が不十分であると報告します。
第3層はCrUXまたはSearch Consoleでの28日間のローリング確認です。過去のアクセスは徐々にウィンドウから外れるため、指標はデプロイ当日に新しい定常状態にジャンプすることはありません。合格とは、モバイルとデスクトップで個別に3つのp75目標（LCP ≤ 2.5秒、INP ≤ 200ミリ秒、CLS ≤ 0.1）をすべて達成することを意味します。LCPの修正によってCLSが0.06からしきい値を超えて悪化してはなりません。全体としての合格がローエンドデバイスの問題を隠さないように、ロールバック基準と残存する低速セグメントを記録します。
高品質な模範解答
「ローカルのLighthouseがグリーンだからといって、モバイルのフィールドデータを無視することはありません。まず、4.1秒が商品詳細URL、URLグループ、オリジンのいずれに属するかを特定し、デバイス、ネットワーク、地域、リリースごとにモバイルをセグメント化します。28日間のp75は単一のデバイスではなく分布であり、LighthouseのTBTはINPではありません。
RUM帰属を追加して実際のLCP要素と最も遅いインタラクションを特定し、同等のデバイスでトレースを取得します。ある低速なナビゲーションのLCP構成要素が0.6秒、1.5秒、0.9秒、1.3秒であったとします。私は1.5秒の検出遅延と1.3秒のレンダリング遅延に最初に取り組みます。ヒーロー画像を初期HTMLに配置し、ファーストビューの遅延読み込みを削除し、描画をブロックするクライアント側の処理を削減します。すでにダウンロードされている画像を圧縮することは最初の手段ではありません。
INPについては、低速なインタラクションを入力遅延、処理、表示に分割します。それらが140ミリ秒、120ミリ秒、90ミリ秒である場合、まずインタラクション前にメインスレッドを占有している起動処理を特定し、次にコールバックを短縮し、更新に伴うレイアウトと描画を削減します。CLSはすでに0.06で合格しているため、画像サイズと非同期コンテンツのプレースホルダーはリグレッションガードとして維持します。
小規模なコホートにリリースし、すべての変更に対して予測されたタイミング構成要素の変動を要求し、同条件のRUMと製品ガードレールでバージョンを比較します。ラボのパフォーマンスバジェットでマージ前のリグレッションを防ぎ、RUMで迅速な実ユーザーシグナルを取得し、28日間のCrUXウィンドウで最終確認を行います。エラー率、コンバージョン、アクセシビリティを低下させることなく、モバイルのp75 LCP、INP、CLSがすべて2.5秒、200ミリ秒、0.1に達した時点で初めて課題をクローズします。」
よくある間違い
- ローカルのLighthouseが合格しているためフィールドデータを無視する → 2つのデータセットは異なるユーザー、時間枠、インタラクションを対象としている → まずURL、デバイス、ネットワーク、リリース、指標のスコープを正規化する。
- 80ミリ秒のTBTを80ミリ秒のINPとして読み取る → Lighthouseは実際のインタラクションなしにINPを測定できない → 影響度の把握にはフィールドINPを使用し、診断にはTBTとインタラクショントレースを使用する。
- サイト全体の平均値のみを見る → 平均値はモバイルのロングテールや不合格のテンプレートを覆い隠す → モバイルとデスクトップで個別にp75を計算し、十分なサンプルがあるグループをセグメント化する。
- LCPが遅いとすぐに画像を圧縮する → 検出遅延やレンダリング遅延が支配的である可能性がある → LCPを4つの構成要素に分解し、異常な要素を変更する。
- ファーストビューのすべてのリソースをプリロードする → クリティカルとされるリソース同士が競合する → 確認されたLCPリソースのみ優先順位を上げ、ウォーターフォールを再確認する。
- クリックコールバックのみを最適化する → コールバック前のロングタスクやその後のレイアウトも影響する → 入力、処理、表示を個別に検査する。
- CLSを0.06から0.02に下げることを優先する → LCPとINPが依然として不合格であるにもかかわらず、合格している指標に工数を費やすことになる → CLSガードレールを維持し、しきい値を超えている指標を優先する。
- 4つの構成要素のp75値を合算する → 各パーセンタイルは異なるアクセスから来ている可能性がある → 単一のナビゲーション内でのみコンポーネントを合算し、集計時に最終的な指標のパーセンタイルを計算する。
- デプロイ当日にRUMが低下したことで成功を宣言する → サンプルサイズ、トラフィック構成、28日間のウィンドウが安定していない → ロールアウトコホートを比較し、ガードレールを検査し、ローリングフィールドデータの確認を待つ。
フォローアップの質問と回答
フォローアップ1: 複数のテスト用スマートフォンで再現できないのに、なぜフィールドLCPが悪いのですか？
フィールド値がURLのものかオリジンのものか、ページテンプレートが正しくグループ化されているか、どの地域、ネットワーク、ナビゲーションタイプ、またはリリースに低速なサンプルが含まれているかを確認します。テストデバイスが実際のテールを捉えていない場合は、低速なRUMナビゲーションから低カーディナリティの環境ラベルを取得し、同等のCPU、ネットワーク、キャッシュ、および認証状態を再現します。それでも再現できない場合は、オンラインの帰属証拠を保持します。高速なデバイスを繰り返し実行しても、問題をテストで消し去ることはできません。
フォローアップ2: グローバルのp75は合格しているものの、ローエンドAndroidの1セグメントのみINPが不合格です。修正すべきですか？
そのセグメントのトラフィック、ビジネス上の重要性、サンプルの信頼性を検証します。グローバルなしきい値の合格は集計分布を示すものであり、すべての重要なコホートを保証するものではありません。そのデバイス層に多くの有料ユーザーが含まれている場合や、INPが500ミリ秒を大幅に超えている場合は、セグメントSLOを定義して対処します。サンプルが極めて少ない場合は、まずオブザーバビリティを改善します。すべての小さなセグメントを厳格なリリースゲートにすると、サンプリングノイズによってリリースが阻害される可能性があります。
フォローアップ3: LCP要素がWebフォントを使用する見出しテキストの場合、計画はどう変わりますか？
リソース検出の対象が画像からフォントとブロッキングスタイルに移行します。フォントリクエストがいつ検出されるか、オリジン間接続をまたぐか、ファイルサイズ、font-display、フォールバックフォントの寸法、および見出しがクライアントレンダリングを待機しているかを確認します。画像のfetchpriority計画をそのままコピーしてはいけません。ファーストスクリーンで実際に使用されるフォントファイルのみをプリロードし、これによって重複ダウンロードが発生したり、よりクリティカルなリソースが押し出されたりしないことを確認します。
フォローアップ4: 遅いインタラクションがクロスオリジンの決済iframe内にあります。トップページ側で何ができますか？
INPはiframeのインタラクションによるユーザーレイテンシを反映できますが、クロスオリジンの境界によりトップページの帰属機能は制限されます。RUMを埋め込みバージョンおよび親ページと相関させ、プロバイダーからのパフォーマンス証拠や再現可能なテストを活用し、そのプロバイダーと協力します。トップページ側でも、同時に発生する自身のロングタスクを削減できます。内部のコールスタックがない場合は、証拠の境界を明確に述べる必要があります。プロバイダーに自動的に責任を負わせることも、ローカルコードでiframeを修正したと主張することも避けます。
フォローアップ5: ページにURLレベルのCrUXデータを取得する十分なトラフィックがありません。合格かどうかをどのように判断しますか？
ファーストパーティRUMを使用してアクセスごとの指標と必要な環境フィールドを収集し、サンプルサイズと時間枠の両方を報告しながら、ラボのクリティカルジャーニーテストでリグレッションを防ぎます。テンプレートレベルの集計によってサンプルサイズを増やせるのは、ページ構造とユーザージャーニーが同等である場合のみです。データが不十分な場合、既知のトレースが改善されたことは証明できますが、URLレベルで「良好」なCrUXステータスであると主張することはできません。
フォローアップ6: ヒーローを早期にレンダリングするとLCPは改善しますが、ハイドレーションが早く開始されてINPが悪化します。どうすべきですか？
これは指標間の現実的なトレードオフであるため、両方の結果を保持します。早期レンダリングに本当に早期ハイドレーションが必要かどうかを確認します。多くの場合、インタラクションコードをオンデマンドで読み込みながら、静的な可視コンテンツを先に届けることができます。即時のインタラクションがビジネス要件である場合は、重要なユーザーアクションを中心にバジェットを設定し、メインスレッドの処理を分割し、ロールアウト中にLCP、INP、およびコンバージョンを比較します。複合パフォーマンススコアによってINPのリグレッションを覆い隠してはなりません。
フォローアップ7: プライバシーポリシーにより、完全なURLとDOMターゲットの保存が禁止されています。RUMで問題を診断できますか？
事前定義されたルートテンプレート、コンポーネント列挙型、インタラクションタイプ、リリースバージョン、粗いデバイス層を使用します。商品ID、クエリパラメータ、テキスト、ユーザー識別子は保持しないでください。レポート送信前にクライアント側でフィールドをマッピングし、サーバー側で高カーディナリティの値を拒否します。帰属の精度は低下するため、列挙されたコンポーネントやジャーニーを中心としたラボでの再現によってそのギャップを埋める必要があります。パフォーマンス診断は、個人データの収集を拡大する許可証ではありません。