WebページやAPIが遅い場合、その原因をどのように特定しますか？

Question

Accepted Answer

**推測せず、まず計測します。** 遅さはクライアント、ネットワーク、サーバー、またはデータベースから発生する可能性があります。体系的なアプローチにより、時間がどこに費やされているかを特定し、ランダムに最適化するのではなく、**最大の貢献要因**を修正します。

## 体系的なシーケンス

```text
1. MEASURE → where is the time spent? client render, network, server, DB?
2. REPRODUCE → confirm it reliably (same endpoint, payload, user)
3. TRACE → use APM/distributed traces to find the slow span
4. CHECK RECENT CHANGES → deploys, config, traffic, data growth
5. ISOLATE → layer by layer, narrow to one component
6. FIX the biggest contributor → re-measure to confirm
```

## 計測してまず確認：時間はどこに？

ブラウザの**Network/Performance**タブとサーバの**timing**を使用して合計を分割します。有用な内訳：

```text
Total 1200ms =
  DNS/connect      20ms
  server TTFB     900ms   ← the bottleneck is server-side
  download         80ms
  client render   200ms
```

**平均値ではなくパーセンタイルに注目してください**：**p50**（典型的なユーザー）対**p99**（最悪のケース）。高速なp50で遅いp99がある場合は、ロック競合、冷たいキャッシュ、遅いDBレプリカ、またはGC一時停止など、均一な問題ではなく散発的な問題を示しています。

## 遅いスパンをトレース

APMツール（トレース）はリクエスト内で時間がどこに費やされているかを正確に表示します：

```text
GET /orders                       950ms
  ├─ auth check                    10ms
  ├─ SELECT orders                 30ms
  └─ loop: SELECT user per order  900ms   ← N+1 query, the real cause
```

トレースは問題のある呼び出しを直接指します。その後、**最近の変更**を確認してください — デプロイ、欠落しているインデックス、またはデータ量の10倍の増加がよく突然の回帰を説明します。

## なぜ重要なのか

推測は間違ったレイヤーを最適化するのに何時間も無駄にします。まず計測し、遅いスパンをトレース して、**p50対p99**を見ることで、曖昧な「遅い」を具体的で修正可能な原因に変え、再計測により修正が実際に機能したことを証明します。