Test Time To First Bytes (TTFB) using Linux/Unix/Mac OS X Terminal

[CCarter]

To test time to first bytes when on a Linux, Unix, or Mac OS X operating system run the following command:

curl -s -w 'Testing Website Response Time for :%{url_effective}\n\nLookup Time:\t\t%{time_namelookup} seconds\nConnect Time:\t\t%{time_connect} seconds\nAppCon Time:\t\t%{time_appconnect} seconds\nRedirect Time:\t\t%{time_redirect} seconds\nPre-transfer Time:\t%{time_pretransfer} seconds\nStart-transfer Time:\t%{time_starttransfer} seconds\n\nTotal Time:\t\t%{time_total} seconds\n' -o /dev/null https://www.buildersociety.com/​

One-line version:

curl -s -w 'Testing Website Response Time for :%{url_effective}\n\nLookup Time:\t\t%{time_namelookup} seconds\nConnect Time:\t\t%{time_connect} seconds\nAppCon Time:\t\t%{time_appconnect} seconds\nRedirect Time:\t\t%{time_redirect} seconds\nPre-transfer Time:\t%{time_pretransfer} seconds\nStart-transfer Time:\t%{time_starttransfer} seconds\n\nTotal Time:\t\t%{time_total} seconds\n' -o /dev/null https://www.buildersociety.com/

It will give you the following output:

I'm not really confident in the hosting of BuSo IMO - coming in at 0.755 seconds, yikes. The 2nd and 3rd tests were better. Averaging the 3 is best. Explanation of the output:

--

Lookup Time: time, in seconds, it took from the start until the name resolving was completed.

Connect Time: time, in seconds, it took from the start until the TCP connect to the remote host (or proxy) was completed.

AppCon Time: time, in seconds, it took from the start until the SSL connect/handshake to the remote host was completed.

Redirect Time: time, in seconds, it took for all redirection steps including name lookup, connect, pretransfer and transfer before the final transaction was started; it computes the full execution time for multiple redirections.

Pre-transfer Time: time, in seconds, it took from the start until the file transfer was just about to begin.

Start-transfer Time: time, in seconds, it took from the start until the first byte was just about to be transferred.

Total Time: total time, in seconds, that the full operation lasted (millisecond resolution).

Credit: How to Test Website Loading Speed in Linux Terminal
--

It's a good idea to check the TTFB against the Top 10 competitors within the search results to see if you are in-line with them or not. Faster is always better - Especially on Mobile!

--

Important: When you use the Google PageSpeed Test (https://developers.google.com/speed/pagespeed/insights/) it gives an important output for Mobile called "First Contentful Paint" - that's important since that signals when a user starts seeing something/anything on the screen. This is why Google is always telling you to defer this and that stuff - so a user can see something/anything on the screen so they know things are happening.

Imagine your own scenario where you click a button and you have zero clue whether something is happening or not, what do you do? Click the button again. If nothing happens after 1-3 seconds you hit the back button or reload the page.

Something to really pay attention to is the time difference between the "Pre-Transfer Time" and the "Start-Transfer Time". That's your server's response to EACH user's HTTP request - every image, CSS file, HTML file, Javascript file - all of it. I've seen instances of where the pre-transfer time was at 0.28 yet the start transfer was 0.56 - literally double - that's insane because that's happening for EACH file being transferred. In those instances the experience of the user will see a very slow site when on non-WiFi mobile. Also - if you are coming in over 1 second - yikes!

I suggest doing this test for every page, not just your homepage, but every major pillar page and blogpost. You might notice something acting up on certain pages and should investigate.

 

[bernard]

How come TTFB changes?

When I did the first lookup it was 3 seconds, then less than 1 second for the same request?

 

[CCarter]

How come TTFB changes?

When I did the first lookup it was 3 seconds, then less than 1 second for the same request?

It will always vary. Perhaps something on your server was taking a bit longer or you had more traffic the first moment versus the next request.

This is sort of like asking Why is the line long at McDonalds today - it's going to depend on demand at that very moment. Your server might be hiccuping. That's why I run the test 3 times then get the average.

Also, consider that once you look up a domain the first time your ISP will cache the DNS information, making look-up faster for the next 24-48 hours. AND your computer will cache the nameserver and DNS information as well, making look-up even faster. So you'll notice the first time you look up something it takes a bit longer on the look-up, but subsequent requests are super faster - it's cause your computer, modem, ISP, or local internet node has cached the DNS data of the IP address and other stuff within it's system.

If you recall whenever you move a website you have to update the DNS - and there is a warning that it can take up to 72 hours to propagate around the world right? It's because there are systems in place that have the old cached location of your IP address in their system and can take up to 3 days to recheck it.

This is why a week before you move a website you should change the TTL (Time to Live) to 5 mins within your DNS/nameserver settings. That tells these caching systems "hey we are going to be moving soon, so don't save this data for more than 5 mins."