3 ms·
I made this decision just this week, biggest reason being gzip compression. S3 will only store your file compressed or uncompressed, and you have to do server-
by ccorda 14y ago
I made this decision just this week, biggest reason being gzip compression. S3 will only store your file compressed or uncompressed, and you have to do server-side gzip detection to request the proper version, which isn't possible with CloudFront. [1]. You also have to gzip compress locally and upload both versions.
With MaxCDN, I just upload uncompressed, and it will gzip upon request certain text file types (xml, js, css, etc.) [2].
[1] http://blog.kenweiner.com/2009/08/serving-gzipped-javascript-files-from.html http://blog.kenweiner.com/2009/08/serving-gzipped-javascript...
[2] http://www.cdnplanet.com/compare/cloudfront/netdna/ http://www.cdnplanet.com/compare/cloudfront/netdna/
- HeyImAlex 14y agoI feel like this is almost a non issue unless you're running a site that absolutely needs to run everywhere since the last browsers that shipped without gzip support were released in what, 1998? A significant portion of your users (according to O'Reilly's 2009 _Even Faster Websites_, around 15%) don't say they can support gzip even though they can. Just ignoring Accept-Encoding headers and serving only gzipped content is probably good enough for 99% of people and likely gives you slightly better overall performance on average than actually respecting whatever the request headers say.
- jdorfman 14y ago@HeyImAlex A week ago I would have totally agreed with you. I asked a friend and he told me "replace the user-agent with a misconfigured upstream proxy and you run the risk of serving an uncompressed version to end user that supports gzip, and vice versa."
- eli 14y agoSounds dangerous, but if you try it out on a popular site, I'd love to hear your results!