Using LetsEncrypt Certificates Properly doubles First Byte Time

Dear Forum,

We are using LetsEncrypt Lego SSL certificates and testing our websites with After repeatedly testing we have concluded that we get a “B” and “820 ms First Byte Time” if we provide our own plus the LetsEncrypt’s Intermediate Certificate “Let’s Encrypt Authority X3 (IdenTrust cross-signed)”

However, if we cut out the intermediate certificate, we get an “A” and “432 ms First Byte Time”. So, by not providing an intermediate certificate, we can show a better result to our clients. However, a test like Qualys SSL Labs complains with “This server’s certificate chain is incomplete. Grade capped to B.”

What is the right thing to do here? A with or A with Qualys?

We are using our own server with the newest versions of Apache/OpenSSL/Lego, and loading the certificates like:

    SSLCertificateFile    "/htdocs/admin/lego/certificates/$hostname.crt"
    SSLCertificateKeyFile "/htdocs/admin/lego/certificates/$hostname.key"

We would like have an A with both tests. :-)[/size][/font]

Is this possible? Thanks for any suggestions.


Do you have a link to a test result of each? You usually need the intermediate certs but including them shouldn’t increase the time by that much. It might have something to do with the size of your TCP initial congestion window or SSL frame size causing an extra round trip for delivering the certs.

Hi PMeenan,

Thanks for looking into this:

[Stripped with just the first certificate]

[Not stripped with first and intermediate certificate]

How could we change those 2 size parameters you mentioned with Apache httpd?

Thanks for your help.

Hi / Servus,

The first thing I noticed is that the site appears to be hosted in Germany but you used a US test location. Due to the unavoidable latency between these locations - ssl negotiation will take a bit longer. It does based on the numbers below - add about 90ms in total. Like peeman said - due to the larger certificate - you probably have an additional round trips during the negotiation process.
The TTFB is also a bit different - but that’s somewhat normal to have a bit of variation.

I would personally always load the intermediate, without it it’s possible some clients may not be able to connect since they cannot verify the entire chain.

All other metrics are very similar.

If your trying to optimize for users that are so far away - then look at either cloudflare or cloudfront style CDN - which will terminate your sites connection as close as possible to the client.

Test 1 (with intermediate)

DNS Lookup: 27 ms
Initial Connection: 138 ms
SSL Negotiation: 261 ms
Time to First Byte: 501 ms
Content Download: 201 ms

Test 2 (Without)

DNS Lookup: 26 ms
Initial Connection: 140 ms
SSL Negotiation: 171 ms
Time to First Byte: 438 ms
Content Download: 199 ms

Hi / Servus,

For our EU clients, we generally use US testing stations to identify such issues. In the EU to US setup, based on about 60 tests, we get on average 425 [A] without intermediate and 850 [B] with intermediate. In EU to EU tests, the results are similar with A and B since the grades there are calculated with a lower relative “Target First Byte Time”. With a higher relative “Target First Byte Time”, the tests from the US provide us a better spread to identify such connecting issues.

We need to know how we can get the A /and/ use the intermediate certificate?!? What parameters can be changed…and where are these?

Thanks so much,

Dennis the Menace.


The first thing I would do - which should be relatively easy is update your apache configuration to use HTTP2 instead of 1.1

If you look at the reports - you can see that the browser must open and negociate SSL multiple times (one for each connection ) so this wastes time overall. With HTTP2 this happens once and then the same connection can handle all the requests.

I would do that firstly and see if it helps at all, it will help with overall performance - but not sure if it would affect your TTFB so much.