mhページ表示が重い、スクロールがカクつく、JavaScriptが固まる…。
そういった問題を解決するには、パフォーマンスの可視化と分析が不可欠です。
Google Chromeの「Performance」パネルでは、レンダリング・スクリプト処理・レイアウト・ペイントなどの一連の流れを視覚的に確認できます。
この章では、実際のユースケースを通じて、ページのボトルネックを見つける手順を学びましょう。
7.1 メモリリークの検出
メモリリークとは、不要になったオブジェクトが解放されず、メモリを使い続けてしまう現象です。
長時間ページを開いていると重くなる、アニメーションが徐々に遅くなる…といった不具合の原因になり得ます。
Memory snapshot の使い方：
Memoryタブを開いて「Snapshot」を取得- GC（ガーベジコレクション）後にも消えないオブジェクトを調査
Retainersでどのオブジェクトが参照し続けているかを確認
💡 活用例：
- SPA（Single Page Application）で画面を切り替えても前のイベントリスナが残り続ける
- WebSocketのコールバックが解放されず蓄積する
7.2 タイムラインによるレンダリング確認
Performance タブで記録を開始すると、ページの描画処理全体のタイムラインが表示されます。
見るべきポイント：
Scripting：JavaScriptの実行時間Rendering：レイアウト・スタイル計算などの時間Painting：実際の画面描画処理Idle：空き時間
シナリオ：
- 「Record」ボタンをクリックして操作を再現（例：ページスクロール、ボタン押下）
- 処理が固まった瞬間をズームイン
- 長時間を占めている処理やレイアウト・リフローを特定
💡 ユースケース：
- 「スクロールが重い」→ リスト描画で毎回全 DOM を更新していた
- 「クリック後の応答が遅い」→ 重い同期処理がブロッキングしていた
7.3 スロットリング設定（CPU / ネットワーク制限）
リアルユーザーの環境では、開発マシンほど高速なCPUやネットワークは使われていません。
DevToolsでは「スロットリング機能」により、意図的にリソースを制限して動作を再現・確認できます。
設定方法：
PerformanceまたはNetworkパネルで、上部の「Throttling」オプションを選択- ネットワーク：
- No throttling（制限なし）
- Fast 3G / Slow 3G
- CPU：
- 2x slow-down / 4x slow-down（処理速度を落とす）
活用例：
- モバイル通信環境下でのページ初期表示速度を確認
- 高負荷ページでのCPUボトルネックを再現し、体感速度を測定
🧑💻 実践課題
課題：画像付き記事リストがスクロール時にカクつく問題を調査・改善する
Performanceパネルでスクロールを記録- 長い
ScriptingやRenderingの箇所を特定 - 画像の読み込みや DOM の再描画が原因か確認
- 遅延読み込み（lazy-loading）や
requestAnimationFrameの活用など改善案を検討
📝 まとめ
- Memoryパネル：メモリリークを特定し、パフォーマンス劣化の根本原因を発見
- Performanceタイムライン：スクリプト・レイアウト・描画の流れを可視化して、遅延の原因を分析
- スロットリング：ユーザー実環境を再現し、UXの劣化を未然に防ぐ
Performanceパネルは、見た目では分からない”重さ”の原因を科学的に突き止める道具です。
単に「遅い」を「速くする」ための最初の一歩として、定量的な視点を養いましょう。
