【要約】[Frontend Performance - Part 9] JavaScript は速いのに、なぜ React は遅いのか？再レンダリングを理解する [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
フロントエンドエンジニアは、JSが高速でもReactアプリで入力遅延やカクつきに直面することがある。これは、Reactのデフォルト動作である「親の更新が子へ連鎖する」仕組みが原因である。具体的には以下の問題が発生する。
- ・State、親の更新、Contextの変更により再レンダリングが誘発される。
- ・大規模なツリーでは、連鎖的な再計算が16msのフレーム枠を超える。
- ・結果として、ユーザー体験を損なう描画遅延（Jank）を引き起こす。
// Approach
開発者は、再レンダリングのコストを最小化するため、まず現状を可視化し、設計レベルの最適化を段階的に進める。具体的な手法は以下の通りである。
- ・React DevToolsやwhy-did-you-renderを用いて、不要な更新を特定する。
- ・Stateを可能な限り使用コンポーネントの近くへ移動（局所化）する。
- ・childrenパターンやコンポーネント分割により、更新の影響範囲を限定する。
- ・最終手段として、React.memoやuseMemoによるメモ化を適用する。
// Result
適切な設計変更とメモ化の適用により、アプリケーションの応答性が劇的に改善される。Todoリストの例では、以下の成果が得られた。
- ・Stateの配置を見直し、入力時の不要な連鎖を遮断した。
- ・React.memoとuseMemoを使い分け、必要な箇所のみを再描画させた。
- ・これにより、大規模なリスト操作でもブラウザのフレームレートを維持できる。
Senior Engineer Insight
> 現場では、安易なメモ化が技術負債を招く。useCallback等の多用は、比較コストの増大とコードの複雑化を招くからだ。真の最適化は、メモ化ではなく「Stateの配置」という設計段階で決まる。大規模開発では、コンポーネントの責務を明確にし、更新の影響範囲を最小化するアーキテクチャ設計が、スケーラビリティと保守性の両立に不可欠である。