Web stranica ili API je spora — kako pronalazite uzrok?

Question

Accepted Answer

**Nemojte pogađati — prvo mjerite.** Sporost može dolaziti od klijenta, mreže, servera ili baze podataka. Metodičan pristup pronalazi *gdje* vrijeme odlazi, zatim ispravlja **najvećeg doprinositelja** umjesto nasumične optimizacije.

## Metodička sekvenca

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

## Prvo mjerite: gdje je vrijeme?

Koristite **Network/Performance** tab preglednika i server **timing** kako biste podijelili ukupno vrijeme. Koristan pregled:

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

Gledajte **percentile, ne prosjeke**: **p50** (tipičan korisnik) naspram **p99** (najgori slučaj). Brz p50 sa sporom p99 pokazuje povremene probleme — Lock contention, hladne cachea, sporu DB repiku ili GC pauzama — ne na uniforman problem.

## Pratite sporu aplikaciju

APM alati (traces) pokazuju točno gdje vrijeme odlazi unutar zahtjeva:

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

Trace vas vodi izravno na problematski poziv. Zatim provjerite **nedavne promjene** — deploy, nedostajući indeks ili 10x rast podataka često objašnjava iznenadnu regresiju.

## Zašto je to važno

Pogađanje troši sate optimiziranja krivo sloja. Prvo mjerenje, praćenje spore aplikacije i gledanje **p50 naspram p99** pretvara vagu "to je spora" u specifičan, ispravljiv uzrok — i ponovno mjerenje dokazuje da je ispravka zaista radila.