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](http://www.engineyard.com/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
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.
Split Components Across Domains
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.