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.
Yeah, I agree, and I hope most people make good use of the extra screen real estate -- Full screening a browser on 27 inches would be less than optimal except for when a website is designed to be used that way.
But, even at a reasonable window size, I find the Gmail compose box to be wider than ideal for encouraging succinct communication.
He mentioned login attempts in the article. Someone tries the wrong password more then a few times and the account gets locked. That should thwart any and all dictionary/brute force/you name it attacks. So which is more secure, an impossible to accomplish remote attack, or a password sitting on your desk?
Bank password polices are retarded. I currently have one that requires 6 characters. No more, no less. This may be the worst offense I've seen but it doesn't excuse the other bullshit that passes as secure or acceptable in the banking arena. These guys need help.
If you're referring to that last line, yeah I totally fat fingered that. I fixed it.
I'm advocating moving to an absolute system. As in an absolute width, measured here, measured there, measured anywhere. This can then be scaled to mimic the appropriate absolute width based on viewing distance and other parameters such as screen real estate.
I know what you're thinking. "But pixels are an absolute measure...". Actually yes, and actually yes. Pixels are an absolute measure in the sense that they state that I want something to be the absolute size of a single pixel but the pixel is arbitrary and now your absolute measure is relative to the actual size of the pixel. As mighty as this sounds, it actually turns out to be not all that useful in design; as screen resolutions vary so will your renderings. This is why CSS pixels are different, they're for all intents an purposes interpreted as 1/96th of an inch. So, great they're absolutely 1/96th of an inch, they're absolute! So why should you stop using them? This paragraph is why you should stop using them. I didn't like writing this paragraph, and I'm gonna guess you didn't like reading it. Pixels are confusing and pixels are * liars. Use points.
You would think so, but that's not true. Design in points (1/72) and ship in points. I'm telling you, you're stuff is rendering at 1/96th, not native res. Try it out for yourself. Make two divs, specify one as 96px and the other as 72pt. See, same size, same size. Now think, if that were an image... Not native res, but yet it still looks right... Interesting.
"A CSS pixel is ALWAYS the exact same thing as a screen pixel"
Not true. You should reread the article, if you care to, and perhaps check the sources. Even if what you were saying was true do you think it makes sense to define things at the native resolution of a monitor? :Faceplam:
OP here. Sure, you can redefine pixel, that's what was done. Why do you need this measure though? 1/96th is so close to points, you might as well just use points and now you're on a universal system.
Pixels use to mean something (a pixel). Now they're used as an absolute unit of measure so that websites (nearly all of them) based on this assumption don't break. Do we really need this unit? Isn't it confusing (1/96th does not a pixel make)? If we stop using it incorrectly maybe it could mean pixel again. Wouldn't that be neat?
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.