Webová stránka nebo API je pomalá — jak zjistíte příčinu?

Question

Accepted Answer

**Nehadejte — měřte nejdřív.** Pomalost může pocházet od klienta, sítě, serveru nebo databáze. Metodický přístup zjistí, *kam* čas jde, a pak opraví **největší přispěvatele** místo náhodné optimalizace.

## Metodická posloupnost

```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
```

## Měřte nejdřív: kam čas jde?

Použijte záložku **Network/Performance** v prohlížeči a server **timing** pro rozdělení součtu. Užitečný rozpis:

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

Podívejte se na **percentily, ne průměry**: **p50** (typický uživatel) vs **p99** (nejhorší případ). Rychlé p50 s pomalým p99 ukazuje na občasné problémy — tvrzení zámků, studené mezipaměti, pomalou DB repliku nebo GC pauzy — ne jednotný problém.

## Trasujte pomalý rozsah

Nástroje APM (traces) ukazují přesně, kam čas v požadavku jde:

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

Stopa ukazuje přímo na problematické volání. Pak zkontrolujte **nedávné změny** — nasazení, chybějící index nebo 10x nárůst dat často vysvětluje náhlý regres.

## Proč na tom záleží

Hádání mrhá hodinami optimalizací špatné vrstvy. Měření nejdřív, trasování pomalého rozsahu a pohled na **p50 vs p99** změní neurčitý "je to pomalé" na konkrétní, opravitelnou příčinu — a opětovné měření prokáže, že oprava skutečně fungovala.