4 ms·
My experience with CloudFlare couldn't be more to the contrary. We rolled it out for a good few months and gave them quite a while to get their act straight. U
by blakefrost 14y ago
My experience with CloudFlare couldn't be more to the contrary.
We rolled it out for a good few months and gave them quite a while to get their act straight. Ultimately, we had to do an emergency switch to another CDN because the performance was SOOOOOO bad and we had an important event occurring the following day (Not the ideal time to be playing with DNS on a production website).
The Theory behind CloudFlare makes sense right? They'll protect you from DDOS by getting everyone onto their network, so the network gets so big no one can take it down and they have specialized equipment and techniques. Well, maybe that makes sense if you have a problem with DDOS, but if you don't, why join a network that is obviously being DDOS every day? That doesn't make much sense to me. I assume they were being DDOS'd because every time they went down, taking us with them, that's what they would said on twitter.
The worse part was response times. With them, individual assets where taken around 500ms to 800ms to load. Once we switched to another service provider, we were seeing around 20ms-30ms. And if it's not already obvious, dynamic pages served off Heroku are faster if they're not stuck behind CloudFlare. Our total cold page load time when from 5s-6s down to 2s with this switch.
Also, all the asset rewriting and page optimization magic is so silly IMOHO. Just use a good framework like ROR with Asset Pipeline and write good code and you won't have that problem. Not like for a small site it should be much of a problem, and for a big site, they should have competent programmers and adequate resources.
Also the SSL Cert they give you sucks. It will have a bunch of other companies names on it, and perhaps besides allowing you to rollout SSL very quickly and easily, doesn't do much in the way of validating your identity.
I wish CloudFlare luck, and hopefully they will fix their issues. Until then, I'm staying away from them.
- carsongross 14y agoMy concern is more about scaling than raw page speed: of course going through a reverse proxy is going to be slower end-to-end than going directly to heroku. But taking the static asset load off of heroku without a Rube Goldberg CDN deployment is great, IMO: they just leverage standard HTTP caching headers and then those requests rarely if ever hit your dynos, like the old varnish functionality you got with bamboo stack on heroku. It's much more brain dead, which works for me. I don't use or care much for all the dynamic optimization they offer (I turned it all off) and, with respect to the SSL cert, I don't really care about how it is issued (to a first approximation, no one looks at certs except the browser verifying the cert against the URL) but YMMV. It does appear that wildcard certs have gotten very cheap now: http://www.namecheap.com/ssl-certificates/comodo.aspx http://www.namecheap.com/ssl-certificates/comodo.aspx so the cost savings isn't as great as I thought. (Thanks for pointing that out aioprisan.) I've found that heroku performance thinking is a bit different than raw page speed thinking: my goal in life is to minimize the load on my dynos. I'd be willing to put up with a CDN that was slower serving static assets than heroku is, just to keep the load off the dynos, but I've found CloudFlare to be plenty fast.
- onetwothreefour 14y agoFor your thing about not looking at certs... that's not true since all browsers now show the 'O' in the address bar for EV certs. And people definitely look at those, in my experience.