ios-perceived-performance

iOS の体感パフォーマンス

目的

このスキルは、実際の処理時間が変わらなくても、iOS の画面やフローがユーザーにとって応答性よく感じられるかを確認するために使用します。

このスキルでは、ユーザーに見えるフィードバック、読み込み動作、段階的なコンテンツ表示、画面の安定性、楽観的 UI、重大な影響を伴う操作、体感応答性の検証に焦点を当てます。

このスキルを使用する場面

次のようなタスクを扱う場合に使用してください。

• 遅い、停止している、何も表示されない、画面が跳ねる、または応答しないと感じる画面
• タップやジェスチャーの後に、目に見えるフィードバックがない
• 意味のあるコンテンツが初めて表示されるまでに時間がかかる
• 読み込み状態、プレースホルダー、スケルトン、空状態、再試行状態、更新状態
• 段階的なレンダリング、一部のコンテンツ表示、セクション単位の読み込み、または古いデータを表示しながら更新する UI
• 楽観的更新、保留中の状態、ロールバック、再試行、ローカルとサーバーの整合性確認
• 重大な影響を伴う、取り消し不能な、破壊的な、金銭、法律、医療、本人確認、またはセキュリティに関わる操作
• 非同期処理中の重複送信や連続タップ
• 生の処理時間と同じくらい、プロダクトの動作も重要となる体感遅延のトレードオフ
• 録画、UI テスト、Instruments、MetricKit、本番ログ、またはユーザーに見えるシグナルを用いた検証

このスキルを使用しない場面

次の用途には使用しないでください。

• CPU、メモリ割り当て、ARC、メモリ、ランタイム、またはコンパイラーのパフォーマンスに関する低レベルの調査
• 問題が体感応答性に関するものでない限り、SwiftUI の無効化、識別性、レイアウト、またはスクロールの問題
• タスクの動作が目に見える UI フィードバックや段階的な読み込みに影響しない限り、Swift Concurrency の内部動作
• ユーザーの視点で、最初に役立つ画面や最初の操作に関する問題でない限り、アプリの起動パフォーマンス
• 応答性、読み込み、またはフィードバックに関する懸念がないビジュアルデザインの変更依頼
• 実行時の証拠がない状態で、アプリの実行を必要とする主張

これらの領域が主な問題である場合は、ios-performance-profiling、swiftui-performance、swift-concurrency-performance、swift-runtime-performance、または ios-launch-performance を使用してください。

基本モデル

ユーザーが CPU のサンプル、ネットワークトレース、データベースの処理時間、非同期タスクのグラフを直接体験することはありません。

ユーザーが体験するのは、次のようなことです。

• アプリがすぐに反応するか
• 役立つコンテンツがいつ表示されるか
• 処理の進行状況が明確か
• 処理が続いている間、画面が安定しているか
• 失敗や再試行が理解しやすいか
• 保留中の処理を信頼できると感じるか
• 操作を誤って繰り返せてしまわないか
• サーバーが確定した結果について、UI が正確に伝えているか

低レベルの最適化を提案する前に、ユーザーに見える遅延や不確実性から考え始めてください。

エージェントの能力の境界

エージェントが通常、調査および改善できること：

• 読み込み済み、空、エラー、更新中、保留中、同期中、失敗などの状態に対する状態モデル
• 非同期処理が完了した後にのみ UI が変化するかどうか
• ユーザーの操作に対して、すぐに視覚的なフィードバックが返るかどうか
• 更新時に、役立つ既存のコンテンツを不必要に消去していないかどうか
• 副次的なコンテンツより先に、重要なコンテンツを画面に表示できるかどうか
• 楽観的更新に、保留中の状態、ロールバック、再試行、競合時の動作があるかどうか
• 重大な影響を伴う操作で、最終的な成功を表示する前に確認を待つかどうか
• 重複送信が防止されているかどうか

実行時の証拠がなければ、エージェントは提案はできますが、証明はできません。

• 画面の速度が十分に感じられるかどうか
• スケルトンによって体感が改善するかどうか
• 意図的な遅延が適切かどうか
• 低電力モードによって、パフォーマンスの余力の少なさが明らかになるかどうか
• 古いデバイスで許容できるパフォーマンスが得られるかどうか
• プロダクトのフローがユーザーにとって信頼できると感じられるかどうか

録画、トレース、テスト結果、プロファイリング出力、本番環境のシグナルなどの証拠をユーザーが提示していない限り、手動検証や実機検証を行ったと主張しないでください。

レビューのワークフロー

1. ユーザーに見える症状を特定します。反応がない、画面が空白になる、全データが揃うまで何も表示されない、更新が急に切り替わる、進行状況が分かりにくい、過度に楽観的な表示、送信の繰り返し、不信感などです。
2. その症状を引き起こす状態遷移を特定します。
3. 最初に有効な改善策が、プロダクト／UI のフィードバックなのか、低レベルのパフォーマンス改善なのかを判断します。
4. UI がユーザーの操作にすぐ応答しているかを確認します。
5. 重要なコンテンツを、二次的なコンテンツより先に表示できるかを確認します。
6. 更新時に、既存の有用なコンテンツを保持できるかを確認します。
7. 読み込み中、空の状態、エラー、再試行、更新中、保留中、同期済み、失敗の各状態が十分に区別されているかを確認します。
8. 楽観的 UI が安全で、取り消し可能で、誠実な表示かどうかを判断します。
9. 重大な結果を伴う操作では、明示的な進行状況の表示と、サーバーで確認された成功を、楽観的な最終状態より優先します。
10. ユーザーに見える応答性を改善する、最小限の変更を提案します。
11. コードから判断できることと、実行時の検証が必要なことを明示します。
12. ユーザー体験を反映する証拠を使った検証を推奨します。

判断ルール

• 操作後にユーザーが反応を確認できない場合は、操作そのものを最適化する前に、すぐにフィードバックを追加します。
• 処理中に画面が空白になる場合は、キャッシュ済みコンテンツ、プレースホルダー、スケルトン、段階的なレンダリングを検討します。
• 無関係なデータを待ってからでないと画面に何も表示されない場合は、セクションごとの読み込みや段階的なレンダリングを検討します。
• 更新によって有用なコンテンツが消える場合は、古いコンテンツが安全であれば保持し、更新中であることを示します。
• 読み込み中、空の状態、エラー、再試行がひとつの状態にまとめられている場合は、パフォーマンスを調整する前に状態を分けます。
• リスクが低く、取り消し可能な操作では、知覚される遅延の改善に楽観的 UI が役立つ場合があります。
• 操作が金銭、破壊的な変更、法律、医療、本人確認、セキュリティに関わる場合、取り消し不可能な場合、またはサーバーが最終的に決定する場合は、確認前に最終的な成功を表示しません。
• 重複送信が起こり得る場合は、保留中の状態、操作コントロールの無効化、冪等性、リクエスト追跡を追加します。
• 推奨事項がプロダクトへの信頼やユーザーの受け止め方に左右される場合は、証拠がない限り、プロダクト上の仮説として説明します。
• パフォーマンスに関する主張をコードから証明できない場合は、成功したと断言せず、検証計画を含めます。

注意点

• スケルトンやプレースホルダーを、実際の実行時間の改善として扱わないでください。
• エラーを、終わりのない読み込み状態の背後に隠さないでください。
• 重大な結果を伴う操作や、取り消し不可能な操作に対して、楽観的な成功表示を推奨しないでください。
• 人為的な遅延を、通常のパフォーマンス改善策として提案しないでください。
• 古いコンテンツが危険または誤解を招く場合を除き、更新中にコンテンツを消さないでください。
• 部分的なコンテンツがユーザーを混乱させる場合は、すべての画面を独立した読み込みセクションに分割しないでください。
• Low Power Mode が古いデバイスを再現すると主張しないでください。大まかな手動の負荷確認にのみ使用してください。
• 記録、トレース、メトリクス、テスト、またはユーザーに見える挙動による証拠なしに、「速く感じる」と言わないでください。
• 直近の問題がフィードバックの欠如や状態の分かりにくさである場合に、広範な低レベルの最適化を推奨しないでください。

証拠と検証

ユーザーが実際に体験する内容を反映する証拠を優先してください。

• 操作から最初のフィードバック、そして最初の有用なコンテンツが表示されるまでの画面録画
• タップから最初のフィードバックまでの時間
• 最初の有用なコンテンツが表示されるまでの時間
• 主要な操作が利用可能になるまでの時間
• 更新の繰り返し試行
• 低速ネットワークでのテスト
• 状態遷移を記録する UI テスト
• ハング、引っかかり、レイアウト、レンダリング、メインスレッドの処理を確認する Instruments のトレース
• MetricKit または Xcode Organizer の応答性データ
• 読み込み段階に関する本番環境のログ
• UI が固まる、空白になる、跳ねる、または誤解を招くと説明するユーザーの報告

証拠が不十分な場合は、慎重な表現を使ってください。

• 「これにより、空白画面が表示される時間が短くなるはずです。」
• 「これにより、ユーザーに早くフィードバックを返せます。」
• 「リリースビルドでの検証が必要です。」
• 「画面録画、Instruments のトレース、UI テスト、または本番環境のシグナルを使って検証してください。」

根拠のない断定は避けてください。

• 「これでパフォーマンスが改善します。」
• 「これで滑らかになりました。」
• 「ユーザーは速くなったと感じるでしょう。」
• 「古いデバイスでも問題なく動作します。」

参照先の案内

関連する場合にのみ、以下を読んでください。

• references/progressive-rendering.md — 画面に有用な UI が表示されるまで全データの読み込みを待つ場合、重要なコンテンツを先に表示できる場合、セクション単位の読み込みが必要な場合、または更新時に既存のコンテンツが消える場合に読みます。
• references/loading-states.md — タスクに読み込み、空、エラー、再試行、更新中、スケルトン、プレースホルダー、または進行状況の状態が含まれる場合に読みます。
• references/optimistic-updates.md — タスクに楽観的 UI、保留中の状態、ロールバック、再試行、競合処理、ローカルでの整合、またはサーバーとの同期が含まれる場合に読みます。
• references/high-stakes-actions.md — 操作が金銭、法律、破壊的処理、取り消し不能、医療、本人確認、セキュリティ上の機微、またはサーバーが正とする処理に関わる場合に読みます。
• references/validation-and-testing.md — 知覚される応答性、古いデバイスでの動作、低電力モードのシグナル、リリースビルドでの動作、画面録画、Instruments のトレース、MetricKit、または本番環境の証拠を使った検証方法についてタスクで尋ねられた場合に読みます。

出力に関する要件

画面またはフローをレビューする場合は、次のように回答してください。

## Finding

Describe the perceived performance issue.

## User impact

Explain what the user sees or feels: no feedback, blank screen, jumpy updates, delayed interaction, unclear progress, unsafe optimism, duplicate submission risk, or premature success.

## Evidence

Point to code, state model, flow behavior, trace, recording, metric, user report, or missing UI state.

## Recommended change

Suggest the smallest useful product/UI change first: immediate feedback, distinct loading state, progressive rendering, stale-while-refreshing content, optimistic update with rollback, explicit confirmation, duplicate-submission prevention, or validation.

## Implementation notes

Explain what can be changed in code and what depends on product, design, backend, or runtime evidence.

## Validation

State how to verify the improvement. Do not claim manual, device, or production validation was performed unless evidence is provided.

ボトルネックがフィードバックの不足、すべてを一度に描画すること、不明瞭な読み込み状態、安全でない楽観的な動作、または継続性の低さにある場合は、低レベルの最適化よりもユーザーに見える改善を優先してください。