Make your website super fast with Asset Pipeline, Sprites & Cloudfront

Vote on Hacker News

Make your website super fast with asset pipeline, sprites & cloudfront

This is the second part of a two part series on how we set up Codeship with Heroku. Read the first part that deals with Heroku and how to use it more efficiently with Unicorn.

In the first part we introduced our Unicorn setup that helps you manage several concurrent requests on one Heroku Dyno. The best optimization though is to remove all unnecessary requests completely. As the Heroku Cedar stack has no Proxy in front of your Rails application any more static assets have to be delivered through your application. This is very inefficient and keeps your dynos or unicorn workers busy with serving your assets.

This blogpost shows how we use the Asset Pipeline, Compass and Amazon Cloudfront to serve all of our assets fast without sending any requests to our application directly. We use all of it on codeship.io to make sure we make the best of all the resources the cloud provides. Although this guide is written with Rails in mind the concepts like Sprites or a CDN can be used with any framework and for any website.

Asset pipeline

The asset pipeline provides a framework to concatenate and minify or compress JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB. The official Guide has a brief and easy introduction on how to use the asset pipeline and upgrade from earlier versions of Rails. Another great resource is the Railscast on the asset pipeline. We will briefly introduce our configuration and then go over our CSS, JavaScript and Image setup.

Configuration

At first add the necessary Gems to your Gemfile. It is assumed that you use the latest versions available of all gems.

Then you need to configure the asset pipeline in application.rb, development.rb and production.rb

We set staticcachecontrol to “public, max-age=31536000″ so the browser caches all static assets for up to a year. In production every asset has a hash added to its name, so whenever the file changes the browser requests the latest version as the hash and therefore the whole filename changes. Through this mechanism you do not have to invalidate any CDN cache at all, but you can by simply setting config.assets.version this will change the Hash as well and make the browser request every asset again.

All of your assets will be precompiled during deployment to Heroku.

CSS

To minimize the requests needed for loading our site we create a single application.css through the asset pipeline. The inherent problem with this setup is that css definitions for different subpages can potentially clash. To make sure this doesn’t happen we give the body tag a special id composed of the controller and action name of the current site.

Then we start every css file that only contains scss for a specific page with the id of that page and name the file controllername_actionname.scss:

It’s definitely not an ideal solution, but it works fine and we haven’t figured out any better way to do this.

JavaScript

We compile all our JavaScript into one application.js file, but as we are not very JavaScript heavy we didn’t need to do any optimizations aside from compression here.

Images

We use Spriting for all of the images in our application. Spriting is the process of combining several images into one bigger image to lower the number of requests to your website. We use the spriting feature of compass-rails heavily in our application. You should have already added compass-rails to your Gemfile before. Configure compass by adding a compass.rb file in config/compass.rb

Now put your images into app/assets/images or one of its subfolders. It is now very easy to create sprites for your website. Create an SCSS File like the following, which expects your buttons to be in app/assetsimages/buttons

This will create a css file for you which references the specific buttons. For example consider you have btn_signup.png and btn_signup_hover.png in your buttons folder. You will then get a buttons-btn_signup css class that you can put onto any element and which sets the background accordingly. The following example creates a link that has btn-signup as its background and gets a hover state. The second css class button is there to set the height and width of the button.

You have to make sure that you set the height and width of every button correctly, so the background fills the element exactly. Setting height and width is best practice in general as the Browser doesn’t have to redraw the page when new images are loaded. You can read more about compass in their Reference Documentation.

Gzip

To make sure all of your assets and pages are compressed before they are sent to your users add Rack:Deflater to your config.ru file.

This will make sure that all your pages are compressed and all the assets that are stored in Cloudfront later on are stored there compressed as well.

Amazon Cloudfront

Now that all assets are set up correctly we can go on to configure Amazon Cloudfront as our CDN. With Cloudfront you can set a Custom Origin pointing to your application. Thus upon the first time you hit a specific Cloudfront url it sends a request to your application and from then on caches the result. To get started go to the cloudfront tab in your aws console and click Create Distribution.

AWS Console

AWS Console

In the first step choose Download as this distribution is used for caching static assets.

AWS Distribution Wizard

AWS Distribution Wizard

In the next step enter your Domain name (or Heroku App Name) as the Origin Domain Name. Every requests that will go to your Cloudfront distribution will be made to this URL and the result will be cached. If you use https set theOrigin Protocol Policy to Match Viewer, so we can later set it to https and all transfers between your application and Cloudfront are encrypted.

AWS Distribution Origin

AWS Distribution Origin

The default values set for the caching behaviour are sufficient. Cloudfront will use the Cache headers we set earlier and store all assets for up to a year.

AWS Distribution Caching

AWS Distribution Caching

In the next window make sure the Distribution state is set to enabled.

AWS create distribution

AWS create distribution

You are presented with a last overview of your new distribution and will be able to create it then. Now you can set the asset host for your application. In your production.rb set config.actioncontroller.assethost. We prefer to set it to ENV['ASSET_HOST'] as we can easily switch to another distribution then, which is very handy when using a staging server. Simply create another distribution for your staging environment and point there in your staging config.

In either case you have to point the asset_host to the distributions Domain Name which should in the end look something likehttps://d2d3cu3tt4cei5.cloudfront.net, though in the AWS console https is not shown.

Before deploying into production test this on your staging app. Make sure that the assets are loaded from cache after your first request. In Chrome open the developer tools and go to the network tab. If you reload the page with F5 chrome will not use your cache, so make sure you either click somewhere in the page or simply open the page again through the NavBar. You should see lots of (from cache) for your requests. Click through your application and make sure that all of your assets are loaded from cache the second time you request them.

Google Chrome

Google Chrome

Check your Heroku logs as well to be sure only the bare minimum of reqeusts are sent to your application. If all works fine Congratulations you have made your application much more responsive. Now go and build something awesome (and tell me about it).

Codeship – A hosted Continuous Deployment platform for web applications

Conclusion

Combining Unicorn on Heroku with the Asset Pipeline and Amazon Cloudfront gives you an incredible platform to scale from. Only the bare minimum of requests are sent to your application and caches are used all along the way to make your application fast, responsive and cheap to run. If you have any questions regarding the setup or anything else you can send an email to flo@codeship.io or a Tweet to @Codeship.

Thanks

Thanks to Arvid Andersson and Tom Coleman for their blogposts.


Download Efficiency in Development Workflows: A free eBook for Software Developers. This book will save you a lot of time and make you and your development team happy.

Author: Florian Motlik

At Codeship I am responsible for the general tech vision and making sure that all of our users are happy and keep their build green. I've always been interested in helping people build great software, great products and just in general make something happen.

Posted by: Florian Motlik | Conversation: 2 comments | Category: Uncategorized | Tags: , , ,

  • dondikaio

    Excellent write-up Florian thank you!

    • https://www.codeship.io/ Florian Motlik

      Thank you. Happy if it could help you