

Your Pages Will Load Faster With Rails - wifelette
http://www.engineyard.com/blog/2009/your-pages-will-load-faster-with-rails/

======
cscotta
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.

~~~
wycats
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 your existing assets URLs will come along for
the ride.

Same with far future expires. If you just set your headers to the far future,
you'll be stuck with outdated content on the client that you can't control. If
you use Rails, without doing a single additional thing, your asset URLs come
prebaked with cache-busting behavior that operated in the background with no
additional work by you.

~~~
brown9-2
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.

~~~
charlesmarshall
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 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.

~~~
brown9-2
The problem with the title "Your Pages Will Load Faster With Rails" is that it
implies that Rails alone will make your pages load faster, and/or that Rails
alone will make your pages load faster than they already are.

All of the speedup suggestions outlined in your article can also be handled
easily - easier than Rails or not, I don't know - in other languages and
frameworks as well. There is nothing about any of these items that only Rails
can handle - heck half of them don't even have anything to do with your choice
of server-side frameworks.

The main point of your article is "How Rails can make it easy to make your
pages load faster".

------
mncaudill
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.

~~~
wycats
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.

~~~
mncaudill
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.

------
xsc
This isn't just specific to Rails. -Use Far-Future Expires -GZip Components
-Split Components Across Domains

~~~
wycats
Of course not. But Rails makes it dead easy!

------
m0th87
Slightly off-topic, but the article pokes fun of older versions of IE because
they only run two concurrent HTTP requests to a host at a time. That is
actually the only instance where IE follows standards correctly:
<http://awurl.com/eWXb3NvtK>

~~~
brown9-2
Really, there is not a single other standard that IE follows correctly?

~~~
m0th87
While the remark wasn't meant to be taken literally, it's pretty close to
true: <http://www.webdevout.net/browser-support-summary>

Part of it is a product of how difficult it is to be standards compliant with
web technology, and perhaps I made an overbearing comment, but I'm still
bitter with how IE held the web back for so many years out of apathy.

------
idlewords
This is just an ad for the guy's hosting business.

~~~
technoweenie
Well yes, it's on the guy's host business' blog.

------
ismarc
Funny,

    
    
        The system is down for maintenance as of 14:26 PST.
    
        It'll be back shortly.

~~~
ismarc
What, no one got the irony of the server(s) hosting a blog post about how to
increase page load performance was down for maintenance in the middle of the
day?

------
vlucas
Kind of funny how the solution for making Rails faster is offloaded to the
client side.

~~~
wycats
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).

