Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Your Pages Will Load Faster With Rails

engineyard.com

Post reply on HN
Print view View original

21–30 of 35 posts

Re: Your Pages Will Load Faster With Rails

#21

Post by charlesmarshall »

wycats wrote: post #17
charlesmarshall wrote: post #13

Earlier quoted context omitted.

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.

Yes, it is presumptuous. Do you think that Rails could make every & any website in the world faster?

Looking at http://www.alexa.com/topsites for example, which of those would you think Rails could make faster?

Re: Your Pages Will Load Faster With Rails

#22

Post by wycats »

charlesmarshall wrote: post #16
wycats wrote: post #6

Earlier quoted context omitted.

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

Also, the reason for using javascript_include_tag instead of is that the actual script tag would look like http://assetsN.yourapp.com/location/of/concatted_js_files.js...;

There's a lot of additional help that a framework can offer for the client-side if you use its helpers, and that help can be tuned over time as the best practices themselves get refined.

Re: Your Pages Will Load Faster With Rails

#23

Post by charlesmarshall »

wycats wrote: post #22
charlesmarshall wrote: post #16

Earlier quoted context omitted.

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

Also, the reason for using javascript_include_tag instead of is that the actual script tag would look like http://assetsN.yourapp.com/location/of/concatted_js_files.js... ; There's a lot of additional help that a framework can offer for the client-side if you use its helpers, and that help can be tuned over time as the best practices themselves get refined.

Speaking of which; when advising to use multiple domains should really mention not to go overboard on the number you use.

Too many alternative domains and you will get a new warning from yslow. Every time you pull from a new domain, this will incur a dns lookup, might even end up with the page going slower because them.

Re: Your Pages Will Load Faster With Rails

#25

Post by charlesmarshall »

wycats wrote: post #19
charlesmarshall wrote: post #16

Earlier quoted context omitted.

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

Yes, both are very tedious, but both possible and done by other frameworks.

Re: Your Pages Will Load Faster With Rails

#26

Post by wycats »

charlesmarshall wrote: post #23
wycats wrote: post #22

Earlier quoted context omitted.

Also, the reason for using javascript_include_tag instead of is that the actual script tag would look like http://assetsN.yourapp.com/location/of/concatted_js_files.js... ; There's a lot of additional help that a framework can offer for the client-side if you use its helpers, and that help can be tuned over time as the best practices themselves get refined.

Speaking of which; when advising to use multiple domains should really mention not to go overboard on the number you use. Too many alternative domains and you will get a new warning from yslow. Every time you pull from a new domain, this will incur a dns lookup, might even end up with the page going slower because them.

Yep. If you just use the default asset host configuration, we limit it to four hosts, as per YSlow.

Re: Your Pages Will Load Faster With Rails

#27

Post by wycats »

charlesmarshall wrote: post #25
wycats wrote: post #19

Earlier quoted context omitted.

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

Yes, both are very tedious, but both possible and done by other frameworks.

The lack of tediousness is the feature. When using Rails, you aren't required to know much about what's going on in order to get the benefits. And that results in an almost universal level of usage.

Re: Your Pages Will Load Faster With Rails

#28

Post by brown9-2 »

wycats wrote: post #17
charlesmarshall wrote: post #13

Earlier quoted context omitted.

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.

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

Re: Your Pages Will Load Faster With Rails

#29

Post by brown9-2 »

m0th87 wrote: post #24

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

Really, there is not a single other standard that IE follows correctly?

Re: Your Pages Will Load Faster With Rails

#30

Post by m0th87 »

brown9-2 wrote: post #29
m0th87 wrote: post #24

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

Really, there is not a single other standard that IE follows correctly?

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.

Post reply on HN