Your Pages Will Load Faster with Rails!

This article was originally included in the October issue of the Engine Yard Newsletter. To read more posts like this one, subscribe to the __Engine Yard Newsletter_._

In Inside Rails, Yehuda Katz, Rails expert and core team member, and Carl Lerche, Rails expert and full-time contributor, present expert advice and insight on the Rails platform and Rails development.

Server-side programmers tend to spend a lot of time tuning their server-side code. Studies show, however, that 90 percent of the user’s perceived performance is on the client-side. The YSlow recommendations are the gold standard for client-side performance, providing a list of things web developers can do both on the server-side and the client-side to improve performance. If you use Rails, a large number of these recommendations are baked into the framework.

These tips are not extremely difficult to implement yourself with another framework, but Rails and Engine Yard believe in making your websites fast by default: you shouldn’t need to understand all the minutiae in order to get a snappy application.

Use Far-Future Expires

YSlow recommends using an Expires header set far into the future. This means that browsers don’t need to ask for your images, JavaScripts, or stylesheets again after the first request. However, this introduces an additional problem: what happens if you (inevitably) change these files? Won’t the browser be stuck with the old file forever?

The solution is to include a last modified timestamp with your assets (something like <img src="/images/myasset.png?84392578943" alt="" />). When the file is modified, you update the timestamp, and the browser will know to ask for the file again.

When you use Rails, this timestamping is the default behavior; all you need to do is set up your Nginx or Apache config to serve with far future headers and you’re ready to go. And if you use Engine Yard, we set up those headers for you.

GZip Components

YSlow recommends GZipping JavaScript, CSS, and other textual assets. This reduces their file size over the wire by approximately 70%. This can be set up using your Apache or Nginx config. If you use Engine Yard, your assets are gzipped by default.

Split Components Across Domains

Some older browsers (cough IE cough) will only download two assets from a host at a time. This means that if you have two JavaScript files, two CSS files, and 10 images, these assets will come down two at a time, even though the user’s connection is fast enough to download them in parallel. The solution to this problem is to split your assets up over multiple hosts (assets0.yourapp.com, assets1.yourapp.com, and so on).

When using server-side code you wrote yourself, or using a traditional server-side framework, you’d be forced to go through all of the URLs you generated and update them to use an asset host helper. With Rails, you can simply add a single line to your configuration and all of your generated URLs will start using the asset hosts you specified:

config.action_controller.asset_host = "assets%d.yourapp.com"

Of course, you’ll need to set up a CNAME entry in your DNS to point the new virtual domains at the same host, but that should be trivial.

This also single-handedly resolves another YSlow recommendation: “Use Cookie-free Domains for Components.” If your assets and application are on the same domain, the browser and server will pass cookies back and forth (up to 4k worth) for each asset request. By using asset hosts for your assets, you get the side benefit of cookie-free domains for your assets.

When comparing frameworks, it’s tempting to look at something like “Etag Support” as a feature and simply check it off. Looking under the surface, however, there are complex considerations that are begging to be abstracted away from you. Why should you have to know what the header name in the request is called (If-None-Match) or how to generate a reliable unique key for an object?

Rails makes working with these ideas drop-dead simple, so you won’t have to stress about following web best practices; when using Rails, you’ll be doing the right thing and hardly know it. Stay tuned for a follow up post on more of the ways Rails makes fast page loading a breeze.