This is probably a simple question, but I can't find a straightforward answer anywhere.
My website is hosted on Amazon EC2.
I want to take advantage of Amazon Cloudfront to speed up the loading of the images, Javascript and CSS on my site.
Throughout my site, I've used relative URLs to point to the images, Javascript and CSS that reside on my EC2 server.
So, now, in order to take advantage of Cloudfront, do I need to change all my relative URLs into absolute URLs which point to Cloudfront, or will this be handled automatically by Amazon/EC2/Cloudfront? Or, maybe a better way to ask the question is, can I leave all my URLs as relative URLs and still get all the advantages of Cloudfront?
Short answer is no, your relative URLs will not work as expected on CloudFront - except for the case mentioned by Gio Hunt that once your page loads the CSS file, any relative url inside the CSS file itself will resolve to CloudFront, but this probably isn't very useful in your case.
See this answer for a solution using SASS that pretty closely matches what I've done in the past:
I used SASS - http://sass-lang.com
I have a mixin called cdn.scss with content like $image_path: "/images/";
Import that mixin in the sass style #import "cdn.scss"
Update image paths as such: background:url($image_path + "image.png");
On deployment I change the $image_path variable in the mixin.scss and then rerun sass
Basically you regenerate your CSS to use the CDN (CloudFront) base url by creating a variable that all your pages respect. The difficulty involved with doing this will depend on how many references and file you need to change, but a simple search and replace for relative paths is pretty easy to accomplish.
Good luck.
If you want to leave everything as is, you could pass everything through cloudfront setting up your site as a custom origin. This can work pretty well if your site is mostly static.
If you do want to take advantage of cloudfront without sending everything through, you will need to update your relative urls to absolute ones. CSS files can keep relative urls as long as the css file is served via cloudfront.
Related
I'm facing what could be a simple problem, but haven't been able to find any solutions yet.
I just recently built a simple 404 page on my website (nofound.html) which through a .htaccess redirection (ErrorDocument 404 /nofound.html) allows me to catch all URL errors and such. Basic.
The problem is that, since the 404 response can be called within different directories, say for example index, or /dir1, or /dir1/dir2, etc, the page is not loading its styles and images right, since the source paths do not link correctly (image.png links correctly from index/nofound.html, but should become ../image.png and so on when going into different directory layers).
I've managed to make the styles load correctly by loading the same stylesheet twice (styles.css AND ../styles.css), but for the images, I have not found any workaround yet (other than duplicating the image within layered directories, which is cumbersome and redundant).
Any thoughts? Thanks in advance!
Although it does not follow best practices, my final solution was to simply use absolute hyperlinks (such as https://website/img.png or something like that) rather than relative links within the website's anchors (../../img.png)
As such, every element on the page is loaded from its absolute -actual- directory, regardless of the relative relationship between the nofound.html result and the rest of the site architecture.
I have a third-party WP plugin which, although no longer updated, still works fine - and for which I've not been able to find an alternative.
It's 'Zajax' - which ajax-loads internal pages... thus enabling a streaming-radio audio-player to be fixed to the viewport-base, with continuous play throughout page-changes.
However, it appears to require absolute urls - on root-relative urls it reloads the whole page (and thus stops continuous-play).
This is a hindrance, because I normally use root-relative urls - and hence sometimes forget to ensure that all internal urls are absolute rather than root-relative.
I want to modify, so that it'll work with root-relative urls - but don't know enough to do this.
Actually using root-relative URL-s is not good idea, but if it is comfortable for you, then use small jQuery snippet which may help you with the problem.
jQuery("a").each(function(){
if (jQuery(this).attr("href").indexOf("http")==-1){
jQuery(this).attr("href","https://yourwebsiteurl.com/"+jQuery(this).attr("href"));
}
});
You can put this code to footer area of your website, it will detect root-related links and convert them to normal links. (without changing anything at your backend, of course)
I know CDNs like Cloudflare save bandwidth by caching static files as images, JS, and CSS files.
I have a script that generates images on the fly and its location looks something like this:
http://domain.com/image.php?id=1
With id being the image id. Cloudflare won't cache these images due to the dynamic URL. If I add a mod rewrite rule to rewrite the URL to become something like:
http://domain.com/images/1
or
http://domain.com/images/1.jpg
Will CloudFlare cache the images in this case or the images have to actually be real files that reside in directories?
One way to check is to open a page containing an image and then use Chrome Web Inspector. Go to Network > Images, select an image, then under Header > Response header look for cf-cache-status.
If you see cf-cache-status: HIT then the image or resource is being cached by CloudFlare. I think the alternative is 'MISS"
Good luck
This question is a duplicate of one on StackOverflow already: Using CDN like Cloudflare with mod_rewrite to save bandwidth
The short answer, however, is this:
The easiest way to Cache Everything on a given endpoint in CloudFlare
is to use a Cache Everything Page Rule, an asterisk will match a
wildcard result. So in your first example we can do the following:
My MVC project uses the default location (/Content/...)
So where this code:
<div id="header"style="background-image: url('/Content/images/header_.jpg')">
resolves as www.myDomain.com/content/images/header_.jpg
I'm moving my images files to S3 so now they resolve from 'http://images.myDomain.com' Do I have to convert all the links in the project to that absolute path?
Is there perhaps an IIS7x property to help here?
EDIT: The question seems to boil down to the specifics of working with IIS's Rewrite Module. The samples I've seen so far show how to manipulate the lower ends and query string of a URI. I'm needing to remap the domain end of the URI:
http://www.myDomain.com/content/images/header_.jpg
needs to become:
http://images.myDomain.com/header_.jpg
thx
I'm not sure I understand you correctly. Do you mean
How do I transparently rewrite image urls like http://www.myDomain.com/Content/myImage.png as http://images.myDomain.com/Content/myImage.png at render time?
Or
How do I serve images like http://images.myDomain.com/Content/myImage.png transparently from S3?
There's a DNS trick to answer the second one.
Create the 'images.myDomain.com' bucket, and put your content in it under the '/Content/' path. Since S3 exposes buckets as domains in their own right, you can now get your content with
http://images.myDomain.com.s3.amazonaws.com/Content/myImage.png
You can then create a CNAME record in your own DNS provider taking 'images.myDomain.com' to 'images.myDomain.com.s3.amazonaws.com'
This lets you link to your images as
http://images.myDomain.com/Content/myImage.png
..and yet have them served from S3 (You might also consider a full CDN such as cloud front.)
I'm designing a web application to support use of a CDN in the future.
Two options I've considered:
Use domain aliasing for static content on the site, including CSS, JS, and some images.
Use "edge side includes" to designate static content regions.
(1) is simpler and I've implemented it before. For example, we would prefix each IMG src with http://images1.mysite.com/, and then later update the corresponding DNS to use the CDN. The drawback I've heard from users of our internal "pre-production" site is that they would have to push the images to images1.mysite.com to preview their changes internally -- ideally, files would not get pushed to images1.mysite.com until they're ready for production. (NOTE - hosts file changes and DNS tricks are not an option here.)
Instead, they would like to simply use relative or absolute paths for static content. e.g. /images/myimage.gif
(2) is not as familiar to me and I would like more info. Would this allow our "pre-production" team to reference static content with a relative path in "pre-production environment" and yet have it work with the CDN in production without HTML modifications?
Could someone compare the two options, in terms of ease of development, flexibility, and cost?
Here's a variation on the second option to consider.
Leave relative image URLs alone in your HTML. On your production server, have image requests return a server-side redirect to the image location on the CDN. This generates marginally more traffic than the other techniques, but it generates an access log entry for each image hit, keeps your HTML and site structure simple, factors specific CDN dependencies out of your site source, and lets you enable, disable or switch CDN-based image service on the fly.
If you are using a demand-pulled CDN such as Coral, you also need to ensure that requests either issued by or declined by the CDN are served directly from your production server. See Using CoralCDN as a server operator for more information on this technique.