Having some difficulty with TTFB

Hello,

I have some difficulty sorting out TTFB metrics. According to Webpagetest’s glossary, First Byte Time is defined as “The target time is the time needed for the DNS, socket and SSL negotiations + 100ms. A single letter grade will be deducted for every 100ms beyond the target.”

In the tests though what is included in the TTFB result, includes not only the above but also the entire process of the initial DB queries, html output, gzip compression and sending all that to the visitor.
In the Waterfall View, I see the initial dns/ssl negotiaions PLUS the compressed html reaching the visitor measured as TTFB.

Is there something I don’t understand here?

1 Like

Hi Astron

The Time to First Byte Metric indicates in milliseconds, how long it takes for the server to send the first byte of the website content data to the client/browser.
While establishing a connection between the client and the server, other data gets transmitted over the network, for protocols such as TCP and TLS.
They ensure a stable and reliable connection between the client and the server, and only after those protocols are done, the website content can be transmitted.

2 Likes

Hi
The question is very good, I also have a ttfb problem, I hope you will answer me

1 Like

In that case, there could be some clarification. You see, “DNS, socket and SSL negotiations +100ms” is a different thing that all the above PLUS some initial website content.

And when the TTFB is considered OK if it is just a couple of hundreds of milliseconds - and it does, according to the initial definition - then it should not include content. If it includes content, then the time is always higher than just the initial connection.

I run Joomla websites, so I have noticed that in all cases the “DNS, socket and SSL negotiations” are around 200-300ms maximum, according to the waterfall.
BUT, the TTFB of Webpagetest includes all the rest: the database queries, gzip, AND the first html content. It is unrealistic to expect all of that, in any website, in the first hundreds of ms. Usually it takes around a second to start delivering THAT data.

1 Like

I beg to differ. The database queries and gzip are exactly what the TTFB measurement is meant to flag and identify when they are slowing things down. On a well-tuned CMS using a fast database backend, it is fairly easy to achieve (SSD’s for the database are pretty critical).

OR if the pages are relatively static you can cache the HTML on a CDN like Cloudflare does with the Wordpress optimizations and only purge the cache when content changes.

1 Like

Hi,

TTFB include all time consumed from start of the http request (dns lookup, tcp connect, ssl negociations…etc) and the first byte return in the response. It measures your server/applications performance (inluded your db queries and alll resources your application need to serve the content)

eg for webpagetest.org, connect and ssl negociation took 63ms while application return first byte in 614ms :

$ curl -w "@format.txt" -o /dev/null -s "https://www.webpagetest.org/"
     time_namelookup:  0,001353s
        time_connect:  0,019604s
     time_appconnect:  0,063998s       # The time, in seconds, it took from the start until the SSL/SSH/etc connect/handshake to the remote host was completed.
    time_pretransfer:  0,064090s
       time_redirect:  0,000000s
  time_starttransfer:  0,614756s          # here is our TTFB
                     ----------
          time_total:  0,710961s