Pushing performance with EngineHosting’s CDN for assets

Site performance is a game of details.

Large sites need this attention to detail in order to keep page loads quick and visitors from wandering away.

A site we recently worked on at Q Digital Studio required a load of performance tweaks, one of which was with EngineHosting’s CDN (Content Delivery Network). Because of the amount of dynamic content being served on this particular site, our focus became ensuring that our assets were not holding up our page loads. 

Unfortunately, we found that there was a bit of a learning curve when working with EngineHosting.

Pay attention to expiry headers

In the process of adding assets to the CDN, we started with images and transitioned to JavaScript (JS) and CSS. What we found with our images and CSS especially, was that the expiry headers needed some attention – so make sure when your CDN is set up that you know where the htaccess file for controlling these is and that you have editing permissions.

If you find yourself pushing updated assets to the live site, you will need to be aware of the headers to understand what will happen to the assets due to the nature of the CDN – it bypasses the web application (EE in our case) and speaks directly with the browser. 

Cache clearing in EE will do nothing. But by editing the defaults below, you can specify how long your assets will be held in the cache.

EngineHosting CDN expiry headers defaults:

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType text/html "access plus 1 second"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType image/gif "access plus 1 month"
    ExpiresByType image/png "access plus 1 month"
    ExpiresByType image/jpg "access plus 1 month"
    ExpiresByType image/jpeg "access plus 1 month"
    ExpiresByType text/javascript "access plus 1 month"
    ExpiresByType application/pdf "access plus 1 month"
    ExpiresByType application/x-download "access plus 1 month"
    ExpiresByType application/x-javascript "access plus 1 month"
    ExpiresByType application/x-shockwave-flash "access plus 1 month"
</IfModule>

As far as the htaccess goes, it should typically be located in the root of your designated cache/assets directory. If it’s not there, EH has said it can also be in the webroot’s htaccess.

Designate caches and set up subdomains

We designated that both layout images and content images should be cached by the CDN. Part of the EngineHosting CDN deployment was setting up subdomains for our assets and static images separately. We created assets.domainname.com for all static assets (layout images, CSS, JS) and static.domainname.com for all content images in our uploads directories.

Because we were using ExpressionEngine, we also needed to update all directory paths for uploads to reflect the changes. So domainname.com/images/uploads became static.domainname.com/uploads. Similarly, all links to CSS and JS that were formerly domainname.com/a/ became assets.domainname.com/.

You can view you assets or uploads by either URL.  For example, assets can be viewed from domainname.com/a/ and assets.domainname.com. While URLs will need to be updated, server paths will remain the same. Setting up sub-domains such as these will ensure no conflict between your assets and all calls being made from your domain name.

Static assets such as images, JS and CSS are great to have in a CDN caching mechanism to keep them from being consistently served at page load. If you’re willing to spring for the CDN, you’ll certainly see some spring in your page-load step.

During the process of implementing the EngineHosting CDN, we learned a performance-oriented pointer worth noting regarding Engine Hosting’s load balanced environment: we were informed that database caching and tag caching in EE can actually slow things down quite a bit.

So if you’re on EngineHosting and have database and tag caching enabled, you’ll want to consider disabling them.

Good service needs good guides

Generally, we’re very happy with EngineHosting’s services, but find the lack of user guides for implementations such as the CDN to be a bit frustrating.

Oriented and optimized for ExpressionEngine by nature, EngineHosting could go a long way for their loyal customers by publishing  some basic guides.

If you’re also becoming acquainted with EH’s CDN, hopefully you found these tips enlightening. Questions or comments? Share below.