✅（パフォーマンス改善）アイテムが増えるとカウントアップ時の描画が重くなる
基素.icon履歴を全部送ってるからか？
Claude Sonnet 4.iconなるほど、「1クリックごとに売買履歴のlengthが50増える」なら、かなり強いシグナルです。原因は「更新のたびに“全ブック＋全履歴”を丸ごとWebSocketでブロードキャストしている」ことによる巨大フレーム化・送信過多の可能性が高いです。
送るデータはどんどん増える基素.icon
https://gyazo.com/3974de6b7ca5bb686d3b89b6fba1dea1
画像を設定していると50回ぐらいで重くなる？
んなことない
3つ以上になると遅くなる
スマホも発熱する
2つでも500ぐらいになるとおそくなりつつある
やはり何か計算を最適化する必要がありそうだ
なにが重いんだろう？
本を増やすと重い
https://gyazo.com/435158d94d5a16dfb55b246fdee4fa1d
メッセージを全部に送る、みたいなことをしてるんだろう
この時点では実装の詳細を基素.iconは知らない
チャートセクションをコメントアウトしたら速度が改善したのでチャートの描画が原因
Junie.iconGPT-5.icon現在の実装では SalesChartsSection に books={viewBooks} を直接渡しており、楽観更新のたびに viewBooks の参照が変わってチャートの再計算・再描画が毎回走ります。チャート側が履歴や集計を作り直す作りであれば、そのコストは「アイテム数 × 各アイテムの履歴長」にほぼ比例します。したがって、アイテム数を 9 に増やし、各 20 カウント程度（= 合計 180 レコード相当）でも、特にモバイルや省電力状態では操作時の“もっさり”が発生し得ます。
原因はこれじゃなかった基素.icon
GPT-5.icon根本的に「SVG描画コスト」が限界要因なので、Canvas系ライブラリ(Chart.js等)への移行が最も合理的。
Canvas描画で10-100倍高速Claude Sonnet 4.icon
SVGは必要なだけのDOMノードをメインスレッドで生成する。数百のSVG要素 → 1つのCanvas要素になる
DOM操作をしなくなるのでweb worker内で描画できる
code:jsx
const svg = document.createElement('svg'); // DOMアクセス不可
ReactDOM.render(<AreaChart />, container); // React DOM不可
https://gyazo.com/c070a5e25bdcd5739272e413acfbaa4fhttps://gyazo.com/5cfed3a3cc87ec999fc175b1b807985d
before もっさり / after サクサク
https://gyazo.com/6f443bdd2c254c22a39d203ab57fd3f8 https://gyazo.com/13d8e6ceee6160e554a94a033b26622c
before /after
＃107