Gadget 14：パフォーマンスチューニング

遅い・重い・遅延が大きいときの原因候補と優先度を整理

パフォーマンスチューニング

「遅い」「重い」の切り分けと優先度です。

目的

  • どこがボトルネックかを優先度つきで特定する
  • 先にやるべき「効果の大きい・手軽な対策」を知る

前提条件

手順（優先度つきの切り分け）

1. 「どこの遅さ」か分類する

分類 症状例 主因候補
起動時に遅い 初回表示まで数分 初回ビルド・依存解決
操作時に遅い クリック後の応答が遅い ネットワーク / リソース
全体的に重い CPU 高・ファンうるさい 常駐リソース不足（連続稼働）
特定機能だけ遅い ある Gadget だけ遅い その Gadget の作り / 外部 API

2. まず確認するコマンド

# リソース
top -o cpu | head
free -h          # Linux / コンテナ内
vm_stat          # macOS

# ポート・プロセスの確認
lsof -i :8787

3. 効果の大きい対策から順に

優先度 対策 効果
高 使っていない Gatekeeper / プロセスを止める 常駐負荷が減る
高 Node を 22 LTS に統一 依存・起動が安定化
高 初回ビルドを済ませてから常駐 初回だけ重い問題を解消
中 リソース増強 or Container 上限を設定 連続稼働で安定（15）
低 フロント dist を更新ビルド 静的配信が最新・軽量化
Tip先に「機能」で測る

一発で原因に当たるより、まず「起動時 / 操作時 / 全体」のどれかを切り分けましょう。 対象が狭まるだけで解決が速くなります。

4. 測定して記録する

time curl -s -o /dev/null http://localhost:8787   # 応答時間

実行前後の数値を記録し、対策効果を判定します。

よくある失敗

症状 原因 対処
測定せず対策し続ける 効果確認が無い 指標（応答秒）を固定して比較
常駐が全体的に重い リソース不足 上限設定 or 複数クラスタ
初回だけ極端に遅い 未ビルド 常駐前に build を済ませる
特定機能だけ遅い 外部 API の遅延 連携先の制限・API 遅延を確認

確認

次に読む