Turning it back off gave a very clear improvement both in my own experience and according to Google's chart.
In my opinion this article skipped two of the best CDN's around, Edgecast and Highwinds. Edgecast in particular is damn fast (ssd boxes, high ram, most stuff served from memory). We're running multiple SSL'd domains through them without issue. Highwinds is more of an up and comer, but they have amazing service (as long as you avoid using them in South America).
The reason I avoid Cloudfront (AWS) is that it's way to expensive. I avoid CloudFlare because of the interactions I've had with their security team and CEO.
MaxCDN is good as long as you have no plans to go global. Let me be very explicit about this- if your CDN doesn't have a POP in Australia then they're not ready for prime time. There are only a few fiber lines going into the country and performance is absolute crap if you aren't hosting your files there. They also have nothing in South America, the MidEast or Africa.
As a seperate note, most DNS management companies will offer DNS based "CDN Managers", which will allow you to set priority rules for each CDN by region. This is an amazing tool that allows you to really take control of your traffic. I've never seen a CDN that was perfect everywhere, and when you have to deal with things like China (who don't really allow external CDN's in, forcing you to use one of theirs or host traffic out of Hong Kong) it's a life saver. I know that Edgecast, Dyn and UltraDNS offer these types of services (with the Edgecast one being the cheapest by far).
https://docs.google.com/spreadsheet/ccc?key=0Al_R0WNcU3q9dGV...
Also, I'd be interested in seeing the results for Fastly.
We weren't too impressed with Cloudfront. The performance was all over the place and they provide no insight for cache hits/misses.
When the entire page is static, but changes must be communicated everywhere instantly, rapid purging is the answer.
Fastly has a great CDN service, beutiful origin hosting for a Rails or Python app, and customizable output filters (gzip? yes, please) and customizable cache config.
Can't recommend them enough.
Clarification psated from a comment I made below:
Sure, I can test my latency, but I'm more interested in what my customers are experiencing. For instance, we have a big customer over in east Asia and I have very little idea what latency they get. When we were using Cloudfront a customer in Australia complained that they were seeing timeouts. It seems there was a bug in Amazon's routing table as Cloudfront has a POP in Sydney but their requests were going somewhere much further away.
I'm using Cloudfront with the origin option for a subset of our users. I've found a few clients with so restrictive or broken firewall rules that I had to add an option to default to getting the files from the source if users come from network X or Y. While cloudfront lets you download the log files, you get one S3 object per edge location per 15 minutes or something like that, so 1000s per day, which made things difficult to troubleshoot (I suspect the problem with one user was partial cache due to Apache's deflate sending responses as chunked encoding as default and Amazon's origin spider sometime dropping such connections).
But purely in terms of speed, Akamai Rules. Closely Followed by ( and sometimes even exceed ) EdgeCast.
From my experience, MaxCDN is the next bet since they are from NetDNA. Not saying CloudFront, or Other OnApp based CDN not good, for large files transfer or video streaming they are perfectly fine. But for small files, fast response and low latency those three are the way to go.
Haven't tested Fastly yet purely because i think they are very expensive against some other established players. And I guess they have far few PoPs. Would love to see some detailed comparison though.
£8.99/month including SSL.
(Note, I haven't actually tried it myself!)
First, you use rules (patterns) to set the TTL, rather than headers. Second, I just couldn't get the SSL working. I'd upload the certificate, it would say that it would show up shortly, but days later, nothing. Third, the routing seemed messed[1]. Their support normally isn't horrible, but it took weeks to get anyone to acknowledge the support request that I opened on this, even after escalating it.
[1] I know people like to point out that internet routing has nothing to do with geography. But I squarely refuse to believe that, Singapore users should get routed to France (they have a POP in Singapore, HK and Japan).
Our product (Myna; mynaweb.com) provides a JS client that our customers embed on their web sites. If we give them a Cloudfront URL we have just created a big legacy problem for ourselves if we ever want to move off Cloudfront (and we did and we have!)
If you're creating a pure JS client connecting to an API on a different domain you have to worry about CORS support to get cross site requests. It's not a huge problem but it slows your site down a bit (you have to make two requests to check CORS permissions and then send data, where you could make one without this issue) and you can't support legacy browsers.
So there are a few reasons why using a Cloudfront URL might not be 100% suitable.
Most sites will probably be fine using SSL for their main site using their main servers - requests going direct to the site, with static/media files being served from a shared SSL certificate with their CDN.
Now I'm happy with Amazon S3 + Cloudfront, it's cheaper and more stable.
From what I could tell talking with some people so far, is that they only think they need CDN, while a couple of regular dedicated servers would be just fine. But, then again, most of my customers are in Europe so I can serve files cheaply. In US, I'm currently using FDCServers, which are 3.3x more expensive than equivallent Hetzner server. And this was one of the cheapest I found. I find most Amazon services to be overpriced. IMHO, you're just paying more for the brand name.
They provide a pretty nice overview about edge locations and other important options for considering to use a certain service.
Would it be possible for them to offer an SNI-only SSL option for far cheaper if you know beforehand who your clients are (say, if you're hosting content for an iOS app)?
CloudFront has been asking a lot about a hypothetical SNI only offering in their user surveys lately, so that is likely the route they'll pursue shortly for far cheaper SSL options.
Edit: Just recalled they use Subject Alternate Name, not SNI. This is where they add your domain to their SSL certificate.
For example Ninite.com moved to them and now the site is virtually unusable because of it, over 90% of the time I get a "403: Forbidden" error when trying to do anything...like send them feedback on how the website doesn't work...
I even see more HN problems this week and I'm sure its because of them.
I spent a short while investigating if there was an easy way to get it working but ended up just giving up on the site.
