react-scan

React Scan

測定対象の Studio インタラクションを、対象を絞ってキャプチャし、最適化します。ワークフローを再現できる場合は、ソースコードだけからパフォーマンスの問題を推測しないでください。

キャプチャを記録する

リポジトリのルートから開始します。

bun run react-scan:capture

Brand Studio の場合は、次を実行します。

bun run react-scan:capture:brand

Studio のビルドが完了するまで待ち、ブラウザーで表示された Studio の URL を開いて、ページが落ち着くまで待ちます。React Scan WebMCP ツールが登録されるのは、この開発用キャプチャモードのみです。

start_react_scan_recording を呼び出し、browser-use を使って名前を付けたインタラクションを 3 回実行します。その直後に stop_react_scan_recording を呼び出します。起動処理、HMR、無関係なインタラクションがデータを左右しないよう、記録は短く保ってください。get_react_scan_recording を呼び出すと、生イベントとエージェント向けの要約が返されます。

記録を取得したら、Ctrl+C で Studio を停止します。記録は WebMCP の結果にのみ保存されます。React Scan が別の HTTP コレクターに送信することはありません。

React Scan が有効な間は、React DevTools のプロファイリングフックのチャネルが置き換えられます。同時に React DevTools の Timeline Profiler で記録しないでください。

根拠を分析する

まず、get_react_scan_recording が返す summary を読みます。キャプチャにコミットイベントが含まれていることを確認し、profilingHooksStatuses を調べます。プロファイリングチャネルがないからといって、アプリケーションがアイドル状態だと解釈しないでください。

自己処理時間の合計が長いコンポーネント、コストの高いレンダーが繰り返されるコンポーネント、またはユーザーが明確に体感できるコミットの遅延を優先します。包括処理時間には子の処理が含まれ、サブツリーを二重にカウントすることがあるため、コストの高い境界を特定するために使用し、その後、自己処理時間と生のツリーを使って実際の処理を特定します。

レンダーの原因は根拠として使用し、自動的な処方箋とは見なさないでください。

• 関連するプロパティ、状態、コンテキスト、フックの変更がないのに parentRenderCount が多い場合は、安定したメモ化境界が必要であることを示唆しています。
• 変更されたプロパティが繰り返し見られる場合は、メモ化を追加する前に、発生元で参照の安定性を確認してください。
• フック、状態、コンテキストの変更がある場合は、更新を所有する箇所を追跡する必要があります。コンポーネントを memo() でラップしても、その更新は阻止できません。
• ソースの位置は JSX の呼び出し箇所を示します。編集する前に、コンポーネントの定義を検索してください。

タイムライン上の位置に関する調査結果については、サブスクリプションやメモ化境界を変更する前に、../studio-perf/SKILL.md も読んでください。

最適化を検証する

ベースラインのキャプチャは保持してください。コードを変更した後、同じビューポートで同じインタラクションを同じ回数記録し、新しいキャプチャと比較します。関連するコミット／コンポーネントのメトリクスが改善し、動作にリグレッションがないことを確認してください。あらゆる再レンダーを最適化しないでください。不要なメモ化の複雑さを加えるより、コストの低い必要なレンダーを許容するほうが望ましい場合がよくあります。

測定した変更前後の差と、動作を検証するために実施した確認事項を報告してください。