パフォーマンスプロファイリング
測定、分析、最適化。この順番で行いましょう。
🔧 実行スクリプト
自動プロファイリングを行うには、以下を実行してください:
| スクリプト | 目的 | 使用方法 |
|---|
scripts/lighthouse_audit.py | Lighthouse パフォーマンス監査 | python scripts/lighthouse_audit.py https://example.com |
1. Core Web Vitals
目標値
| 指標 | 良好 | 不良 | 測定対象 |
|---|
| LCP | < 2.5s | > 4.0s | 読み込み |
| INP | < 200ms | > 500ms | インタラクティブ性 |
| CLS | < 0.1 | > 0.25 | 安定性 |
測定のタイミング
| ステージ | ツール |
|---|
| 開発 | ローカルの Lighthouse |
| CI/CD | Lighthouse CI |
| 本番環境 | RUM（Real User Monitoring） |
2. プロファイリングのワークフロー
4 ステップのプロセス
1. BASELINE → Measure current state
2. IDENTIFY → Find the bottleneck
3. FIX → Make targeted change
4. VALIDATE → Confirm improvement
プロファイリングツールの選択
| 問題 | ツール |
|---|
| ページの読み込み | Lighthouse |
| バンドルサイズ | バンドルアナライザー |
| ランタイム | DevTools Performance |
| メモリ | DevTools Memory |
| ネットワーク | DevTools Network |
3. バンドル分析
確認すべきポイント
| 問題 | 兆候 |
|---|
| 大きな依存関係 | バンドルの上位に出現 |
| 重複したコード | 複数のチャンク |
| 未使用のコード | カバレッジが低い |
| 分割の不足 | 単一の大きなチャンク |
最適化のアクション
| 発見事項 | アクション |
|---|
| 大きなライブラリ | 特定のモジュールだけをインポートする |
| 重複した依存関係 | 重複を解消し、バージョンを更新する |
| メインに含まれるルート | コード分割を行う |
| 未使用のエクスポート | ツリーシェイキングを行う |
4. ランタイムプロファイリング
Performance タブの分析
| パターン | 意味 |
|---|
| 長いタスク（>50ms） | UI のブロッキング |
| 多数の小さなタスク | バッチ処理の余地がある可能性 |
| レイアウト/ペイント | レンダリングのボトルネック |
| Script | JavaScript の実行 |
Memory タブの分析
| パターン | 意味 |
|---|
| ヒープの増加 | メモリリークの可能性 |
| 大量の保持 | 参照を確認する |
| デタッチされた DOM | クリーンアップされていない |
5. よくあるボトルネック
症状別
| 症状 | 考えられる原因 |
|---|
| 初回読み込みが遅い | 大きな JS、レンダリングのブロッキング |
| 操作が遅い | 重いイベントハンドラー |
| スクロール時のカクつき | レイアウトのスラッシング |
| メモリの増加 | リーク、保持された参照 |
6. 即効性の高い改善の優先順位
| 優先度 | アクション | 効果 |
|---|
| 1 | 圧縮を有効にする | 高 |
| 2 | 画像の遅延読み込み | 高 |
| 3 | ルートごとのコード分割 | 高 |
| 4 | 静的アセットのキャッシュ | 中 |
| 5 | 画像の最適化 | 中 |
7. アンチパターン
| ❌ 避けるべきこと | ✅ 推奨 |
|---|
| 推測で問題を特定する | 先にプロファイリングする |
| 細部の最適化に注力する | 最も大きな問題を修正する |
| 早すぎる最適化 | 必要になったときに最適化する |
| 実際のユーザーを無視する | RUM のデータを使用する |
ご注意: 最も速いコードは、実行されないコードです。最適化の前に削除しましょう。
