Make Your Blog Faster (Final Part)

Part 4 of this series finally made us finish the configuration of Amazon’s Web Services (AWS) needed for implementing a Content Delivery Network. In a perfect world we would be finished now, but you should be prepared for a couple of issues that might occur under certain circumstances. When I’ve set up the CDN for this very website, these issues involve(d) some effects with font serving and Firefox; some attention you will have to spend at your bucket’s special permissons; and then we will have to correct some MIME type bindings with font files. Could be that these recipes are no longer necessary (or even invalid): at the time of this writing (February 2015) they were necessary for avoiding problems with Firefox.

So where is the problem? Let’s suppose you already have upload all data of your WordPress theme(s) to your CDN, including font data. Browsing your website with Opera and Chrome gives the expected results, but with Firefox it’s a little different. The first problem emerges if your fonts are not coming from the same host name like the rest of your data. This is a cross domain request problem: by default, Firefox won’t load your front from any CDN without further setup. The error code revealed by Firebug reads as follows:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at . This can be fixed by moving the resource to the same domain or enabling CORS.

Not a very good advice. We were moving everything to the CDN to speed up things, so putting the fonts back to the server is not an option. Obviously we must “enable CORS”. I’ve never heard of that before.

CORS is Cross-Origin-Resource-Sharing. Amazon has a good description of how to enable it on your bucket. The basic idea is that your bucket has to be configured to allow cross-domain requests. You do this by creating a CORS configuration, that is a XML document, where parameters like allowed HTTP methods, allowed origins, timeout boundaries etc. are put together. You can reach them from the AWS control panel via S3 -> choose your bucket -> Properties -> Permissions -> Edit CORS configuration.

An easy example configuration might look like this (taken from this site):

Here you allow GET requests coming from any origin. Your bucket would be able to serve several websites which would be able to load any data using HTTP GET. But that is perhaps not the best solution, because you probably don’t want every site to access your data. AWS isn’t for nothing, so if you want to restrict requests coming from your server you want to change the AllowedOrigin to:

Should you want to be using other data and work with other methods like GET and POST on it, browsers will do a so-called ‘preflight’, issuing a HTTP OPTIONS, and then, upon approval, will do the actual request (more details about this in Mozilla’s developer documentation). I’ve uploaded pretty much everything to my CDN, so GET and POST should be sufficient for the bucket to work.

Amazon’s Enbling CORS document features all CORSRule elements. I had some trouble with the Allowed Header element which is used for preflight configuration: I simply put it to ‘*’.

All this results in following configuration for my website:

You can see that I’m allowing http and https requests, coming from eclecticimaging and potential subsites, respectively. I’m allowing GET and POST requests, no request must last longer than five minutes. These AllowedHeader elements are for preflights and shouldn’t be of much interest, since I’m allowing GET and POST only, anyway. (But that somehow looks ugly, and I should be investigating this further.) All Common Request headers used for the AllowedHeader element are described here.

There is an interesting discussion at StackOverflow where several AWS users talk about their various tweaks. I have added another one, and that concerns editing the bucket’s behaviour. Go to AWS control panel -> CloudFront -> choose the distribution we have created in part 4 -> Behaviors -> select it and click Edit. In the Default Cache Behavior Settings you will note the Whitelist Headers section. Now put the Origin header into the whitelist and save this configuration. I guess this header directly refers to the AllowOrigin element in the CORS configuration; at least it works for me. More details on S3’s request and response behaviour can be found here.

One more thing: you will probably not that the .ttf files in your bucket have received a (wrong) MIME type “application/vnd.ms-opentype”. Look at it with S3 -> Buckets -> -> wp -> wp-content -> themes -> -> fonts; you should change this MIME type to the correct value “application/x-font-ttf” for each ttf file.