測定対象: ユーザー重視のパフォーマンスの主要な指標 (Measuring What Matters User Centric Performance)

ユーザー重視のパフォーマンス測定

ユーザー中心のパフォーマンス測定は、システムがトラフィックを生成するか、技術的に負荷がかかるかどうかに基づいていません。人々が迅速に、簡単に、確実に、そして満足のいく形で目標を達成できるかどうかを評価します。最も強力な測定システムは、行動データ、ユーザーの認識、ビジネス結果、および技術的パフォーマンスをまとめて読み取ります。

1. ユーザー行動の指標

これらは、ユーザーが実際に行うことを示しています。

• タスク完了率: 定義されたタスクを正常に完了したユーザーの割合。
• タスク期間: 目標に到達するまでに必要な時間。
• エラー率: 失敗したアクション、検証エラー、またはシステム エラーの頻度。
• エラー回復率: エラー後に回復し、タスクを完了したユーザーの割合。
• 機能の導入率: 対象となるユーザーが特定の期間内にその機能を使用した割合。
• ファネル放棄: 複数ステップのプロセスでユーザーが離脱する場所。
• Time to value: 登録またはエントリから最初の意味のある結果までの時間。

行動指標は、単に「クリック数を増やす」ではなく、「チェックアウトを完了する」など、特定のユーザーの目標に結び付けた場合に最も効果を発揮します。 GitLab の UX フレームワークでは、タスクの完了、タスク時間、エラー、ファーストクリックの精度、機能の導入が主要な行動指標として考慮されます。 handbook.gitlab

2. ユーザーの認識指標

分析は何が起こったかを示します。態度指標は理由を説明するのに役立ちます:

• 顧客満足度 (CSAT): エクスペリエンスに対する満足度。
• 知覚された使いやすさ: 製品の使いやすさ。
• 顧客努力スコア (CES): 顧客が費やしたと思われる労力。- 認識された効率: 製品が時間を節約するかどうか。
• ネット プロモーター スコア (NPS): 製品を推奨する可能性。
• 認識された有用性: 意味のある問題を解決できるかどうか。

製品のタスク完了率は高くても、イライラしたり、不必要に難しく感じたりすることがあります。したがって、行動と態度の尺度は一緒に評価されるべきです。 handbook.gitlab

3. 保持率と価値の指標

これらは、製品が継続的な価値を提供しているかどうかを示します。

• アクティベーション率: 最初の意味のあるアクションを完了した新規ユーザーの割合。
• 維持率: 一定期間後に戻ってきてアクティブな状態を維持するユーザーの割合。
• 解約率: 製品の使用を中止したユーザーの割合。
• DAU/WAU/MAU: 毎日、毎週、毎月のアクティブ ユーザー。
• 接着性: 通常、DAU÷MAU 比として近似されます。
• コホート保持: 登録日または共通の特性ごとにグループを個別に追跡します。
• 紹介率: ユーザーが他の人を紹介または招待する頻度。

機能構造: ユーザーに提供される価値を表す ノース スター メトリックを定義し、チームが影響を与えることができる 2 ～ 3 つの入力メトリックを選択します。たとえば、コラボレーション製品には、「毎週成功したコラボレーション」が北極星としてリストされます。プロモーターとしてアクティベーション、機能の導入、保持を使用できます。 youtube

4. 技術的なパフォーマンスの指標

デジタル製品では、技術的な速度はユーザーの観点から測定される必要があります。

ユーザーエクスペリエンス	役立つ指標
最初の可視性	最初のコンテンツフル ペイント (FCP)、最大のコンテンツフル ペイント (LCP)
決意	累積レイアウト シフト (CLS)
サーバーの応答	最初のバイトまでの時間 (TTFB)
流暢さ	フレームの一貫性とアニメーションの応答
信頼性	クラッシュ、失敗したリクエスト、停止およびエラー率

Web パフォーマンスは、管理された実験室テストとリアル ユーザー モニタリング (RUM) の両方で測定される必要があります。なぜなら、デバイス、ネットワーク、パーソナライゼーション、インタラクションがエクスペリエンスを根本的に変えるからです。 ウェブ

5. 一連の実際的な測定値

ほとんどのチームは、次の 5 つの指標から始めることができます。

1. 価値指標: ユーザーがアクセスする理由となる主要な結果。
2. 行動指標: タスク完了率またはタスク期間。
3. 認識指標: CSAT、CES、または認識された使いやすさ。
4. 保持指標: コホートの保持または再利用。
5. 信頼性またはパフォーマンスの指標: エラー率、INP、LCP、または稼働時間。

優れた指標は、明確で正規化されており、時間の経過とともに比較可能で、意味のあるユーザー グループに分割され、実用的である必要があります。合計ページビュー数、ダウンロード数、登録ユーザー数、またはセッション継続時間だけに依存しないでください。これらは意味のある価値を生み出さずに成長する可能性があります。 youtube

例

オンライン返金サービスの場合:

• North Star: 現役従業員あたりの請求が正常に返されました。
• 動作: リクエストの完了率と送信時間の中央値。
• 認識: 出荷後の使いやすさのスコア。
• 保持率: 90 日以内に 2 回目のリクエストを送信した従業員の割合。
• 技術: プラグ読み込み中のエラー率と INP。
• 診断: バウチャー検証ステップでの放棄率。この組み合わせによって、プロセスに参加する人の数が決まるだけではありません。完了できたかどうか、体験はどう感じたか、戻ってきたかどうか、技術的な問題が成功を妨げたかどうか。

このセクションで繰り返される概念```text

📦 Laboratuvar vs saha Kontrollü, tekrarlanabilir teşhis ile gerçek kullanıcı ortamındaki doğrulama.

📦 Core Web Vitals (CWV) LCP, INP ve CLS—yükleme, yanıt ve görsel kararlılık; gerçek kullanıcıların 75. yüzdeliğinde.

📦 FID → INP (Mart 2024) FID yalnızca ilk girdi gecikmesini ölçüyordu; INP ziyaret boyunca etkileşim yanıtını ölçer.

📦 RUM Gerçek kullanıcı izleme: cihaz, ağ, rota ve özellik boyutlarında production ölçümü.

📦 CrUX Chrome kullanıcı deneyimi raporu—uygun siteler için kamuya açık saha verisi.

📦 Performans bütçesi LCP/INP/CLS, JS ağırlığı, üçüncü taraf maliyeti ve iş akışı başarı limitleri.

📦 Attribution (ilişkilendirme) web-vitals attribution build: LCP öğesi, INP hedefi, LoAF ve alt faz süreleri.

## 臨床検査と現場での測定

ユーザー重視の性能における **実験室テスト** では、制御された再現可能な条件下で製品を測定します。 **フィールド測定**では、ユーザーの実際の環境でのパフォーマンスを観察します。一般に、ラボの結果は、問題の原因を見つけるのに適しています。現場での結果は、製品が日常の使用で機能するかどうかをよりよく理解します。 [web.mit](https://web.mit.edu/6.813/www/sp16/classes/11-experiment-design/)

### 臨床検査

臨床検査では、ユーザー、タスク、デバイス、および条件を定義されたプロトコルに組み込みます。

一般的な寸法:

- タスクの完了率。
- 任期。
- エラーの頻度と回復。
- ナビゲーションまたはクリックパス。
- 最初のクリック精度。
- 認識された可用性と作業負荷。
- タスク後の満足感。
- デザインバージョン間の比較。

**長所:** 高い制御性と再現性。競合するデザインを比較するのは簡単です。特定のインターフェイスの問題を分離します。プロトタイピングや制御された A/B スタイルの実験に適しています。

**制限事項:** 参加者は、監視されていることがわかっているため、異なる行動をとる可能性があります。人為的なタスクは実際の優先順位を反映していない可能性があります。静かなテスト ルームでは、すべての職場、ネットワーク、技術的条件を再現することはできません。実際のコンテキストがより困難な場合、ラボはユーザビリティを過大評価する可能性があります。

ラボとフィールドのユーザビリティテストを比較した研究では、普遍的な勝者は見つかりませんでした。条件が良好な場合、結果は同様になる可能性があります。困難な状況、可用性の低さ、競合するタスクなどでは、違いが生じます。 [pubmed.ncbi.nlm.nih](https://pubmed.ncbi.nlm.nih.gov/30487113/)

### フィールド測定フィールド測定は、ユーザーが通常仕事、旅行、買い物、または製品を操作する場所で行われます。これには、直接観察、状況に応じたインタビュー、日記調査、遠隔遠隔測定、またはフィールドでのユーザビリティ テストが含まれる場合があります。

有用なフィールド指標: 現実世界のミッションの成功。中断を含む継続時間。環境およびネットワークの状態。デバイス/プラットフォームの違い。エラーの頻度と重大度。回避策;再利用と保存。遅延、クラッシュ、リクエストの失敗。ワークフローへの準拠に関するユーザーのコメント。

**長所:** 本物の動作とコンテキスト。注意力が散漫になると、インフラストラクチャや環境ツールによって引き起こされる問題が明らかになります。製品が実際のルーチンに統合されているかどうかを示します。これは、モバイル、職場、産業、ヘルスケア、およびロケーションベースの製品で特に価値があります。

**制限事項:** 変数の制御が少なくなります。参加者を直接比較するのは困難。データにはノイズが多くなる可能性があります。プライバシーと同意の要件はより厳しくなります。

現場は現実主義に強く、実験室は精度と制御に強い。 [web.mit](https://web.mit.edu/6.813/www/sp16/classes/11-experiment-design/)

### 何を測定するのですか?

|質問 |実験室での測定 |フィールドの寸法 |
|---|---|---|
|ユーザーはタスクを完了できますか? |定義されたシナリオでの完了率 |実作業中の完了率 |
|彼らはどれくらい効率的に働いているのでしょうか？ |タスクの継続時間、クリック数、キーストローク |停止、移行、回避策を含む期間 |
|何が間違っているのでしょうか? |観察されたエラーと失敗したインタラクション |プロダクションエラー、サポートリクエスト、放棄されたタスク |
|それはどんな感じですか？ |満足度、作業量、使用感 |長期的な満足度、信頼、不満、知覚価値 |
|信頼できるものですか? |制御された応答時間とデバイスのテスト |実際の遅延、接続の変動、クラッシュと障害 ||それは価値を生み出しますか？ |インスタントミッション結果 |再利用、保持、導入、ビジネス/ユーザーの成果 |

### 推奨されるアプローチ

2 つをループとして使用します。 1 つだけを選択しないでください。

1. **ラボから開始** - 明らかなユーザビリティの問題を見つけ、代替案を比較します。
2. **現場で測定** - 本物の条件で動作をテストします。
3. **研究室に戻る** - 現場での重大な問題の原因を調査します。
4. **運用環境での検証** - 分析、フィードバック、パフォーマンス監視を使用します。
5. **結果をスライス** - デバイス、エクスペリエンス、アクセシビリティのニーズ、場所、接続、およびタスクの種類。

例: モバイル経費アプリは、ラボでは 95% の配送率を取得する可能性があります。現場では、照明が不十分な場合やモバイルネットワークが不十分な場合にチップを撮影すると、ドロップアウトが明らかになることがあります。ラボではインターフェイスの問題が示されています。現場では、それを重要なものにする環境的および技術的条件が明らかになります。

基本原則: **実験室のスキルを説明します。フィールドは実際のパフォーマンスを検証します**。信頼できるユーザー中心の評価には、通常、両方が必要です。

## Core Web Vitals: 主要な指標

**Core Web Vitals (CWV)** は、ページ エクスペリエンスの 3 つの部分 (読み込み、応答性、視覚的な安定性) を評価する Google のユーザー中心の指標です。現在のセットは **LCP、INP、および CLS** です。 [ウェブ](https://web.dev/articles/vitals)

|メトリック |対策 |良いターゲット |
|---|---|---:|
| **最大のコンテンツフル ペイント (LCP)** |主要な表示コンテンツ (ヒーロー画像、見出し、または大きなテキスト ブロック) がどのくらい早く表示されるか | ≤ 2.5 秒 |
| **次のペイントへのインタラクション (INP)** |訪問中のクリック、タップ、キーボード操作に対する視覚的な反応はどれくらい速いか | ≤ 200 ミリ秒 |
| **累積レイアウト シフト (CLS)** |ページの読み込み中または使用中に、表示されるコンテンツが予期せずどのくらい移動するか | ≤ 0.1 |

### 各指標は何を示していますか?- **LCP — 読み込み中:** 「ユーザーは重要なコンテンツをすぐに見ることができますか?」
- **INP — 応答:** 「ユーザーが対話すると、インターフェイスはすぐに応答しますか?」
- **CLS — 安定性:** 「予期せぬスクロールをせずにページを読んだりクリックしたりできますか?」

INP は 2024 年に **最初の入力遅延 (FID)** に置き換わります。正式な移行は **2024 年 3 月 12 日**です。 FID は最初の相互作用のみを測定しました。 INP は、訪問中のインタラクションの反応を評価します。ブラウザ ツールでの FID サポートは、2024 年 9 月をもって廃止されました。 [dynatrace](https://www.dynatrace.com/knowledge-base/core-web-vitals/) · [developer.chrome](https://developer.chrome.com/docs/crux/release-notes)

### CWV はどのように評価されますか?

実際のユーザーデータ**75。パーセンテージ** では、モバイルとデスクトップを別々に測定します。ページが全体的に「良好」な CWV 評価を受けるには、3 つの指標すべてが「良好」のしきい値を満たしている必要があります。 [ウェブ](https://web.dev/articles/vitals)

Lighthouse と Chrome DevTools は問題の診断に役立ちます。実際のユーザー フィールド データは、デバイス、ネットワーク、場所全体での実際のパフォーマンスを示します。 PageSpeed Insights、CrUX、Search Console は、これらの結果の追跡に役立ちます。 [ウェブ](https://web.dev/articles/vitals)

### 一般的な修復アクション

- **LCP:** ビジュアルを最適化し、レンダリングをブロックするリソースを削減し、サーバーの応答を改善し、スクロールせずに見える範囲のコンテンツを優先します。
- **INP:** 長い JavaScript タスクを分割し、メインスレッドの作業を制限し、イベント ハンドラーを高速化します。
- **CLS:** 画像と広告用のスペースを割り当て、既存のコンテンツの上にコンテンツを追加せず、フォントとサイズを修正します。

CWV は貴重なテクニカル指標です。ただし、タスクの完了、放棄、満足、コンバージョンなどのユーザー中心の結果と組み合わせる必要があります。高速なページが、必ずしも有用なページや成功するページであるとは限りません。## 最大のコンテンツフル ペイント (LCP)

**LCP は、ユーザーがページを開いてからメインの表示コンテンツが表示されるまでの時間を測定します。** ビューポート内の最大の画像、ビデオ フレーム、またはテキスト ブロックのレンダリングが完了した瞬間を記録します。知覚される読み込み速度を示す強力な指標です。 [ウェブ](https://web.dev/articles/lcp)

### LCP としてカウントされるものは何ですか?

LCP 要素の多くは、ヒーローまたはバナー画像です。目立つタイトルまたはテキストブロック。製品画像。ビデオポスターまたは最初に表示されるビデオフレーム。 CSSが読み込まれた大きな画像です。

LCP は **First Contentful Paint (FCP)** とは異なります。FCP は、コンテンツが表示される最初の瞬間を測定します。 LCP は、プライマリ コンテンツが表示される瞬間を推定します。 [ウェブ](https://web.dev/articles/lcp)

### LCP しきい値

| LCP結果 |経験 |
|---|---|
| **2.5 秒以内** |良い |
| **2.5 ～ 4 秒以上** |改善すべき |
| **4 秒以上** |弱い |

** ページ読み込みの 75%。結果が単なる平均ではなく、ほとんどのユーザーを代表するように、少なくともモバイルとデスクトップとは別にパーセンテージ**を考慮してください。 [ウェブ](https://web.dev/articles/lcp)

### LCP が遅い原因は何ですか?

LCP は通常、**4 つの遅延**で構成されます。

1. **サーバー応答遅延:** ブラウザーは最初の HTML 応答 (TTFB) を待ちます。
2. **読み込み遅延:** ブラウザが LCP リソースを発見するのが遅れるか、リクエストを開始するのが遅くなります。
3. **リソースの読み込み時間:** 画像、ビデオ、フォント、その他のコンテンツのダウンロードには時間がかかります。
4. **レンダリングの遅延:** ソースの準備はできていますが、JavaScript、CSS、またはその他の作業により画面へのレンダリングが遅れます。 [developer.chrome](https://developer.chrome.com/docs/performance/insights/lcp-breakdown)HTTP Archive Web Almanac 2024 によると、モバイル ページの約 73% で LCP 要素は画像です。画像ベースの LCP はテキストベースよりも約 2 倍遅くなる傾向があります。アバブザフォールド LCP イメージの遅延読み込みをオフにし、必要に応じて `fetchpriority="high"` を使用してネットワークの優先順位を与えると、重要な予算が維持されます。

### LCP を改善するにはどうすればよいですか?

- サーバーの応答を改善します。効果的なキャッシュまたは CDN を使用します。
- LCP 画像を最適化し、正しいサイズに設定します。
- 最新の形式と適切な圧縮を使用します。
- 検出が遅れた場合は、重要な LCP リソースのみをプリロードします。
- スクロールせずに見える範囲の LCP イメージを遅延読み込みしないでください。
- レンダリングをブロックする CSS と不要な JavaScript を削除します。
- 長いメインスレッドタスクを削減します。
- Web フォントを読み込むときに重要なテキストがすぐに表示されるようにします。
- 過剰なリダイレクトやクリティカルなリクエスト チェーンを避けます。

Lighthouse などのラボ ツールを使用して原因を診断します。実際のユーザーフィールドデータを使用して改善を検証します。管理されたテストでは良好に見えるページでも、低速なデバイスまたはネットワークを使用しているユーザーに対しては、不十分な LCP が生成される可能性があります。

## FID、INP、CLS

これらの指標は、エクスペリエンスの 2 つの異なる部分をカバーします。**応答性** - ページが入力にどれだけ早く応答するか - と **視覚的な安定性** - コンテンツがユーザーが期待する場所に留まるかどうかです。

### 最初の入力遅延 (FID)

**FID は、ユーザーの最初の操作とブラウザがその処理を開始するまでの遅延を測定しました。** 初期入力遅延 (たとえば、ボタンのタップとイベント ハンドラーの開始の間) のみをキャプチャしました。FID は当初、JavaScript によってブロックされたページを検出するのに役立ちました。しかし、完全な相互作用やその後の相互作用は測定されませんでした。 FID は **Core Web Vital として廃止され、INP** に置き換えられました。 [developer.chrome](https://developer.chrome.com/docs/crux/release-notes)

FID のアーキテクチャ上の欠点は、開発者がイベントを非同期にすることで人為的にスコアを改善できることでした。長いタスクがバックグラウンドで実行されている間、ユーザーはページが鈍いと感じることがありました。 INP はこの盲点を埋めます。

### 次のペイントへのインタラクション (INP)

**INP は、訪問中のユーザー インタラクションに対する視覚的な応答の速さを測定します。** 入力遅延には、イベント ハンドラーの処理、レンダリング ジョブ、次の画面更新までの時間が含まれます。 [ウェブ](https://web.dev/articles/inp)

例: ナビゲーション メニューをクリックします。検索フィールドに入力します。 「カートに追加」にはタッチしないでください。ダイアログまたはポップアップ メニューを開く。フィルターまたはタブを選択します。

| INPスコア |応答性 |
|---|---|
| **≤ 200 ミリ秒** |良い |
| **> 200 – 500 ミリ秒** |改善すべき |
| **> 500 ミリ秒** |弱い |

良好な INP は、実際のページ訪問の **75% です。割合** - 通常、モバイルとデスクトップは別々に評価されます。 [ウェブ](https://web.dev/articles/optimize-inp)

INP は 3 つのサブフェーズに分かれています: **入力レイテンシー** (メインスレッドがビジーな場合)、**レンダリング時間** (重いイベント ハンドラー)、**プレゼンテーション レイテンシー** (スタイル/レイアウト/ペイントおよび大規模な DOM)。最適化は、どのフェーズが優勢であるかによって異なります。

#### INP の改善

- 長い JavaScript タスク (`scheduler.yield()` またはスケジューラ API) を分割します。
- 不要な JavaScript とサードパーティのスクリプトを削減します。
- イベント ハンドラーを小さく効率的に保ちます。
- 重要でない作業は対話が終わるまで延期します。
- 過剰な DOM 更新を避けてください。- 効率的なレンダリングおよびアニメーション技術を使用します。
- ページ読み込み中のメインスレッドのブロックを軽減します。

**ロング アニメーション フレーム (LoAF)** API は、INP を診断するために 50 ミリ秒を超える視覚化更新を公開します。呼び出し元、スクリプト タイプ、および `sourceURL` / 文字位置によって原因となるコードにフラグを立てます。

### 累積レイアウト シフト (CLS)

**CLS は、表示されているコンテンツの予期しない動きを測定します。** CLS が高い場合は、ボタン、テキスト、または画像が表示された後に移動することを意味します。ユーザーは場所を失ったり、間違ったコントロールをクリックしたりする可能性があります。 [ウェブ](https://web.dev/articles/cls)

一般的な原因: 画像/ビデオのサイズが大きすぎます。既存のコンテンツの上に広告またはバナーが配置されます。フォントの遅延読み込みによりテキスト サイズが変更されます。動的な通知。表示された後にレイアウトを変更する JavaScript。

| CLSスコア |視覚的な安定性 |
|---|---|
| **≤ 0.1** |良い |
| **> 0.1 – 0.25** |改善すべき |
| **> 0.25** |弱い |

CLS は時間の測定ではなく、単位のないスコアです。影響を受けるビューポート比率とオフセット距離の両方が考慮されます。 [docs.newrelic](https://docs.newrelic.com/docs/new-relic-solutions/observability-maturity/digital- experience/l2-cwv-cls/)

#### CLS の改善

- 画像とビデオにオープン `width` および `height` を付与します。
- 広告、埋め込み、動的コンテンツ用のスペースを割り当てます。
- すでに表示されているコンテンツの上にコンテンツを挿入しないでください。
- 重要なフォントをプリロードまたは固定します。
- アニメーションではレイアウト機能よりも `transform` および `opacity` を優先します。
- 最終的なコンテンツと同じサイズのプレースホルダーを使用します。
- `content-visibility: auto` を使用する場合は、スクロールを避けるために `contain-intrinsic-size` でスペースを予約してください。

### 実質的な区別- **FID:** ブラウザは最初のインタラクションを迅速に処理しましたか? (歴史的)
- **INP:** ページは、訪問中のインタラクションにすぐに応答しますか?
- **CLS:** ユーザーが読んだり操作したりするときに、ページは視覚的に安定していますか?

現在の Core Web Vitals レポートでは **INP と CLS** に焦点を当てます。 FID は、古いレポートや履歴データを解釈するときに主に意味を持ちます。

## コア Web バイタルを超えて

LCP、INP、CLS は必須です。しかし、パフォーマンスの問題をすべて説明できるわけではありません。サポート指標により原因を診断します。製品とビジネスの指標は、技術的な改善が実際にユーザーに役立つかどうかを示します。

### サポートする指標とレポートを解釈する

|メトリック |説明に役立つもの |
|---|---|
| **最初のコンテンツフル ペイント (FCP)** |ユーザーが初めてページのコンテンツを閲覧したとき |
| **最初のバイトまでの時間 (TTFB)** |サーバー、ネットワーク、バックエンドの応答遅延 |
| **合計ブロッキング時間 (TBT)** |ラボテストでのメインスレッドのブロック |
| **スピードインデックス** |表示可能なコンテンツが徐々に表示されるまでの速度 |
| **溶接重量** | JavaScript、CSS、画像、フォント、サードパーティのペイロード サイズ |
| **ロングミッション / LoAF** |メインスレッドをブロックする JavaScript と長いキーフレーム |
| **エラーと失敗率** |リクエスト、スクリプト、または重要なワークフローが失敗したかどうか |
| **変革、放棄、そして任務の成功** |パフォーマンスがユーザーの結果に影響するかどうか |

FCP と TTFB は LCP の診断に特に役立ちます。TTFB はサーバーの遅延を明らかにすることができ、FCP はレンダリングのブロックやレンダリングの時期尚早の問題を明らかにすることができます。 TBT は本質的に **臨床検査**です。フィールドは INP を置き換えません。 [ウェブ](https://web.dev/articles/user-centric-performance-metrics)

レポートを解釈する場合:1. フィールドデータから始めます。影響を受けるページ、デバイス、地域、ブラウザ、ユーザー セグメントを見つけます。
2. 平均ではなく、75 パーセンタイルに注目してください。
3. 「ユーザーが経験すること」と「原因」を分離します。
4. ラボツールを使用して原因を再現し、切り分けます。
5. スコアが最も低いページだけではありません。重要な旅に影響を与える問題に優先順位を付けます。
6. 仮説を立て、的を絞った変更を加え、再度測定します。
7. 変更によってパフォーマンスとユーザーの結果 (完了や変換など) の両方が改善されることを確認します。

Lighthouse のスコアを目標として考えないでください。目標は「100」ではありません。実際のユーザーにとって、より高速で、応答性が高く、安定したエクスペリエンスが得られます。

### 進化するクライアント アーキテクチャ (概要)

SPA では、ソフト ナビゲーションによって LCP がリセットされず、CLS が蓄積し続ける可能性があります。実験的な **ソフト ナビゲーション API** は、ユーザー アクション + URL 変更 + 可視ペイント条件下でソフト ナビゲーションを検出し、RUM でのインタースティシャル LCP の測定への扉を開きます。 **Speculation Rules API** を使用したプリレンダリング/プリフェッチにより、LCP をゼロに近づけることができます (追跡セクションの Ray-Ban の例)。 **sGTM (サーバーサイド タグ マネージャー)** は、ブラウザからサードパーティのタグの重み付けを取得するためのメイン スレッドと DNS/TLS のコストを削減し、INP と LCP に直接反映されます。

## 研究用ツール

### Lighthouse: パフォーマンス監査

Lighthouse は、パフォーマンス、アクセシビリティ、SEO、ベスト プラクティス、PWA 機能の自動監査を提供します。パフォーマンス レポートには、指標、診断チェック、機会、提案される改善リンクが含まれます。 [developer.chrome](https://developer.chrome.com/docs/devtools/lighthouse)

Lighthouse を次の目的で使用します。

- プルリクエストまたはビルドコントロール。
- 再現可能なベースライン比較。
- レンダリングをブロックするソースの検出。- 大きすぎる画像や未使用の JavaScript の検索。
- LCP、CLS、FCP、TBT、および関連するラボ指標を調査します。
- サイトのトラフィックが少ない、またはまったくないページのテスト。

同じ URL、デバイス エミュレーション、ネットワーク プロファイル、認証状態、繰り返しなど、一貫した条件で実行します。単一の実行はノイズが多いと考えてください。中央値や傾向を見てください。 Lighthouse CI では、`numberOfRuns` (例: 3 ～ 5) およびメトリックベースのアサーションにより、スコア ノイズに基づいてより信頼性の高いゲートが作成されます。

### Chrome DevTools パフォーマンス パネル: 詳細な診断と AI 支援

[パフォーマンス] パネルは、ネットワーク アクティビティ、CPU 作業、JavaScript の実行、レンダリング、レイアウト、ペイント、ユーザー インタラクションなどのブラウザ トレースを記録します。 Lighthouse は、症状は見つかったものの、正確なブロック アクティビティを見つける必要がある場合に使用するツールです。 [developer.chrome](https://developer.chrome.com/docs/devtools/パフォーマンス/概要)

実践的なワークフロー:

- ページの読み込みや遅いインタラクションを節約します。
- **インサイト** ビューで、LCP フェーズ、レンダリング ブロック リクエスト、レイアウト シフト違反者、および長いタスクを探します。
- メインのタイムラインとフレーム チャートを担当するスクリプト、スタイルの再計算、レイアウト、またはペイントを見つけます。
- トレースを [ネットワーク] パネルおよび影響を受ける DOM 要素に関連付けます。
・修正後、再保存してください。

Chrome DevTools は、保存されたパフォーマンス プロファイルに対する AI 支援も提供します。選択した洞察を説明したり、アクティビティを追跡したり、可能な改善点を提案したりできます。これを分析補助として使用し、トレースとコードに対して各提案を検証します。 [developer.chrome](https://developer.chrome.com/docs/devtools/ai-assistance/performance) LoAF レジスタは、INP ボトルネックを機能とリソースの場所に絞り込みます。

### WebPageTest: 現実的なテストと高度な分析WebPageTest は、場所、ブラウザ、デバイス、接続プロファイル、繰り返し実行にわたる現実的で高度なテストに役立ちます。 **フィルムストリップ** ユーザーが時間の経過とともに目にするもの。 **ウォーターフォール** は、リクエストの依存関係、スケジューリング、優先度、リソースのレイテンシを示します。 [パフォーマンス.shopify](https://performance.shopify.com/blogs/blog/how-to-test-with-webpagetest)

研究するときに使用します。

- 特定の国または地域からのパフォーマンスが遅い。
- モバイル デバイスとネットワークの動作が遅い。
- 初登場と繰り返し登場。
- CDN、DNS、TLS、サーバーおよび接続のスケジューリング。
- 視覚的な発見とリクエストの優先順位付け。
- サードパーティのスクリプトとウォーターフォールのボトルネック。
- 最終スコアだけでなく視覚的な進行。
- サードパーティの SPOF シミュレーション (タグ サーバーがダウンしたときにクリティカル パスがブロックされるかどうか)。

## フィールドツール

### `web-vitals.js` を使用したフィールドでの CWV キャプチャ

`web-vitals` ライブラリは、ブラウザーで Core Web Vitals を測定し、結果を分析システムまたは可観測性システムに送信します。最小限のアプリケーション:```html
<script type="module">
  import {onCLS, onINP, onLCP}
    from 'https://unpkg.com/web-vitals@4?module';

  function sendToAnalytics(metric) {
    navigator.sendBeacon('/rum', JSON.stringify({
      name: metric.name,
      value: metric.value,
      id: metric.id,
      path: location.pathname
    }));
  }

  onCLS(sendToAnalytics);
  onINP(sendToAnalytics);
  onLCP(sendToAnalytics);
</script>
```公式ライブラリは **アトリビューション** ビルドも提供します。LCP 要素またはリソースは、`inputDelay` / `processingDuration` / `presentationDelay`、`interactionTarget`、LoAF レコードなどの INP のデバッグ コンテキストを追加します。スコアの代わりに犯罪者の座標を与えます。 [developers.google](https://developers.google.com/codelabs/chrome-web-vitals-js)

本番環境にプライバシーに配慮したディメンションを追加: ページ テンプレートとルート。デバイスクラスと接続タイプ。ブラウザとオペレーティング システム。国または地域。バージョン;ログイン済み/匿名。実験または機能のフラグ。

プライバシー設計で明示的に許可されていない限り、URL、ユーザー ID、フォームのコンテンツ、またはその他の個人データを送信しないでください。

### CrUX と外部データ

**Chrome ユーザー エクスペリエンス レポート (CrUX)** は、人気のあるサイトでの対象となる実際の Chrome ユーザーのエクスペリエンスを表します。 PageSpeed Insights、Search Console、CrUX API、BigQuery を介して、LCP、INP、CLS、およびその他のディメンションのフィールド データを提供します。 [developer.chrome](https://developer.chrome.com/docs/crux)

CrUX は次の目的で価値があります。 パブリック Web に対するベンチマーク。パフォーマンスの問題が実際のユーザーに影響を与えるかどうかを確認します。リリースによって現場のパフォーマンスが変わるかどうかを検証する。モバイルとデスクトップの比較。歴史的な傾向。

CrUX には適用範囲と可用性の制限があります。すべてのユーザーまたはすべてのページを表すわけではありません。 28 日移動平均は、昨日の分布の影響を示していません。正確な対象ユーザーおよび製品固有のディメンションを得るには、ファーストパーティ RUM と併用します。

### Web Vitals を超えて RUM

実際のユーザーのモニタリングでは、次のものもキャプチャする必要があります。

- ルート変更または SPA ナビゲーションのタイミング (ソフト ナビゲーションで強化可能)。
- API レイテンシと失敗したリクエスト。- JavaScript エラーと Promise の拒否。
- 長いミッションと長いキーフレーム (LoAF)。
- 機能ごとのインタラクション遅延。
- 検索、支払い、ログインまたはアップロードの完了。
- 怒り狂ってクリックし、再試行して放棄します。
- クラッシュ、オフライン状態、接続の変更。
- 測定可能な場合のアクセシビリティ障害。

有益な質問は、「INP は悪いですか?」というだけではありません。そうではありません。 「どのインタラクションが、どのユーザーに対して、どのバージョンで遅いのか、そしてそれがタスクの完了を妨げているのでしょうか?」

サードパーティのマーケティング/分析スクリプトは、測定のために追加されると、逆説的に INP/LCP を破壊する可能性があります。 **sGTM** は、ブラウザ内の多数のスクリプトを単一のファーストパーティ ストリームにまとめます。 JS の実行、DNS、SSL のコストをクラウドに移すため、計測自体がパフォーマンスを低下させることはありません。

## 予算、アラート、継続的なモニタリング

パフォーマンス予算は、品質目標を強制可能な制限に変換します。ユーザーの指標と理由の両方に基づいて予算を定義します。

- LCP: 75 パーセンタイル ≤ 2.5 秒。
- INP: 75 パーセンタイル ≤ 200 ミリ秒。
- CLS: 75 パーセンタイル ≤ 0.1。
- JavaScript 転送: ルートごとに最大値が合意されています。
- 合計ページ重量: デバイス クラスごとの最大値。
- サードパーティのリクエスト: 承認済みリストと最大コスト。
- エラー率: 許容可能な最大パーセンテージ。
- 重要なワークフローの成功: 最低完了率。

3 つのアラート レベルを使用します。

- **警告:** メトリック制限に近づいています。
- **回帰:** 合意されたパーセンテージを超えると指標が悪化しました。
- **重大:** Core Web Vital または重要なワークフローが失敗のしきい値を超えています。

Lighthouse CI アサーションの例 - スコアよりもメトリックベースのゲートを優先します。```json
{
  "ci": {
    "collect": {
      "url": ["http://localhost:3000/", "http://localhost:3000/blog"],
      "numberOfRuns": 3,
      "settings": { "preset": "desktop" }
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", {"minScore": 0.9}],
        "first-contentful-paint": ["warn", {"maxNumericValue": 2000}],
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}]
      }
    }
  }
}
```### 継続監視の例

実際のシステムは次のように動作します。

1. Lighthouse は、すべてのバージョンの代表的なページ セットで実行されます。
2. WebPageTest は、複数の場所と接続プロファイルから毎晩実行されます。
3. `web-vitals.js` (可能な場合は帰属) は、本番環境から匿名化された LCP、INP、および CLS を送信します。
4. ダッシュボードは、バージョン、ルート、デバイス、および地理ごとに結果をスライスします。
5. モバイル INP が 2 つの連続期間で 15% 悪化すると、アラートが起動されます。
6. チームは、影響を受ける DevTools + LoAF とのやり取りを監視します。
7. 長い JavaScript タスクを短縮した後、トレース データとフィールド データの両方が検証されます。
8. 変更は、パフォーマンスが向上し、タスクの達成/コンバージョンが低下しない場合にのみ維持されます。

これにより、**Lighthouse による検出、DevTools による診断、WebPageTest ストレス テスト、RUM による検証、予算による回帰防止**というフィードバック ループが作成されます。

### 実際の継続的なモニタリング (短い事例メモ)

- **タブーラ:** パブリッシャーサイトでの TBT/INP が高い。 LoAF によるボトルネックのマーキング、サードパーティのダウンスケーリング、レンダリング エンジンの再設計。
- **Fotocasa:** FID 期間中は緑色。 2024 年 3 月 INP 以降、Search Console に「改善が必要/弱い」と表示されます。ギャラリー、マップ、フィルターの相互作用における隠れたクライアントの速度低下は、RUM で解決されました。
- **Ray-Ban:** 投機ルールを使用して製品ページをプリレンダリングします。 LCP が約 43% 減少し (サブ 1 秒)、PDP コンバージョンがモバイルで約 101% / デスクトップで約 156% 増加したと報告されています。
- **T-Mobile:** LCP が 2 秒を超えると、100 ミリ秒の遅延ごとにコンバージョンが減少し、バウンスが増加します。彼らはスピードを KPI に変え、訪問から注文までのコンバージョンを最大 60% 増加させました。

この測定はボードを緑色に塗るためのものではありません。ミッションを実際の旅で可能にすることです。

## 最も混同されやすい組み合わせ```text
❌ FID hâlâ güncel bir Core Web Vital’dır
✓ FID Mart 2024’te emekli oldu; odak INP’dedir (ziyaret boyunca yanıt)

❌ Yeşil Lighthouse skoru saha CWV’nin iyi olduğu anlamına gelir
✓ Lab teşhis eder; CrUX/RUM gerçek kullanıcı deneyimini doğrular

❌ Ortalama LCP “yeterince iyi”yi temsil eder
✓ 75. yüzdeliği mobil ve masaüstü ayrı izleyin

❌ TBT, INP’nin yerine geçer
✓ TBT lab teşhisidir; saha yanıtı için INP kullanın

❌ web-vitals skoru tek başına kök nedeni gösterir
✓ Attribution + LoAF etkileşim hedefi ve suçlu betiği gösterir

❌ CrUX dünkü deploy’u yansıtır
✓ CrUX ~28 günlük ortalamadır; anlık regresyon için birinci taraf RUM şarttır

チェックリスト: 測定する必要があるものを測定する

1. North Star + 行動、認識、維持、技術/信頼性からそれぞれ 1 つの指標を選択します。
2. 重要な作業のラボ シナリオとフィールドの次元 (デバイス、ネットワーク、地理、ルート) を定義します。
3. LCP、INP、および CLS の p75 の「良好な」しきい値をモバイル/デスクトップごとに修正します。
4. LCP を 4 つの遅延 (TTFB、ディスカバリー、ダウンロード、レンダリング) に分割します。 INP を 3 つのフェーズに分割します。
5. 代表的な URL で Lighthouse CI + WebPageTest を実行します。中央値/傾向を読み取ります。
6. web-vitals (帰属優先) + プライバシーに配慮したディメンションを使用して RUM を運用環境にインストールします。
7. ベンチマークには CrUX を使用します。回帰と機能診断には RUM を利用します。
8. 予算と 3 つのアラート レベル (アラート / リグレッション / クリティカル) を定義します。タスクの成功または変革によって改善を検証します。

これら 8 つの項目に答えられないとしても、まだ「スコアを見ている」ことになります。まだユーザー指向の測定を行っていません。

このエピソードのピンポイント

1. ユーザー中心の測定では、トラフィックやラボのスコアだけでなく、行動、認識、維持率、技術的パフォーマンスが組み合わされます。
2. 研究室が能力と理由を説明します。フィールドは実際のパフォーマンスを検証します。この二つは循環です。
3. 現在のコア Web Vitals は LCP、INP、CLS です。 FID は歴史的なものです。 p75 のしきい値: LCP ≤ 2.5s、INP ≤ 200ms、CLS ≤ 0.1。
4. LCP は 4 つの遅延に分割され、INP は 3 つのフェーズに分割されます。 LoAF とアトリビューションは、根本原因をスコアではなく座標に帰します。
5. ソフト ナビゲーション、投機ルール、sGTM などのアーキテクチャ ツールは、測定の盲点やサードパーティの重み付けを埋めるのに役立ちます。
6. 予算、アラート、継続的なモニタリングにより、改善が永続的に行われます。 Taboola、Fotocasa、Ray-Ban、T-Mobile は、測定がビジネスの成果に結びついていることを示しています。

目標はボードを緑色にすることではありません。目標は、ユーザーが重要なタスクを迅速、確実、満足のいく方法で完了できるかどうかを知り、意識的に設計することです。

次に、Core Web Vitals を「優れた指標」から製品要件、予算、リリース ゲートに変換します。