I don&#x27;t currently see a 500 ms difference, so maybe they figured something out. From my shell, I see about 35 ms to <a href="http:&#x2F;&#x2F;www.stavros.io&#x2F;404" rel="nofollow">http:&#x2F;&#x2F;www.stavros.io&#x2F;404</a> and about 85 ms to <a href="https:&#x2F;&#x2F;www.stavros.io&#x2F;404" rel="nofollow">https:&#x2F;&#x2F;www.stavros.io&#x2F;404</a> (the HTTPS site serves actual content and the HTTP a redirect, which confounds the numbers).<p>The HTTPS server is currently offering me a 4096-bit-RSA  certificate, signed by the 2048-bit-RSA StartCom class 1 intermediate CA. There&#x27;s no security benefit in a 4096-bit cert signed by a 2048-bit one, since any attacker capable of breaking 2048-bit RSA but not 4096-bit is just going to attack the CA cert and sign their own forged cert (and any attacker <i>sorta</i> capable of breaking 2048-bit RSA will dedicate their brute force effort to CA certs). And to my knowledge, all current CA intermediate certs are 2048-bit. Meanwhile, because of math, 4096-bit certs take a lot longer to handshake: see e.g. <a href="https:&#x2F;&#x2F;certsimple.com&#x2F;blog&#x2F;measuring-ssl-rsa-keys" rel="nofollow">https:&#x2F;&#x2F;certsimple.com&#x2F;blog&#x2F;measuring-ssl-rsa-keys</a><p>CertSimple&#x27;s data indicates a 25 ms difference between 2048-bit and 4096-bit keys on their server, so I&#x27;d expect that the 4096-bit key is responsible for at least most of the performance difference here. A few years ago I screwed this up on a production shared web host, and I believe we saw a greater than 50 ms difference. (While we&#x27;re at it, that cert is SHA-1, so it&#x27;s possible they can get a reissue for free.)<p>Were you able to replicate the 500 ms (!) performance difference on your own server? Are you using a 2048-bit cert and reasonable cipher suites?