As in title, i realize partly very long TTFB caused by SSL negotiation longer then one second in setup of HTTP/2, Apache and Nginx as reverse proxy.
What could be the setting screws and mostly expectable causes for such? Here an example.
ps: Found a similar question, but without specific recommendation, which where a solution for the problem.
I wouldn’t say that is actually that long when throttling your connection to Fast-3G.
The TLS handshake does take some time to complete as it requires a number of round trips. My answer here gives some guidance on what you can do to reduce this.
Additionally TLSv1.3 has some performance improvements so it can complete the handshake in 1 round trip (or even 0 round trips in some cases). HTTP/3 which is due to come out this year (or perhaps next) is also based on QUIC rather than TCP and has some connection setup performance improvements.
The simplest way to get these sorts of technology improvements is to use a CDN in front of your site to handle the user connection, and then they can pipe requests back to your site and cache content at their edge nodes. Many CDNs support TLSv1.3 already and some even support HTTP/3. They will also likely be based near your users so round trip times (RTT) will be shorter and they also usually have highly optimised network stacks.
Moving back to your site, one thing I notice is that you are using an Extended Validation cert and that requires revocation checking on all browsers (these are the first two requests and they must complete before the handshake to your site is completed). There’s a good post about that here: https://nooshu.github.io/blog/2020/01/26/the-impact-of-ssl-certificate-revocation-on-web-performance/. For non-EV certs Chrome doesn’t do revocation checking (and instead relies on a downloaded list of revoked certs which is uploaded periodically), though I see you tested with Firefox and currently it will always do a revocation check for EV and non-EV. EV certs have lost their usefulness since browsers stopped giving extra Green on the URL bar for them so it may be better to revert to a standard DV or OV cert in your next cert renewal for a performance gain in Chrome.
Other than those things your site looks good in terms of TLS set up, though you still have some older TLS settings enabled and while at browsers shouldn’t use them in preference for more secure settings, you should turn them off unless you really need them for supporting older browsers that can’t use newer settings.
Also there is possibly some tunings in the TCP layer, that are not shown by that test, but they do require expertise so would advise against them unless you know what you are doing.
