Last week, we introduced a popular new feature in HowFast called “split time”. You can now see a more detailed view of your backend response time, with the portion of time spent in DNS resolution, TCP connection, TLS handshake, request send, waiting for the first byte of data from your server, response download, and optionally time spent following redirects.

Twitter response’s split time: we can see that Twitter’s backend takes a constant time to respond (“wait”), but DNS queries are doubling the total response time every now and then. Increasing the DNS records TTL can reduce the frequency of these peaks — their current TTL is 30min.

This split time is available for the last 60 minutes (with a probe every minute) to see the recent evolution, and also over the last 7 days to see the averaged evolution.

It is now very easy to just focus on the backend response time (“wait”) and measure the performance impact of your last commit.

Let’s see how each portion of the response time is measured:

DNS resolution time

This is the time spent resolving the domain name of your URL. Long story short, the goal is to transform into the IP address 2001:bc8:4400:2100::20:20d (or for those without access to the IPv6 world).

We do a DNS resolution for each request sent to the monitored URL. While a classic browser/OS will cache the record locally, we chose to query it each time.

Also, we recently switched to a local resolver, instead of using our provider’s resolver. A cached record now only takes a few milliseconds to be retrieved, while an expired record will still need a bit more.

TCP & TLS connection

This is the time spent sending the very first packet to your backend, at the IP address returned by the DNS resolution process. It usually depends on three factors:

  • the processing power of the client,
  • the distance between the client (the HowFast worker) and the target (your backend), and the “network conditions”,
  • the processing power of the backend or load balancer, if applicable.
With HowFast, you can see how much time TLS handshakes actually take (not much).

Please also note that we are starting a brand new TLS connection for every probe. With “usual” HTTP clients, the TLS handshakes is only performed once for the first request (as well as the DNS resolution, and TCP connection), and the same TCP+TLS connection is reused for subsequent requests.

If this number is high, this may be linked to:

  • a low processing power on the client
  • a congested network or a long distance between the client and the target
  • a low processing power on the load balancer / backend.

This split time feature is an amazing tool to investigate performance issues:

What is causing these periodic peaks? HowFast will show you!

If you are not already using HowFast, you can sign up for free on and start tracking in seconds! Besides this split time feature, you will also benefit from 1-minute interval downtime checks with Slack/email notifications, unlimited monitors, performance analysis, and much more. For free.

Let us know what you think of this new feature!