2

I have been using Cloudflare for a while without much consideration to what it was doing. Today I have noticed that there is around 500ms of delay when I view a web page over https when Cloudflare is turned on for the domain.

Both resources below confirm that the use of https on a website should have no impact on the performance.

https://stackoverflow.com/questions/149274/http-vs-https-performance https://www.keycdn.com/blog/https-performance-overhead/

I have 2 websites running on the same server. Both using SSL, but only one with cloudflare as a proxy. The normal https site has an average TTFB of 140ms (php home page) and the site using cloudflare has a TTFB of 600ms when viewing a 1kb html file. I setup a new subdomain and pointed it at the same site. I then setup an A record in Cloudflare and set it up so it would bypass the Cloudflare proxy. The same 1kb html file loaded with a TTFB of 84ms over http with the new subdomain.

My settings in the Crypto section of Cloudflare are as follows.

  • SSL : Active (Full)
  • Origin Certificates : None
  • Always Use HTTPS : No
  • HTTP Strict Transport Security: Off
  • Authenticated Origin Pulls: Off
  • Opportunistic Encryption: Off
  • TLS 1.3: Enabled+ORTT

Any help on this would be greatly appreciated.

  • Who's providing you the hosting? Namecheap?... I have 7 hours of logs today discussing with them why SSL cloudflare is so slow yet without SSL its fine... they told me to speak to my ISP lol. – Simon Hayter Oct 12 '17 at 17:21
  • It's a dedicated server on the ovh network so the IP address is all mine. I would be surprised if it was them, but it is definitely worth considering. I may setup a support ticket and wait the 9 years it takes for them to respond :D – Dan Hastings Oct 12 '17 at 17:26
2

should have no impact on the performance

That's not the case. And its not what I take from the content of the 2 URLs you cited. Having said that, the delays you describe sound unusually high.

Whether TTFB is a useful metric for measuring the performance impact (in the absence of a lot of other information) is somewhat dubious. If your application is configured to push out an early response without using chunking, then this is exactly the behaviour to be expected when the time to the last byte is lengthy (the SSL part will try to buffer a lot of the response).

What is your RTT from the browser to Cloudflare? From Cloudflare to your origin server? Are you using domain sharding? HTTP2?

The first place I would be looking is at the number of RTTs for the SSL handshake. Although I suspect there's not a lot you can do to influence this behaviour.

  • Granted the metric doesn't mean much alone but in context to the http page, we are talking about an additional 500ms just for ssl. I have a standard setup, the exact same setup used in the other site. 1 web server with Apache handling the SSL certs. The vhosts for both sites are identical. However being behind Cloudflare adds a huge overhead. Yes flushing can be used to improve first byte but this I'd a 1kb html page that has a 500ms wait. Something is wrong with the SSL when it's behind Cloudflares proxy – Dan Hastings Oct 12 '17 at 16:23
  • What is the duration of the request and the ttfb on the origin? – symcbean Oct 12 '17 at 21:08
  • The HTML file contains 4 letters. The first byte is 600 Ms and the duration of the request is just that. On the other WordPress site on the same server the TTFB over SSL is 140ms and the home page loads in under 2 seconds. For the slower site the TTFB on the home page is 800 Ms and the page is fully rendered in around 2 seconds. I have put huge amounts of effort into making php quick, but the simple fact is a tiny HTML file has a huge TTFB over https and hardly anything over http – Dan Hastings Oct 12 '17 at 21:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.