なぜパフォーマンスがユーザーエクスペリエンスなのか (Performance Is User Experience)

パフォーマンスが UX である理由

パフォーマンスはユーザー エクスペリエンスと切り離せないものであり、最も目に見える側面の 1 つです。ユーザーは時間の経過とともに Web サイトを体験します。つまり、コンテンツが表示される速さ、アクションを実行できる速さ、インタラクションが流動的であるか不連続であると感じられるかどうかです。 Web パフォーマンスには、読み込み時間や応答などの客観的な尺度と、ユーザーの速度に対する認識の両方が含まれます。 MDN

インターフェイスが遅いと、あらゆる段階で摩擦が生じます。

• 画面が空白または表示されない場合、サイトが機能しているかどうか疑問に感じます。
• 反応しないボタンは、アクションが実行されたかどうかを示します。
• レイアウトを変更するとコンテンツが予期せず変更され、エラーが発生します。
• スクロールやアニメーションが動かなくなると、インターフェースが信頼できなくなる。
• 遅れは精神の流れを妨げ、放棄される可能性を高めます。

対照的に、高速で安定したインターフェイスは簡単に感じられます。ユーザーは、ターゲットとの間でテクノロジーを管理するのではなく、ターゲットに集中できます。 Web プラットフォームのガイダンスは、パフォーマンスの向上と、エンゲージメント、維持、満足度の強化、および放棄率の低下とを相関させます。 web.dev

パフォーマンスは品質を伝える

ユーザーは多くの場合、応答性を信頼性の表れと解釈します。すぐに反応する製品は、慎重に設計されていると感じます。製品が凍結したり、動かなくなったり、保留されたままになっていると、たとえその仕様が技術的に正しいとしても、壊れやすく感じられます。

だからこそ、パフォーマンスはエンジニアリングや最適化だけではありません。 製品要件として扱う必要があります。デザインの選択、コンテンツ戦略、JavaScript アーキテクチャ、ホスティング、視覚効果が組み合わされて、ユーザーが知覚するエクスペリエンスが形成されます。## 何を最適化するか

ユーザー重視のパフォーマンス戦略では、次のような質問をする必要があります。

1. 意味のあるコンテンツはいつ表示されますか? 最終的な読み込み時間だけでなく、待機中のエクスペリエンスを最適化します。
2. ユーザーはいつ操作できますか? 準備ができているように見えても入力を無視したページは、まだ壊れているように感じます。
3. インターフェイスの安定性はどの程度ですか? コンテンツ、広告、画像、フォントの読み込み中の予期せぬ動きを防ぎます。
4. 操作はどの程度流動的ですか? スクロール、入力、メニューを開く、およびナビゲーションは、ぎくしゃくするのではなく、連続的に感じられる必要があります。

Core Web Vitals は、このエクスペリエンスの重要な部分を測定するのに役立ちます。しかし、メトリクスは、実際のユーザーの摩擦を表す限り、価値があります。目標はボードを緑にすることではありません。実際の状況で製品が速く、明確で、信頼できると感じられるようにすることです。

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

📦 Kullanıcının algıladığı performans Deneyimin laboratuvar skorundan değil; kullanıcının hissettiği hız ve güvenilirlik.

📦 Algılanan bekleme süresi Gecikmenin duygusal süresi; çoğu zaman memnuniyeti saat süresinden daha çok etkiler.

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

📦 Saha verisi ile laboratuvar verisi Gerçek kullanıcı ölçümü ile kontrollü, tekrarlanabilir teşhis testleri.

📦 RAIL Response, Animation, Idle, Load—kullanıcı eylemlerine göre performans hedefleri.

📦 Performans bütçesi “Yeterince hızlı”yı tasarım kısıtı haline getiren ağırlık, gecikme ve kararlılık limitleri.

## 遅さの代償

Web サイトが遅いと、ユーザーがメイン コンテンツを見る前にコストが発生します。最初の遅れが第一印象になります。訪問者は、その製品が古い、信頼性が低い、または困難であるという兆候と受け止める可能性があります。したがって、パフォーマンスは、単に留まるかどうかだけではありません。また、サイトの背後にある機関についての判断も形作られます。

ユーザーは、コンテンツがすぐに表示され、インタラクションが応答性があることを期待しています。遅延が増加すると、忍耐力が低下します。ユーザーはページを離れたり、同じ操作を繰り返したり、製品に対する自信がなくなって離れたりする可能性があります。 MDN は、パフォーマンスの低下が放棄、維持率の低下、コンバージョンの低下、満足度の低下の原因であると特定しています。 [MDN](https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Performance/why_web_performance)

### 第一印象は設置時に決まります

ページが技術的に準備ができていない場合でも、読み込みエクスペリエンスはインターフェイスの一部です。

- 空白の画面では進行状況がわかりません。
- 部分的にレンダリングされたページは、製品が不完全に感じられる可能性があります。
- 目に見える読み込みインジケーターは役立ちますが、不必要に長い待ち時間を補うことはできません。
- レイアウトが変わるとインターフェイスが不安定になり、クリックミスが発生する可能性があります。
- 迅速な初期応答により、システムが動作していることが保証されます。

これは、まだ信頼を築いていない初めての訪問者にとっては特に重要です。 Google のパフォーマンス ガイドでは、遅いサイトはエンゲージメントや維持の効果が低く、読み込み時間が長くなると測定可能なユーザー離れが生じると指摘しています。 [web.dev](https://web.dev/learn/performance/why-speed-matters)

### 満足が積み重なる

1 回の遅延は許容されます。ただし、繰り返し発生する遅延はセッション全体で蓄積されます。ユーザー製品が最初にページ、次にメニュー、そして検索結果を待つのは、ゴールまでのスムーズな道ではありません。一連の障害として生きています。パフォーマンスは感情状態にも影響します。 web.dev でまとめられた研究では、ページ速度の遅れはストレスの増加と関係しています。つまり、ゆっくりとした体験は、その持続時間だけが示唆するよりも重く感じるかもしれません。このフラストレーションは時間が経つにつれて、信頼、エンゲージメント、リピート意欲、および製品を推奨する可能性を低下させます。 [web.dev](https://web.dev/learn/performance/why-speed-matters)

### ビジネスへの影響

「遅さのコスト」は相互に関連した形で現れます。

- 放棄された訪問と未完了のクエストが増えました。
- コンバージョンと収益が低下します。
- リピート利用と顧客維持の減少。
- アクションが成功したかどうかが不明確な場合、サポートに対する需要が増加します。
・ブランドに対する信頼が薄れる。
- 接続が低速または制限されているユーザーのデータ、バッテリー、デバイスのコストが高くなります。

実際の教訓は単純です。スピードは製品の第一印象とその後のすべてのやり取りの一部です。高速なサイトは時間を節約するだけでなく、ユーザーの注意に対する敬意を伝え、エクスペリエンスがより信頼できるものになるようにします。

## 待つことの心理学

待機は、秒単位の中立的な測定値としては経験されません。人は感情と期待によって遅延を判断します。インターフェイスがすぐに応答する場合、2 秒は許容できると感じるかもしれません。画面が空白であったり、結果が不確実であったり、アクションがうまくいったかどうかが不明な場合は、同じ時間がはるかに長く感じられます。

サービス体験の調査によると、**知覚される待ち時間**は、客観的な待ち時間よりも満足度に大きく影響することがよくあります。待ち時間が空っぽだったり、説明がなかったり、不確実だったり、ユーザーの制御を超えていたりすると、気分はさらに悪くなります。交流、知識、目に見える進歩により、同じ期間をより管理しやすくなります。 [エラスムス研究](https://repub.eur.nl/pub/12176/)

### デジタルでの待ち時間が苦痛である理由

いくつかの心理的影響により、遅延は Web やアプリケーションに特に悪影響を及ぼします。- **忙しくない時間が長く感じられます。** 空白の画面では集中できるものが何もありません。時間の経過に注意が移ります。
- **不確実な時間が長く感じられます。** フィードバックがない場合、システムがロード中なのか、フリーズしているのか、または障害が発生しているのかがわかりません。
- **不安な時間が長く感じられます。** お金、個人データ、または重要なタスクが関係している場合、結果によって不安が生じます。
- **不公平または制御されていない時間が長く感じられます。** なぜ待っているのか、何ができるのかを理解していないユーザーはイライラします。
- **中断された時間が長く感じられます。** 繰り返し中断すると集中力が妨げられ、タスクが実際より難しく感じられます。

最初の待ち時間は、残りのエクスペリエンスへの期待を決定するため、多くの場合特に重要です。ユーザーが価値を得る前に製品の速度が遅いと、その遅れは必要なステップではなく障害のように感じられます。

### より良い待機を設計する

最良の解決策は優れたパフォーマンスです。ただし、避けられない待機は意図的に設計する必要があります。

- ユーザーがタップまたは送信すると、すぐに応答が表示されます。
- 空白の画面をスケルトン レイアウトなどの意味のある構造に置き換えます。
- 時間が測定できる場合は進行状況を表示します。
- プロセスが複雑な場合は、何が起こったのか説明してください。
- キャンセル、再試行、バックグラウンドでの続行などの制御を与えます。
- アクションが繰り返されないように、成功を明確に確認します。
- 失敗を安全に処理できる場合にのみ、楽観的更新を使用してください。

進行状況インジケーターは客観的にプロセスをスピードアップするものではありません。これにより不確実性が軽減され、システムが機能していることがわかります。目標は、受動的に待つことを意識的な進歩に変えることです。ユーザーは、何かが起こっていること、なぜそれが起こっているのか、そして可能であればそれがどれくらい続くのかを知らなければなりません。

## UX パフォーマンスを評価するUX パフォーマンスは、**システムのパフォーマンス** と **ユーザーが目標をどのように達成するか** という 2 つの観点から測定する必要があります。ページは優れた技術スコアを取得する可能性がありますが、ナビゲーションがわかりにくかったり、エラーが頻繁に発生したり、重要なタスクに時間がかかりすぎたりすると、ユーザーはイライラすることになります。

### コア ウェブ バイタル

Google の Core Web Vitals は、読み込み、応答性、視覚的な安定性という 3 つのユーザー向けの側面に焦点を当てています。推奨される「良好な」しきい値は、実際のユーザー エクスペリエンスの 75 パーセンタイルで測定されます。 [Google 検索セントラル](https://developers.google.com/search/docs/Appearance/core-web-vitals)

|メトリック |対策 |良いターゲット |
|---|---|---|
|最大のコンテンツフル ペイント (LCP) |メインコンテンツが表示されるとき | ≤ 2.5 秒 |
|次のペイントへのインタラクション (INP) |インターフェイスがユーザー入力に目に見えて応答する速さ | ≤ 200ms |
|累積レイアウト シフト (CLS) |ページが予期せず移動する量 | ≤ 0.1 |

これらの指標は、次の 3 つの基本的な質問に答えます。 * 重要なコンテンツを見ることができますか?待たずに対話できるでしょうか?インターフェースはそのままですか?*

### 製品と可用性の指標

技術的な指標は実際のユーザーの結果と一致する必要があります。

- **タスク成功率:** タスクを正しく完了したユーザーの割合。
- **タスク期間:** 目標を達成するために必要な時間。
- **エラー率:** エラー、反復アクション、または失敗の頻度。
- **放棄率:** フローが完了する前の放棄の頻度。
- **満足度:** CSAT、タスク後の質問またはインタビュー。
- **維持とコンバージョン:** パフォーマンスの向上がコンバージョン、購入、購読、またはその他の価値のあるアクションにつながるかどうか。これらの指標は、パフォーマンスの向上が単により良い診断スコアを生み出すのか、それとも有意義な UX の向上をもたらすのかを示します。 [UX Army](https://uxarmy.com/blog/how-to-measure-ux-performance/)

### フィールドデータと実験室データ

**フィールド データ**は、実際のユーザーの実際のデバイス、ブラウザ、ネットワーク、場所から取得されます。これは、ユーザーが実際に得ているエクスペリエンスを理解するための最良の方法です。 Core Web Vitals レポートでも、この種の実世界データが使用されます。 [Google Search Console ヘルプ](https://support.google.com/webmasters/answer/9205520?hl=ja)

**実験室データ**は、制御された機器と再現可能なテスト条件から得られます。回帰を抽出し、変更を比較するのに役立ちます。ただし、現実世界のすべてのデバイスやネットワークの状態を表すことはできません。

強力な測定プロセスでは、原因を見つけるための研究室、影響を検証するための現場、そしてエクスペリエンスが実際に改善されたことを検証するためのユーザー結果指標の 2 つが使用されます。

### ページだけでなくジャーニーを測定する

ページレベルのスコアは便利です。しかし、ユーザーは**フロー**: 検索、ログイン、支払い、ファイルのアップロード、フォームへの記入を経験します。ユーザーの観点からこれらのジャーニーのパフォーマンスを測定します。

1. ユーザーが開始できるまでの時間。
2. 重要なやり取りの後に遅れます。
3. 間違いと反復的な行為。
4. 完了と放棄。
5. タスク後の満足感。

したがって、最も意味のあるパフォーマンス目標は、単なる「LCP の削減」や「INP の改善」ではありません。それは、**ユーザーが重要なタスクを迅速、安全に、不必要な労力をかけずに完了できるように支援することです。**

## 誰もが楽しめるパフォーマンス高速エクスペリエンスは、最新の電話、強力なラップトップ、または高速 Wi-Fi によって定義されるべきではありません。実際のユーザーは、古いハードウェア、限られたデータ プラン、混雑したモバイル ネットワーク、小さな画面、または負荷の高い JavaScript やアニメーションに悩まされるデバイスを使用している可能性があります。包括的なパフォーマンスとは、**コア エクスペリエンス**をこのような状況でも使用可能で応答性の高いものにすることを意味します。

### ベースラインまでの設計

遅いユーザーを異常値として扱うのではなく、妥当な最低の能力から始めます。

- 大量のダウンロードを行わなくても、重要なコンテンツとアクションを利用できるようにします。
- 画面サイズ、向き、入力方法に適応するレスポンシブなレイアウトを使用します。
- ナビゲーション、フォーム、主要な操作を小さな画面上でシンプルに保ちます。
- セマンティック HTML とプログレッシブ エンハンスメントを使用して、高度な機能をインストールしなくても基本機能が動作するようにします。
- すべてのデバイスが高速プロセッサ、大容量メモリ、タッチ接続または永続的な接続をサポートしていると想定しないでください。

目標は、より悪いモバイル バージョンを作成することではありません。同じ核となる価値を提供します。プレゼンテーションとオプション機能をユーザーのコンテキストに適応させる。

### リソースをインテリジェントに適応させる

ブラウザーは、必要以上に多くのデータや計算をデバイスに受信しないでください。レスポンシブ画像は、`srcset` および `sizes` を使用して適切なサイズを選択できます。スクロールせずに見える画像は遅延してロードできるため、表示されるコンテンツ用に帯域幅が確保されます。 [MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Responsive_images)

アダプティブ ローディングは、誰にでも高速なコア エクスペリエンスを提供し、デバイスとネットワークがサポートしている場合は、高品質のメディア、複雑なアニメーション、または必須ではないスクリプトを追加できます。この小さい画像とビデオは低速接続で表示されます。それはアニメーションが減り、より低いハードウェアでの計算が安くなる可能性があります。 [web.dev](https://web.dev/articles/adaptive-loading-cds-2019)### 接続不良のサポート

ネットワークが安定していません。ユーザーは、Wi-Fi とモバイル データの間で切り替えたり、エレベーター内で接続が切れたり、帯域幅が十分であるように見えても遅延が長くなったりする可能性があります。優れた UX の理由は次のとおりです。

- クリアなロード、オフライン、および再試行のステータスを表示する必要があります。
- エラーが発生した場合にユーザー入力を保存します。
- 基礎となるアセットを適切な場所にキャッシュする必要があります。
- 安全なアクションをキューに入れて後で同期できるようにする必要があります。
- 一時的なエラーの後にタスク全体の再起動を強制すべきではありません。
- アクションが成功したか、失敗したか、またはまだ保留中であるかを伝える必要があります。

割り込みを適切に処理するインターフェイスは、理想的な条件下でのみ、高速なインターフェイスよりも信頼性が高く感じられます。

### 実際の状況をテストする

パフォーマンス テストには、実際のローエンド デバイス、さまざまなブラウザ、小さな画面、CPU スロットリング、およびシミュレートされた低速または不安定なネットワークを含める必要があります。フィールドテストと管理テストの両方でコアウェブバイタルを測定します。結果をデバイス クラス、接続タイプ、地理、主要な移動ごとにセグメント化します。

標準的な「私のマシンで動作しますか?」そうではない。それは、「一般的なデバイスを使用し、接続が難しいユーザーは、重要なタスクを見て、理解し、完了できるか?」ということです。パフォーマンス製品とは、ハードウェアの品質やネットワーク速度を使用可能なエクスペリエンスの前提条件としない製品です。

## パフォーマンス第一の設計

パフォーマンス第一の設計速度、応答性、安定性は、発売後に修正すべき技術的な問題ではありません。はそれを最初から製品要件として考慮します。デザイナーやエンジニアは、各ビジュアル、インタラクション、機能がユーザーの時間、注意力、バッテリー、データ、デバイス リソースに与える影響を考慮するよう求められます。

### コアエクスペリエンスから始めるまず、ユーザーの主な目標を特定し、そこに至る最短の信頼できるパスを設計します。

- 最も重要なコンテンツを最初に表示します。
- 主要なアクションをできるだけ早く利用できるようにします。
- コアコンテンツと競合する装飾アイテムを削除します。
- 高度な機能は必要になるまで延期します。
- 段階的な開示を使用して、初期画面をシンプルに保ちます。
- 便利なブランク、ロード、エラー、オフライン状態を設計します。

使いやすくなるまでに時間がかかりすぎる美しいインターフェースは、成功したデザインとは言えません。プライマリ画面は、セカンダリ コンテンツが読み込まれ続けている間でも、すぐに価値を提供する必要があります。

### 責任を持って視覚的な選択をする

設計上の決定はパフォーマンスに直接影響します。大きなヒーロー ビデオ、最適化されていない画像、カスタム フォント、複雑な影、過剰なアニメーション、サードパーティのウィジェットにより、ダウンロード サイズ、レンダリング作業、およびインタラクション ラグが増加する可能性があります。

適切なサイズの応答性の高い画像、軽量のアセット、抑制されたアニメーション、プログレッシブ レンダリング可能なコンポーネントを選択します。

### 知覚されるパフォーマンスを考慮した設計

ユーザーはスピードだけでなくフィードバックも必要としています。応答性の高いインターフェイス:

- 入力をすぐに確認する必要があります。
- 新しいコンテンツの読み込み中に画面が保護されました。
- ページ構造がわかっている場合は、スケルトンを使用する必要があります。
- 進行状況インジケーターは、長時間にわたる操作で使用する必要があります。
- 視覚的な動きを防ぐために、レイアウトの寸法を一定に保つ必要があります。
- エラーを説明し、回復アクションを提供します。

フィードバックは正直である必要があります。読み込みアニメーションでスタックしたリクエストを隠してはいけません。スケルトンは、それが表すコンテンツに似ている必要があり、誤った期待を抱かせてはなりません。

### プロセスにパフォーマンスを組み込む

パフォーマンス第一の設計は、一般的なワークフローとして最適に機能します。

1. ページの重さ、読み込み、応答性、安定性のパフォーマンス バジェットを定義します。2. 設計レビューに低速のデバイスとネットワークを含めます。
3. 理想的な最終画面だけではありません。プロトタイプのロード、エラー、および遷移状態。
4. 研究室および現場の条件で現実的なユーザー ジャーニーをテストします。
5. 公開後の Core Web Vitals とタスクの結果を監視します。
6. 新しい機能が利用可能な予算を消費する場合は、設計を再検討します。

中心となる原則はシンプルです。**理想的なプロトタイプに現れるものだけではありません。ユーザーが実際に受け取ることができるエクスペリエンスをデザインします。**

## レールモデル

RAIL は、Web パフォーマンスを単一ページの読み込み数ではなく定義します。これは、ユーザーの一連のアクションの観点から考えるためのユーザー中心のフレームワークです。エクスペリエンスを **応答、アニメーション、アイドル、ロード** に分割します。これは、人々が遅延をどのように認識するかに基づいて、各コンテキストに実用的な目標を与えます。 [web.dev](https://web.dev/articles/rail)

|原則 |ユーザーエクスペリエンス |実践目標 |
|---|---|---|
| **応答** |クリック、タップ、入力、その他の入力を確認します | 100 ミリ秒以内に返信 |
| **アニメーション** |スワイプ、ドラッグ、トランジションを滑らかに保ちます |各フレームは約 16 ミリ秒で生成されます。
| **アイドル** |今後のインタラクションをブロックせずにバックグラウンド時間を使用する |理想的には 50 ミリ秒未満で小さな単位で作業します。
| **ロード** |有用なコンテンツとエンゲージメントをすぐに利用できるようにする |インタラクティブなコンテンツを約 5 秒で読み込みます |

###応答

ユーザーがボタンをクリックすると、完全なプロセスに時間がかかる場合でも、インターフェイスはほぼ即座にアクションを確認する必要があります。最初の応答は、押された状態、スピナー、オプティミスティック アップデート、またはナビゲーション トグルです。その目的は、入力が受信されたことを保証することです。長い JavaScript タスクはメインスレッドをブロックし、このフィードバックを遅らせる可能性があります。高価な作業をより小さな部分に分割すると、ブラウザーはより頻繁にユーザーに制御を戻すことができます。 [MDN](https://developer.mozilla.org/en-US/docs/Glossary/RAIL)

### アニメーション

スワイプ、ドラッグ、トランジションは継続的な操作です。レンダリングでフレームが欠落すると、動きがぎくしゃくしてしまいます。インターフェースは洗練されておらず、制御が難しいと感じます。

従来の RAIL ターゲットは、60 fps でフレームあたり約 16 ミリ秒です。実際には、チームは、動きが状況の理解やコンテンツの操作に役立つ流動性を優先する必要があります。処理能力を消費する不必要なアニメーションは避ける必要があります。

### アイドル状態

空き時間は、可能性のあるコンテンツのプリロード、遅延データの解析、または重要ではないコンポーネントの初期化など、将来のインタラクションに備える機会です。ただし、バックグラウンド ジョブは割り込み可能な状態にしておく必要があります。メインスレッドを独占するタスクにより、ユーザーがページを操作するとすぐにページが遅く感じられます。

RAIL では、インタラクションを優先できるように、空白の作業を短い単位に分割することを推奨しています。これは、同じ計算に時間がかかる低電力デバイスでは特に重要です。 [web.dev](https://web.dev/articles/rail)

###ロード

ダウンロードは、ブラウザが各リソースをダウンロードするだけでは終了しません。意味のある目標は、有用なコンテンツを表示し、視覚的な安定性を確立し、主要なインタラクションをできるだけ早く利用できるようにすることです。

したがって、RAIL ベースの読み込み戦略では、次のことが優先されます。

- 重要なコンテンツとスタイル。
- 意味深な初登場。
- 基本的なインタラクション コード。
- 安定したレイアウトサイズ。
- すぐには必要ない画像、スクリプト、機能が遅延します。

### 今日の RAIL の使用RAIL は、最新のメトリクスに代わるものではない計画および優先順位付けモデルとして最もよく理解されています。これを Core Web Vitals、フィールド データ、タスクの結果と組み合わせて、どの遅延がユーザーにとって最も重要かを確認します。

たとえば、製品チームは、ランディング ページの読み込みは許容範囲内であるが、検索フィルターに 600 ミリ秒かかることに気づく場合があります。 RAIL は、摩擦の本当の原因は初期荷重だけではないため、その相互作用に注意を向けます。が答えです。中心原則は次のとおりです。**ユーザーが行動し、待機し、何が起こっているのかを把握する瞬間を最適化する**。

## パフォーマンスをゼロから設計する

パフォーマンスは、起動後のクリーンアップ タスクとしてではなく、製品の基盤に組み込む場合に最も簡単に実現されます。コンテンツ、レイアウト、ビジュアル、フォント、JavaScript、API、およびアーキテクチャに関する早期の決定により、エクスペリエンスがどれだけ早く役立つか、および実際のデバイスでの応答性が決まります。

### 早めに目標を設定する

詳細な画面を作成する前に、最も重要なユーザー ジャーニーにとって「十分な速度」が何を意味するかを定義します。

- 意味のあるコンテンツはいつ表示されるべきですか?
- ユーザーはいつ対話できるようにすべきですか?
- 主要なアクションはどれくらい早く反応する必要がありますか?
- 注文の変動はどの程度まで許容されますか?
- どのようなデバイスとネットワーク条件をサポートする必要がありますか?

これらの回答を、ページの重さ、画像サイズ、JavaScript、フォント、サードパーティのコード、読み込み時間、およびインタラクションの遅延に関するパフォーマンスの予算に変換します。予算により、パフォーマンスは開発者だけの問題ではなく、一般的な設計上の制約になります。

### 影響力の高い選択を最初に行う

多くの場合、最大の利益は実装前に行われた決定から得られます。

- 装飾的なメディアよりも重要なコンテンツを優先します。
- 二次機能の前にクリティカル パスを設計します。- レスポンシブな画像と適切なサイズのアセットを選択します。
- カスタム フォントとサードパーティ スクリプトの依存関係を軽減します。
- コンテンツのロード中にレイアウトを安定させます。
- 高度な機能にはプログレッシブ拡張機能を使用します。
- 不必要なネットワーク要求を必要とする対話を避けてください。

一般に、小さく焦点を絞ったインターフェイスは、最適化が必要になる機能が多いインターフェイスよりも高速化が簡単です。

### 実際のエクスペリエンスのプロトタイプを作成する

静的デザイン ファイルは最終状態を表します。ただし、待機、部分ロード、障害、または回復を示すものではありません。プロトタイプには以下を含める必要があります。

- 初期読み込みが遅い。
- API 応答の遅延。
- 空およびスケルトン状態。
- 進行状況インジケーター。
- オフラインまたは切断された接続。
- エラーと再試行の動作。
- ローエンドデバイスの制限。
- キーボード、タッチ、アクセシビリティのインタラクション。

これにより、パフォーマンス関連の UX の問題が発生しますが、依然として安価に置き換えることができます。

### 常に測定する

設計レビュー、プロトタイプ、プルリクエスト、リリース候補、実稼働など、あらゆる段階でパフォーマンスをテストします。ラボを使用して問題を再現し、フィールドを使用して実際のユーザーを理解し、タスクの完了、放棄、満足度などの製品メトリクスを使用して、技術的な改善が機能していることを確認します。

指針となる原則は、**パフォーマンスを左に動かす**です。つまり、コードを作成する前に重要なパフォーマンスに関する決定を下し、予算とテストで保護し、完成した機能の定義の一部とみなします。高速な製品は、単一の最終最適化パスでは作成されません。それは、最初から行われた何百もの小さな決定によって形作られます。

## 最も混同されやすい組み合わせ```text
❌ Performans UX’ten ayrıdır
✓ Performans, UX’in en görünür boyutlarından biridir

❌ Yeşil Core Web Vitals panosu ürünün iyi hissettirdiği anlamına gelir
✓ Metrikler gerçek sürtünme ve görev sonuçlarını temsil ettiğinde işe yarar

❌ Bekleme yalnızca saat süresidir
✓ Algılanan bekleme; geri bildirim, kesinlik ve kontrolle şekillenir

❌ Geliştirici laptopunda hızlı olmak “yeterince hızlı”dır
✓ Kapsayıcı performans sıradan cihazlar ve zor ağlardan başlar

❌ Lansmandan sonra optimize edin
✓ Performansı sola kaydırın: bütçe, prototip ve “bitti” tanımı ilk günden

チェックリスト: パフォーマンスを製品の UX として扱う

1. 最も価値の高い 5 つのジャーニーをリストします (マーケットプレイス: 検索、製品の詳細、カートに追加、チェックアウト、アカウントの回復)。
2. 旅ごとに、空白の画面、静かなタッチ、レイアウトのバウンス、繰り返しのクリックなど、「壊れた」感覚を平易な言葉で書き留めます。
3. 意味のあるコンテンツ、インタラクションの準備、応答の待ち時間、レイアウトの安定性に関する目標を設定します。
4. 理想的な画面だけではありません。スタンバイ、エラー、オフライン、リカバリーの状態を設計します。
5. Core Web Vitals (フィールド + ラボ) をタスクの成功、在職期間、失敗、放棄、満足度にマッピングします。
6. リリースが「完了」したとみなされる前に、移行する必要がある主要なデバイスとネットワークを特定します。
7. RAIL レンズを適用します。応答、アニメーション、アイドル、またはロードに最も影響を与える遅延はどれですか?
8. 答えを、設計とエンジニアリングが共同で所有するパフォーマンス予算に変換します。

これら 8 つの質問に答えられないとしても、パフォーマンスは依然として後回しです。これは製品要件ではありません。

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

1. パフォーマンスは UX です。ユーザーは、外観、応答性、安定性、流動性など、長期にわたって製品を体験します。
2. 遅さは信頼、転換、保持、感情的エネルギーを犠牲にします。最初の待ち時間が第一印象です。
3. 多くの場合、客観的な秒数よりも、知覚される待ち時間の方が重要です。フィードバック、進捗、制御を設計して、避けられない遅延を発生させます。
4. システムのパフォーマンスとユーザーの結果を一緒に測定します。ページバニティスコアよりもジャーニーを選択してください。
5. 包括的でパフォーマンス第一の設計は、ベース デバイス、不完全なネットワーク、初期の予算から始まります。
6. RAIL はユーザーの行動と待機時間に注意を払い続けます。 Core Web Vitals は、このストーリーの一部をデジタル化しています。

目標はボードを緑色にすることではありません。目標は、ユーザーが重要なタスクを迅速かつ安全に、不必要な労力をかけずに完了できるようにすることです。

次に、ユーザーが感じていることとツールが測定していることを分離します。これにより、指標は単なる見栄えシートではなく、意思決定ツールになります。