An HTTP check on the client side is not a single operation — it's a chain of phases. The browser (or monitoring service) first resolves the domain into an IP, then establishes a TCP connection, then performs a TLS handshake for HTTPS, and only after all of that does it start waiting for the first byte of the response. Each phase takes its own time, and the overall "site speed" is their sum.
Tracker.ru measures all four phases for every HTTP check and shows them in the check log as a waterfall — a horizontal chart with colour-coded segments. This gives a direct answer to the question "why is the site slow": you can see exactly which phase is losing milliseconds.
Which phases the waterfall consists of
The full cycle from request to first byte in Tracker.ru is broken into four independently measured phases:
- DNS — resolving the domain to an IP address. The query goes to a DNS resolver (typically the local cache of an ISP or service), which returns the A/AAAA record. A warmed-up cache typically takes 5–30 ms; long resolution times (200+ ms) point to a problem with the authoritative NS, a geographically distant resolver, or TTL=0.
- Connect (TCP handshake) — the three-way SYN/SYN-ACK/ACK with the target server. Depends mostly on RTT (round-trip time) — physical distance and link quality. Moscow ↔ Moscow is usually 5–15 ms; Moscow ↔ Frankfurt is 30–60 ms; Moscow ↔ the United States is 130–200 ms.
- TLS (handshake) — the encrypted channel handshake, HTTPS only. Modern TLS 1.3 fits into 1 RTT, TLS 1.2 — into 2 RTT. A slow TLS handshake (300+ ms on a nearby server) suggests a heavy cipher suite, OCSP certificate checks, or cold sessions. For plain HTTP checks (not HTTPS) this phase is 0 — no handshake happens.
- TTFB (Time To First Byte) — the time from the end of the handshake to receiving the first byte of the response. This is the server-side processing: framework routing, database queries, template rendering, header assembly. The norm for static pages is 50–200 ms; for dynamic pages with DB queries — 200–600 ms; anything above 1 second usually requires backend profiling.
The sum of these four values is the total HTTP check duration (the response_time field in the log). If you have the home page open in a browser, after TTFB the body of the HTML still has to download, parse, fetch assets, render the DOM — but all of that is outside the server response, and Tracker.ru does not measure it: we focus on the server side, which you can actually control.
How to read the waterfall in Tracker.ru
In the check log every successful row contains the phase details. Hover over the row and a tooltip appears with the breakdown:
Total: 487 ms
├─ DNS: 12 ms
├─ Connect: 38 ms
├─ TLS: 74 ms
└─ TTFB: 363 ms
If you open a URL page and switch to the "Logs" tab, the same data is available as columns. For long ranges (7/30 days) it's easier to look at trends on the statistics page — there you can see which phase is creeping up over time.
In addition to the UI, the same values are available via the REST API: the GET /api/urls/{id}/logs endpoint returns the dns_time, connect_time, tls_time, and ttfb fields (in milliseconds) for every entry. This is useful if you export metrics into Grafana, Prometheus, or your own observability stack.
Why look at the waterfall
A single overall "response time" does not answer the question "what should I fix". The waterfall does.
"The site has become slower over the past month"
Open the 30-day response-time chart on the URL page. If the overall trend is creeping up, look further at the phases. TTFB rises while DNS/Connect/TLS stay stable — the problem is on the backend (DB load has grown, a slow query has appeared, the cache is not working). DNS rises — check the state of the authoritative NS and the TTL of the records. TLS rises — look at the cipher suite and whether OCSP must-staple is enabled without warm sessions. Connect rises while TTFB stays stable — routing or the network provider has changed.
"The site is intermittently slow"
Spikes in a single phase are a different class of problem. DNS spikes up to 1–2 seconds — the resolver periodically misses the cache and goes to the authoritative NS. TLS spikes — the server doesn't have enough CPU for cryptography (typical for cheap VPS). TTFB spikes — background jobs (cron, GC, backups) steal resources from the request handler.
Tracker.ru stores every check, so such spikes are visible on the detailed chart instead of being averaged out into an hourly mean.
"One region is slow, the others are not"
If you use multi-region monitoring — Moscow, Frankfurt, Almaty — every region has its own waterfall. This immediately separates two causes:
- TTFB is the same everywhere but Connect in one region has grown — the problem is in the network between that region and the server. The server doesn't need to be relieved; look at the provider or the intermediate hops.
- TTFB has grown everywhere by the same amount — on the contrary, server-side load. The network is not at fault.
"The site feels fast, but Google Search Console says it's slow"
Google uses TTFB as one of the Core Web Vitals signals (the INP metric partially correlates). If PageSpeed Insights shows "Reduce server response times" but you don't feel a slowdown in the browser, track TTFB specifically on regular checks. A 7-day average gives a more stable picture than one-off measurements from Google.
What to do with large values
| Phase | What a large value means | Where to look |
|---|---|---|
| DNS > 100 ms | Resolver missing or authoritative NS is far | DNS record TTL, NS geo-distance, switch to a faster DNS provider |
| Connect > 200 ms (nearby server) | Long network path or packet loss | traceroute, ISP, CDN/edge |
| TLS > 300 ms | Heavy cipher or OCSP without stapling | TLS 1.3, OCSP stapling, session reuse |
| TTFB > 1000 ms | Slow backend | Query profiling, DB slow query log, page cache |
These thresholds are reference points, not absolute rules. A primary-source site with complex analytics may legitimately have a TTFB of 800 ms; a static landing page with a TTFB of 400 ms is already suspicious.
Comparison with other services
Response-time breakdown by phase is not available in every monitoring service:
- Tracker.ru — all four phases (DNS / Connect / TLS / TTFB) for every check, available in the UI and via the API.
- UptimeRobot — shows only the overall response time, no breakdown.
- Pingdom — yes, a similar breakdown is available in synthetic monitoring.
- Better Stack (Better Uptime) — yes, in higher-tier plans.
- Healthchecks.io — no (it's a heartbeat service, not URL monitoring).
This is an important detail when choosing monitoring for production sites: without a phase breakdown, diagnosing a slow site turns into guesswork. A detailed comparison of Tracker.ru with competitors is available in the comparison section.
Where Tracker.ru stores the data
All four fields are saved in every entry in the check log:
dns_time— millisecondsconnect_time— millisecondstls_time— milliseconds (0 for HTTP without TLS)ttfb— milliseconds
If a phase didn't get a chance to run (for example, DNS failed to resolve — host_not_found), all subsequent fields stay at zero and the check status is marked as a failure with the corresponding error_status.
History is retained for the entire lifetime of the URL: you can review the waterfall of checks from yesterday, from a month ago, or compare two periods against each other.
Related articles
- /features/multi-region — monitoring from 3 regions: Moscow, Frankfurt, Almaty.
- /docs/features/screenshots — visual monitoring and pixel diff.
- /docs/features/keyword-check — checking for a keyword in the HTML response.
- /docs/notifications/webhooks — the webhook payload includes the
dns_time,connect_time,tls_time, andttfbfields. - /docs/features/maintenance-windows — maintenance windows: so that planned work doesn't distort waterfall trends.