HTTP2, NginX but still high TTFB - ssl

Question

No matter what changes we've made TTFB is high!
Surprisingly, server side guy insists that everything is set correct and the server runs fast enough but webpagetest report didn't change at all!
After so much optimization, I can't believe it doesn't change and I started to suspect TLS, gZIP and redirections...
Did I miss something?

Answer 1

It appears that the page itself takes about a second to generate. Here's a curl output (using this to get timestamps), and notice the value of time_appconnect
$ curl -w "#curl_format.txt" -so /dev/null https://jimmydance.com/
time_namelookup: 0.004
time_connect: 0.217
time_appconnect: 0.921
time_pretransfer: 0.921
time_redirect: 0.000
time_starttransfer: 1.348
----------
time_total: 1.352
This would suggest that the bottleneck is the application generating the page. Looking at the page itself, it shouldn't take so long, I would look at the framework you're using or the resources allocated to the server.

Answer 2

Using #frederik-deweerdt's answer and a breakdown of curl timing figures
Your server is spending nearly 1 second doing its TLS handshake (time_appconnect: 0.921)
TTFB is time_starttransfer - time_appconnect (1.348 - 0.921 = 0.427)
the time the server spent generating the html is TTFB - (time_connect - time_namelookup) (0.427 - (0.217 - 0.004)) = 0.214
so I'd say the bottleneck isn't the app, instead it's the server's slow TLS negotiation and some latency in the network.
Have a look here for a good explanation of these curl timing figures: https://blog.cloudflare.com/a-question-of-timing/
The diagram below shows what each of those timings refer to against a typical HTTP over TLS 1.2 connection (TLS 1.3 setup needs one less round trip):
time_namelookup in this example takes a long time. To exclude DNS resolver performance from the figures, you can resolve the IP for cURL: --resolve www.zasag.mn:443:218.100.84.167. It may also be worth looking for a faster resolver :).
time_connect is the TCP three-way handshake from the client’s perspective. It ends just after the client sends the ACK - it doesn't include the time taken for that ACK to reach the server. It should be close to the round-trip time (RTT) to the server. In this example, RTT looks to be about 200 ms.
time_appconnect here is TLS setup. The client is then ready to send it’s HTTP GET request.
time_starttransfer is just before cURL reads the first byte from the network (it hasn't actually read it yet). time_starttransfer - time_appconnect is practically the same as Time To First Byte (TTFB) from this client - 250 ms in this example case. This includes the round trip over the network, so you might get a better guess of how long the server spent on the request by calculating TTFB - (time_connect - time_namelookup), so in this case, the server spent only a few milliseconds responding, the rest of the time was the network.
time_total is just after the client has sent the FIN connection tear down.