I'd say download Firebug, YSlow, and Google's PageSpeed and let that be your guide, as these suggestions are helpful, but just the tip of the iceberg. A YSlow feature that is new (at least to me) is its JavaScript tab. It's not related to performance exactly, but it will run your JS through jslint, minify, beautify it (if it's in a gnarly style). Great stuff.
Totally the tip of the iceberg. I plan to post some more of the built-in Rails support for other YSlow recommendations in the coming weeks.
The big point of emphasis for me from your post was that, usually, the front-end is the performance sink. A lot of web developers don't seem to get that, and will spend their time optimizing PHP loops (assuming they are not hitting the disk in the middle of that loop...).
I always tell my developers:
1) Measure, measure, measure.
2) Then, apply Amdahl's Law.
Hey @cscotta: This is just the first part of a few posts on this topic. The important part of the post is that Rails handles most of the heavy lifting for you. "Split assets across domains" sounds like it's a snap, but if you already have a large application and want to add it, it can be quite painful. The point is that with Rails, it's literally just a matter of adding a single line in your configuration and all you…
The title is misleading though because it makes it sound as if all you need to do to make your pages load faster is switch to Rails. Whether or not Rails makes it easy to implement these suggests or if another framework makes it harder/easier is another discussion.
There are a few cases where it's actually true depending on your host. For instance, if you use a Rails hosting provider, your image_tag, javascript_include_tag, and css_link_tag, you will get the benefit of far-future expires for free. This is not really specific to any particular Rails hosting provider; they all know that since Rails provides the cache-busting infrastructure, they can be aggressive about client-side caching.
Hey @cscotta: This is just the first part of a few posts on this topic. The important part of the post is that Rails handles most of the heavy lifting for you. "Split assets across domains" sounds like it's a snap, but if you already have a large application and want to add it, it can be quite painful. The point is that with Rails, it's literally just a matter of adding a single line in your configuration and all you…
The title is misleading though because it makes it sound as if all you need to do to make your pages load faster is switch to Rails. Whether or not Rails makes it easy to implement these suggests or if another framework makes it harder/easier is another discussion.
Yes, the title is very misleading. As for the op protesting its because Rails makes its easy to do those things then surely that should be reflected in the name of submission - 'Built in Rails functionality helps page load'
I would also say the title is very presumptuous; claiming to make all pages load faster is an unachievable goal & clearly an exaggeration.
Wycats is a great guy and contributes a ton to the Ruby community, but I have to say...there's really not much here that's new or insightful. Set your headers, gzip content, and split assets across domains, yes, but - "Your pages will load faster with Rails"? Somehow the headline doesn't seem appropriate.
Hey @cscotta: This is just the first part of a few posts on this topic. The important part of the post is that Rails handles most of the heavy lifting for you. "Split assets across domains" sounds like it's a snap, but if you already have a large application and want to add it, it can be quite painful. The point is that with Rails, it's literally just a matter of adding a single line in your configuration and all you…
Expiry headers can just as easily be setup in your apache config and I can't think of any modern language that can't access file modification times.
A simple config for multiple resource domains is nice; but I'm not a fan of helper functions. javascript_include_tag just isnt as clear as
The title is misleading though because it makes it sound as if all you need to do to make your pages load faster is switch to Rails. Whether or not Rails makes it easy to implement these suggests or if another framework makes it harder/easier is another discussion.
Yes, the title is very misleading. As for the op protesting its because Rails makes its easy to do those things then surely that should be reflected in the name of submission - 'Built in Rails functionality helps page load' I would also say the title is very presumptuous; claiming to make all pages load faster is an unachievable goal & clearly an exaggeration.
Is it? Do you have pages that don't include assets? No JavaScript? No CSS? No images? If so, then I think you're right. Otherwise, built-in Rails functionality will make all your pages faster.
Kind of funny how the solution for making Rails faster is offloaded to the client side.
How did you read that into what I wrote? According to Steve Souders (YSlow), 80% of the time spent waiting for a page to load happens on the client. Rails makes it really easy to cut down significantly on that time. The question of server-side performance is entirely orthogonal (and not actually a "problem" for Rails at all; Rails provides significant server-side performance tools as well).
Hey @cscotta: This is just the first part of a few posts on this topic. The important part of the post is that Rails handles most of the heavy lifting for you. "Split assets across domains" sounds like it's a snap, but if you already have a large application and want to add it, it can be quite painful. The point is that with Rails, it's literally just a matter of adding a single line in your configuration and all you…
Expiry headers can just as easily be setup in your apache config and I can't think of any modern language that can't access file modification times. A simple config for multiple resource domains is nice; but I'm not a fan of helper functions. javascript_include_tag just isnt as clear as
You have to set up the Expires header and modify every asset tag to include a cache-busting query string. Doing this via HTML parsing in Apache is extremely non-performant. Manually adding the mtime query string to every asset reference is possible but tedious and yet another thing to think about while building your app (resulting in a very-close-to-0 use of the technique outside of explicit framework support).
Kind of funny how the solution for making Rails faster is offloaded to the client side.
Rails is still just as slow as it ever was. According to YDN Best Practices (http://developer.yahoo.com/performance/rules.html), 80% of response time is spent on the front end. These techniques are for implementing common best practices (as measured by YSlow) that every site should follow.