⏱️ E4 · Timing Tab: TTFB, Waiting, Download

E4 · Timing Tab: TTFB, Waiting, Download: The Timing tab is like a **package tracking page**: a single number saying a request "took 2.9 seconds" TELLS YOU NOTHING, but like pack

The Timing tab is like a **package tracking page**: a single number saying a request "took 2.9 seconds" TELLS YOU NOTHING, but like package tracking, if you split the time into phases ("waited in the warehouse", "was in transit", "delivered to the door") you see EXACTLY where the delay is. `TTFB` (Time To First Byte) = how long the server took to send its first byte, `Waiting` = how long the server took to PROCESS the request (usually the biggest slice), `Content Download` = how long the response data took to DOWNLOAD. So why does this split matter so much — isn't "3 seconds slow" enough to say? Because the fix is COMPLETELY different: if `Waiting` is large the culprit is the SERVER (a slow SQL query, an N+1 problem — escalate to the developer); if `Content Download` is large the culprit is DATA SIZE/NETWORK (an unnecessarily huge JSON, missing compression). The Java equivalent is manual profiling with `System.currentTimeMillis()` inside a method — but there YOU measure the segments by hand, in the browser the Timing tab does it automatically FOR you. For QA, a "slow" performance bug report is nearly worthless without Timing data — when a developer asks "which layer is slow?", answering "I don't know, it was generally slow" gets the report bounced back.

A Request's Three Phases

The horizontal bar in the Timing tab splits a request's duration into colored slices. `TTFB` is usually small (the server saying "got it" is fast); `Waiting` is the time the request is REALLY being processed — a database query, an external service call, or a bad algorithm can eat time here; `Content Download` is how long a large response body (e.g. thousands of bug records) takes to download.

Timing Bar — TTFB / Waiting / Content Download

🎬 A 3-Second Delay: Network or Server?

A request takes 2.9 seconds total — alone, this number tells the tester nothing.

The Timing tab splits the duration into three. `TTFB` is only 0.1s — reaching the server and getting the first byte is fast.

`Waiting` is 2.7s — almost the entire total duration is here. The server spends time processing the request (a query, a calculation).

`Content Download` is only 0.1s — the response data is small, download is fast. Network/data size is NOT the culprit.

The lesson — 2.7s of 2.9s belongs to Waiting: the delay is in the SERVER, not the NETWORK. The bug report should not say "generally slow" but "2.7s in the Waiting phase, likely N+1/slow query".

The Order for Diagnosing the Cause of Slowness

If large, even reaching the server/first response is delayed (network/DNS/server load).

If large, the server is slow while PROCESSING — a query/calculation is suspect, escalate to the developer.

Check Content Download…