Don't upload assets (js/css) to S3 when using Cloudfront
Instead, just set a custom origin header on your Cloudfront distribution, and point it to your application.
Pros
- No need to pay for a S3 bucket.
- No need to upload assets to S3 during deploy.
- Possibly less gem dependencies.
- Possibility to serve gzipped assets depending on the Accept-Encoding header. (Why we moved to this solution at Mynewsdesk)
Cons
- Could mean slower initial requests if loading asset from a very remote location
- Need to distribute precompiled assets to all of your application nodes, if behind a load balancer.
Read more: http://aws.typepad.com/aws/2010/11/amazon-cloudfront-support-for-custom-origins.html
Written by Richard Johansson
Related protips
2 Responses
We've used custom origin in a recent project and it is great!
It is worth noting that you should version your assets to avoid serving cached content from cloudfront.
Example
<link rel="stylesheet" href="http://yourcloudfronturl.com/content/style.css?v=1"/>
The other benefit is its easier to handle access-control-allow-origin issues with fonts and Firefox if serving from your app instead of S3
Have a fresh tip? Share with Coderwall community!
JavaScript on a page runs with the privileges of that origin. One altered library, tag manager, or snippet can read inputs, change what people see, and call your APIs as the user.
Security insights from Cside