Autoptimize 1.6.5 got just pushed out, with one new feature and one notification. The new option configures Autoptimize to output the aggregated JavaScript in the head-section instead of at the bottom of the HTML. This can be useful when some of the JavaScript needs to be loaded asap and might prove useful to make jQuery plugins behave.
The notification might be less welcome for some users; YUI compression and the CDN options are marked as deprecated in this release. YUI compression was pretty exotic and required the installation of JAVA and the YUI compression jar, so I doubt anyone was actually using this. CDN options are deprecated as well; some people reported issue that I could not reproduce or fix. As I consider CDN not to be core functionality and as it can better be accomplished using e.g. WP Super Cache (which is a must-have companion of Autoptimize anyhow), CDN will indeed also be removed from Autoptimize. Expect the deprecated parts to be removed in 1.7.0 (which isn’t planned yet).
cdn
Site slower with CDN? Check your CSS!
A couple of days ago we implemented a CDN for a Drupal-based website, using MaxCDN/ NetDNA and the Drupal CDN module. We were very surprised to discover the site became … slower. It took us some time to identify the problem, but CSS turned out to be the culprit;
- The supplier created separate CSS-file for each and every template using SASS, causing some automated duplication of CSS
- Some of that CSS was not in the theme .info-file and wasn’t added using drupal_add_css either, but the link was hardcoded in the template-file
- The CSS that was added the normal way (i.e. not hardcoded in the template) was picked up and modified by the CDN module (changing paths for e.g. images and fonts into URL’s pointing to the CDN)
- CSS that was hardcoded in the template was not visible for the CDN-module, so the paths were not updated and still pointed to the origin webserver
- Because of duplication of e.g. background-images and fonts, pointing at both the CDN and the origin-server, these assets were downloaded twice and the extra file-size resulted in a site that was slower with than without a CDN
Once we understood the problem, the solution was pretty simple;
- clean up the CSS, avoiding to re-declare e.g. @font-face in multiple templates (resulting in a smaller CSS file download size as well)
- add CSS using drupal_add_css (with the option not to aggregate, as IE8 might choke on the massive amount of CSS) for the CDN module to take that into account as well
Web Performance Optimization can be so much fun!
Learning from my Apache/ CDN mistakes
Earlier this year I configured this here little blog to offload static resources to MaxCDN. I made some mistakes in the process, which I documented in a blogpost that has been in my drafts for too long. So here’s the gist;
- Etags misconfiguration:
- Problem: By default Apache uses the file’s inode to calculate the Etag, but that inode is unknown to the CDN, so Etags can never match.
- Solution: change the Apache config not to use inode, e.g. “FileETag MTime Size”
- Cookies & domains issues:
- Problem: I created my CDN-domain as a sub-domain of my main one, which led to (small) performance and (potentially huge) security issues.
- Solution: Make sure your CDN-domain is different from the domain on which your cookies are set. So for example for main domain blog.futtta.be don’t use static-cdn.blog.futtta.be, but rather blog-cdn.futtta.be (except if cookies would be set on futtta.be, in which case I would need cdn-futtta.be).
- Todo: it might make sense to add some Apache magic to make sure that for requests from the CDN:
- only images, css & js can be requested
- the cookie header is removed alltogether
CDN to the Max
It was time to put my money where my mouth is, or at least to give the use of a CDN a try. Based on previous tests MaxCDN seemed like a decent, dirt-cheap solution, so that’s what the js, css & images for this blog are served from now.
Setting this up was very easy:
- log into MaxCDN and set up a pull zone on static-cdn.blog.futtta.be with origin blog.futtta.be
- create static-cdn.blog.futtta.be in the web interface of my DNS-provider (as a CNAME to the domain-name provided)
- configure WP Super Cache to use static-cdn.blog.futtta.be instead of the non-cdn static.blog.futtta.be)
The speed difference can be huge, especially when routing to my origin VPS-server in Germany isn’t great. I’m sure my 2 overseas users and Google will approve!
Bandwidth-wise, with 10MB/day, I seem to be far from the 1TB/year I’m allowed, so if you’d like me to setup a (temporary) pull zone for your blog so you can check out if this would work for you then just drop me a line.
Choosing a CDN in a whim
I had to look into CDN’s some time ago, to find a suitable temporary solution for a problem at work. There are a lot of players in this field, Akamai and Amazon (Cloudfront) being market leaders of some sort, but there’s also Microsoft with their Azure CDN (which we already had some experience with), other big guns such as Rackspace and Level3 and specialized shops such as CacheFly, CDNetworks and NetDNA as well. So how to choose?
| Results only relevant for Belgium (and even then …) | avg. speed (ms) for 64kB | speed delta % from fastest |
| softlayer | 121.3 | 100% |
| gogrid | 123.0 | 101% |
| microsoft azure | 132.0 | 109% |
| level3 | 132.0 | 109% |
| amazon cloudfront | 133.3 | 110% |
| maxcdn | 136.7 | 113% |
| cotendo | 138.7 | 114% |
| cachefly | 147.3 | 121% |
| rackspace | 156.3 | 129% |
| highwinds | 226.3 | 187% |
| voxcast | 227.7 | 188% |
| flexiscale | 317.3 | 262% |
| amazon s3 eu | 417.3 | 344% |
| google appspot | 668.0 | 551% |
| voxel nl | 814.0 | 671% |
| amazon s3 us | 932.0 | 768% |
| voxel ny | 942.0 | 776% |
Well, if you’re in a hurry, you could compare price and features via cdnplanet.com. The info might not always be complete, but it does give you a good first idea and you can always visit the CDN’s proper site for more details, can’t you?
After comparing features & pricing, you really should get an idea of the speed of these CDN’s, of their performance relative to your customers. I found this CDN Speed Test on cloudclimate.com very useful; it performs a live test of approximately 20 CDN providers, requesting a 64 kilobyte file 10 times for each CDN from within your browser. So if you can get a sample of your customers to perform that test and provide you with the results, you’ll have some very useful information about performance. Together with your overview of features and price, you should be able to make at least a vaguely educated decision, no?
To have an idea about performance for our market (Belgium), I asked some Facebook-friends to provide me with the results of the CDN Speed Test. Most data I received was for Telenet or Skynet/Belgacom, not coincidentally the biggest ISP’s here. You can see the aggregated results in that ugly table on the left (or a couple of paragraphs up, if you’re subscribed to the RSS-feed).
My conclusion: as I was looking for a pay-as-you-go (no obligations, no monthly fee) CDN for static files, with support for Origin-Pull, HTTPS and some administration features (for example to purge the cache and watch nice graphs), MaxCDN fit the picture pretty well. With a great introductory price ($40 for the first Terabyte and even less if you find the coupon code) and performance that is at 113% of the fastest competitor, they seem to have found somewhat of a sweet spot for my specific context.
The only problem; I’ve got to wait for a “GO” from some people higher up the food chain. Maybe I should already implement it on my blog, just for the fun of it?
Quick & dirty “CDN” in WordPress
If you want a quick & dirty way to speed up WordPress without any plugins:
- create a subdomain in DNS, e.g. static.yourblog.org
- add that subdomain as a ServerAlias to your Apache config (remember to restart apache)
- add the following to your wp-config.php:
define('WP_CONTENT_URL','http://static.yourblog.org/wp-content');
If you want to do this the right way; plugins such as WP Super Cache or W3 Total Cache do a much better job at this.